Context engineering is the design of the information available to a language model when it performs a task. It includes instructions, retrieved documents, conversation history, tool definitions, tool results and any relevant memory.
Prompt engineering sits within that work. A prompt specifies the task and desired behaviour; context engineering also determines which evidence reaches the model, whether it is current and what must be excluded. The distinction becomes especially useful when an assistant works across several systems or takes multiple steps.
Context engineering and prompt engineering compared
| Decision | Main concern | Example |
|---|---|---|
| State the task | Prompt engineering | Ask for a cancellation policy explanation with a clause reference |
| Demonstrate a boundary case | Prompt engineering | Show how to respond when an order has shipped |
| Retrieve current evidence | Context engineering | Fetch the applicable policy version and live order status |
| Manage conversation history | Context engineering | Preserve a corrected order number across turns |
| Choose available tools | Context engineering | Offer a read only order lookup for an informational request |
| Enforce access | Application security | Verify that the signed in user can access the order |
These responsibilities overlap. Prompt design also involves testing and software, and context engineering is not limited to retrieval. The terms describe useful areas of work rather than a strict organisational boundary.
Anthropic's context engineering guidance discusses managing the information supplied during inference, including the changing context of an agent. The terminology does not imply that earlier prompting practices became obsolete.
What belongs in an LLM context
Start with the information required for the current decision. A support assistant may need the current question, a small portion of the conversation, the applicable policy and an authenticated order lookup.
Tool definitions describe actions the model may request. Retrieved passages provide documentary evidence. Tool results provide observations, such as a current delivery status. Memory may supply a saved preference, but only if that preference is relevant and remains valid.
These sources have different authority. A customer's statement that an order shipped is useful context; the order service may be the designated authority for shipment status. An assistant's earlier guess should not acquire authority simply because it appears in the conversation history.
Example: answering an order cancellation question
Consider a customer asking, “Can I still cancel order 41822?” A sufficient context might contain:
Task: Explain eligibility. Do not perform an action.
Verified order lookup:
order_id: 41822
status: dispatched
Current policy:
4.2: Orders can be cancelled until they are dispatched.
4.7: Dispatched orders follow the returns process.
Question:
Can I still cancel order 41822?
This context supports an explanation that cancellation is no longer available under clause 4.2 and that clause 4.7 describes the next route.
If clause 4.7 is missing, clause 4.2 still establishes the cancellation boundary. The assistant lacks the documented next step; it has not gained permission to cancel. This distinction matters when diagnosing retrieval failures. Identify precisely which part of the answer lost its evidence.
The customer's cancellation history is unnecessary unless the policy uses it. Including it adds sensitive data without helping the decision.
Build context with explicit selection rules
A context builder should authenticate the request, fetch authorised data, select relevant evidence and check the final token budget. It should also preserve source identifiers and versions.
The builder needs a policy for excess material. Older conversation turns might be summarised, duplicate passages removed and verbose tool results reduced to required fields. Mandatory instructions or essential evidence should not disappear through blind truncation.
The write, select, compress and isolate framework provides a useful vocabulary for these choices. Each choice needs a test. A shorter context is useful only if the task still has enough information.
For the cancellation question above, context assembly can follow this workflow. The application checks access before any private order data reaches the model.
Measure context quality at the point of failure
Track missing evidence, stale records, unsupported claims and lost corrections alongside token use. A token breakdown shows where space and cost are going; it does not show which component caused an error.
For a practical review, take a failed answer and inspect the exact context sent. Was the necessary evidence absent, contradicted, outdated or merely unused? That finding determines whether to change retrieval, memory, prompt wording or the application logic.