What Is Context Engineering? A Guide for AI Builders
Choose what an agent sees at each step: instructions, tools, retrieved evidence, memory, and working state. Includes a concrete context-budget example.
Context engineering is the work of deciding what information an AI model receives at each step of a task. It includes instructions, tool definitions, current state, retrieved documents, relevant memories, and selected conversation history. The goal is to supply enough reliable information for the next decision within the model's context and cost constraints.
Prompt engineering focuses on how instructions are written. Context engineering also controls which facts and tools are available, when they arrive, and what happens to them as the task continues.
Start with the next decision
Consider an assistant preparing a customer renewal summary. It needs the current contract, recent support issues, confirmed customer priorities, and the requested output format. It probably does not need every message ever exchanged with that customer.
Ask what would change the next decision. A current contract amendment may matter more than ten older summaries. A recent support event may be relevant evidence without being an instruction. The distinction affects both retrieval and how the context is labeled.
Anthropic's context-engineering article describes this as managing the information available during inference. It also discusses selective retrieval and compaction. Those are useful techniques to evaluate, not a fixed architecture every agent must copy.
Separate information by its role
| Context component | Example | Treatment |
|---|---|---|
| Instructions | Produce a renewal summary with citations | Keep clear and internally consistent |
| Authoritative state | Current contract and account permissions | Fetch from the owning system |
| Retrieved evidence | Support notes and previous commitments | Keep source identity and dates |
| Working state | Sections drafted and unresolved questions | Update as the task progresses |
| Historical memory | The customer's preferred reporting style | Apply only when relevant |
| Tool output | Search results or a database response | Bound size and preserve needed references |
Do not let text retrieved from a document become a new instruction merely because it appears in the prompt. Likewise, a remembered account role should not substitute for the permission check performed by the application.
Allocate a budget before filling it
Suppose an application chooses an illustrative 32,000-token operating budget for a request. It reserves 4,000 for output, leaving 28,000 for input. This is an application example, not a claim about a specific model's limits.
One possible input allocation is 3,000 for instructions and tools, 2,000 for the current request, 5,000 for working state, 12,000 for evidence, and 6,000 of headroom. Those values total 28,000. Unused capacity is acceptable; it is not a quota to fill.
When evidence exceeds its allocation, rank and deduplicate it, retrieve narrower sections, or split the work into steps. Do not truncate blindly through the middle of a citation or remove the only passage supporting an exception. Measure actual tokens with the tokenizer or usage interface for the selected model; word counts are only rough planning aids.
Build the context at the point of use
A useful request sequence authenticates the caller, loads current task state, retrieves authorized evidence, checks versions, and selects what the next model call needs. The model can request more information when the first evidence set leaves a specific gap.
For example, the renewal assistant might first identify support incidents, then fetch the two relevant incident reports. Loading every report upfront may be wasteful, while allowing unlimited tool exploration may be slow. Record tool calls and evidence use so you can compare those strategies on actual tasks.
There is also a freshness tradeoff. Precomputed summaries are convenient, but current contractual terms should come from the latest approved source. Label summary dates and keep a route back to the original material.
Preserve state across long tasks
When a task outlasts one context window, carry forward a compact record of the objective, constraints, completed actions, outstanding questions, and evidence references. Keep exact identifiers, numbers, and instructions that would be dangerous to paraphrase incorrectly.
A handoff should say “draft prepared, not sent” when that is the true state. Otherwise, the next session can mistake an intention for a completed external action. This applies to agents continuing their own work as well as work transferred between agents.
The context-limit guide covers overflow and compaction. The long-term memory guide covers information needed across separate sessions and tasks.
Evaluate the assembled context, not only the prose
Log which evidence IDs reached the model, how many tokens each component consumed, and which sources the answer cited. If an answer is wrong, this lets you distinguish missing evidence from poor use of available evidence.
Useful tests include a late correction, an older conflicting document, a long irrelevant tool result, an inaccessible record, and a request where no memory is needed. Compare task completion, evidence support, latency, and cost. Smaller context is an improvement only if the task still succeeds.
Start with one workflow and capture ten representative traces. For each trace, identify the information that changed the answer and the information that merely consumed space. That review gives you concrete retrieval and context changes to make before adding another framework or model.
If those traces show that useful context disappears between sessions, try Supermemory in that workflow. Start by carrying one confirmed preference or decision into the next conversation, and compare the assembled context with your existing approach.