Context engineering
The quality of an agent's output depends more on what is in its context than on how clever the prompt is. Context engineering is choosing that content on purpose.
Words on this page (10)
- agent
- : A model run in a loop that chooses its own tools and steps until the task is done.
- prompt
- : The input text you give a model, including instructions, examples and data.
- context engineering
- : Deciding what goes into the model's context window, and when.
- few-shot
- : Giving a few worked examples in the prompt.
- tool
- : A function the model can ask your program to run, described by a name, description and argument schema.
- guardrail
- : A rule or check that limits what a system may do or output.
- policy
- : A rule for choosing actions. In a language model, the model itself is the policy.
- token
- : A piece of text the model reads and writes, usually a word or part of a word. About 4 characters of English on average.
- repo
- : Repository: a project folder tracked by git, usually hosted on GitHub.
- attention
- : The mechanism that lets each token weigh all earlier tokens by relevance when computing its next representation.
What it is
Context is everything the model sees on a call. Six kinds cover most of it: instructions (role, goals, boundaries), knowledge (retrieved documents, schemas), memory (what happened this session, and what persists across sessions), examples ( demonstrations), (their names, descriptions and results), and (hard rules and format constraints).
The working rules
Treat the window as a budget. Load only what the next step needs. Prefer a short pointer the can follow, such as a file path, over pasting the content. Trim old tool output. When a long task fills the window, compact it into a summary or restart with a clean context and a written handoff. Order matters: stable instructions first, so cached prefixes stay reusable.
Try it
List what your agent sees on its tenth step. Mark each item as needed, maybe, or noise. Remove the noise and compare results.
A worked example: the six kinds
Customer support agent. Instructions: tone, limits. Knowledge: the refund retrieved for this question. Memory: the customer said earlier they bought the red model. Examples: two model replies to similar tickets. Tools: look up order, issue refund up to $10. Guardrails: never reveal other customers' data. The question is not "how do I word the ", it is "what does this agent need on its desk right now?"
How the model uses the window
The model keeps no memory between calls. Each step, the whole context is sent again, and the model reads all of it. An agent's memory is only what you choose to resend. Invented numbers: the first step has 2,000 , and each step adds 1,500 tokens of tool output. Step 10 holds 2,000 + 9 × 1,500 = 15,500 tokens. Over 10 steps the model reads 87,500 tokens in total, because each step re-reads everything before it.
A second example: a coding agent
An agent fixing one bug does not need the whole . Instructions: the repo's rules file. Knowledge: only the failing file. Memory: the output of the last test run, not all earlier runs. Tools: read a file, edit a file, run the tests. Compare this with the support agent above. The same six kinds apply, but the content is picked for the task. A one-off question to a chat assistant needs none of this. A good single prompt is enough.
What goes wrong
The symptom is an agent that ignores a rule you gave early, repeats a step, or picks the wrong tool. The most useful check is to print the exact context at the failing step and read it as the model would. Often the needed item is missing, or it is buried under pages of old output. Fix what you find there before changing the wording of any instruction.
Common mistake
Adding more and more in case it helps. Every extra line competes for the model's .
A new employee on their first day is handed a pile of 400 documents and told "answer customer questions". Another is handed a one-page guide and a link to exactly the three documents that matter for today's question. The second will do better, though both are equally smart. Context engineering is preparing that second desk.
Check yourself
An agent's tenth step carries a 40k-token tool result that no longer matters. Best move?
Not quite. Old tool output distracts the model and costs tokens, so trim it unless a later step needs it.
Why put stable instructions at the start of the prompt?
Not quite. Providers cache matching prefixes, so a stable start is cheaper and faster.
A support agent needs the refund policy for one question. What is better than pasting the whole handbook?
Not quite. Loading only what the next step needs keeps the context small and focused.
You got 0 of 3 right.
Go deeper
- Article
Anthropic · Context as a finite resource, with compaction, notes and subagents.
- ArticleContext engineeringArticle
Simon Willison · Why the term replaced prompt engineering.
- Article
Manus · Production lessons on KV-cache, file-system memory and keeping errors in context.
- ArticleHow Long Contexts FailArticle
Drew Breunig · Names the failure modes: poisoning, distraction, confusion, clash.
- ArticleThe New Software LifecycleArticle
Addy Osmani · Summarizes Google's whitepaper, including the six kinds of context.
Spotted a mistake or something unclear? Report it on GitHub.