What Is Context Engineering? Definition, Techniques and Examples (2026)

Context engineering is the practice of deciding everything a language model sees on each call, so that the task is solvable with the fewest, most relevant tokens. That includes the system prompt, examples, tool definitions, retrieved documents, memory, conversation history, and the results of earlier steps. A model has no knowledge of your situation beyond what is in its context window; context engineering is the work of putting the right things there and keeping the wrong things out.

The term spread in June 2025. Shopify's CEO Tobi Lütke wrote that he preferred it to "prompt engineering" because it names the real skill: providing all the context for the task to be plausibly solvable by the LLM. Andrej Karpathy agreed, describing it as "the delicate art and science of filling the context window with just the right information for the next step." The shift in wording tracks a shift in practice: once models started running as agents for dozens of steps, the instruction became a small part of the input, and everything around it started to decide the outcome.

Context engineering versus prompt engineering

Prompt engineering is a subset. It is about the instruction: the role, the task, the constraints, the output format, the examples. Context engineering treats the whole window as the thing being designed, usually by code rather than by hand, and across every turn of an agent harness rather than one message.

A rough way to see the difference is to count tokens in a long agent run. The instruction might be 500 tokens. The tool definitions might be 5,000. Retrieved files, earlier tool results, and conversation history can fill the next 100,000. Rewriting the 500 matters, but most of what the model attends to is the other 99%, and that is where most agent failures start.

What goes into a context window

It helps to list the parts, because each one is a separate decision:

• Instructions. The system prompt and standing rules, such as a CLAUDE.md or AGENTS.md file in a coding agent.
• Examples. Few-shot demonstrations of the output you want.
• Tools. The names, descriptions, and schemas of every tool the model can call, including every tool from every connected MCP server.
• Retrieved knowledge. Documents, code, or records pulled in for this step (the retrieval in RAG).
• Memory. Facts carried over from earlier sessions; see agent memory.
• History. The conversation and the agent's own earlier actions and their results.
• Output contract. The format the next step or the parser expects.

Every token in that list competes for the same finite window and for the model's attention.

The four core techniques

LangChain's Lance Martin grouped the practical techniques into four moves, and most real systems use all of them:

1. Write: keep information outside the window. Save plans, notes, and intermediate results to files or a scratchpad the agent can reread, instead of carrying everything in the conversation. A coding agent that keeps a running todo file and rereads it each step is doing this.
2. Select: pull in only what this step needs. Retrieve the three relevant files rather than the whole repository, load memory entries that match the task, and expose only the tools the current step could use. Retrieving just in time, when the agent asks for something, usually beats loading everything up front.
3. Compress: shrink what has to stay. Summarise long tool outputs before they go back in, trim old turns, and run context compaction when the window fills. Compression is lossy, so decide in advance what must survive it: the goal, constraints stated once, and exact error strings.
4. Isolate: split work across separate windows. Give a subagent a narrow task and a clean context, and take back only its conclusion. The main agent never sees the twenty files the subagent read, only the answer.

How context fails

Drew Breunig named four failure modes that are worth checking against any agent that misbehaves on long tasks:

• Poisoning. A wrong fact or a hallucination enters the context and the model keeps building on it, because everything in the window looks equally true.
• Distraction. The history grows so long that the model leans on repeating earlier actions instead of reasoning about the current step.
• Confusion. Irrelevant material, such as forty tool definitions for a task that needs three, pulls the model toward the wrong tool or the wrong detail.
• Clash. Two parts of the context disagree (an old instruction and a new one, two retrieved documents) and the model picks one silently.

Underneath all four is context rot: accuracy falls as input length grows. Chroma tested 18 models in 2025 and found performance degrading with longer inputs on simple tasks, long before the advertised limits. Anthropic's engineering guide on context engineering frames the same point as an attention budget: aim for the smallest set of high-signal tokens that makes the desired outcome likely. A million-token window is a ceiling, not a target.

Untrusted text is a fifth problem. Anything an agent reads (a web page, an issue, a document) becomes part of its context, which is how prompt injection works. Treat retrieved content as data and keep it clearly separated from instructions.

Cost and the cache

Context engineering is also a cost discipline. Providers discount input tokens that repeat an earlier request's prefix: on Claude Sonnet, cached input costs $0.30 per million tokens against $3 uncached, a tenfold difference. The team behind the Manus agent called the cache hit rate the single most important metric for a production agent, and their rules follow from it: keep the start of the prompt stable (no timestamp at the top), append to the context instead of editing earlier turns, and hide unavailable tools rather than deleting their definitions mid-session, since any change early in the window invalidates the cache for everything after it.

A worked example: a data analysis agent

Take an agent that answers questions about a sales database. A naive version loads the full schema of 60 tables, every past message, and the raw output of each query. After ten questions it is slow, expensive, and starts confusing column names from different tables.

The engineered version keeps a short system prompt with the analysis rules, retrieves only the schemas of tables whose names or descriptions match the question, summarises each query result to the rows and totals that answered it, writes confirmed definitions ("active customer means an order in the last 90 days") to a notes file it rereads, and hands exploratory work to a subagent that returns one paragraph. The prompts in our Claude data analysis pack are written to slot into that structure: the profiling prompt runs once and its summary, not the raw output, stays in context.

A prompt for auditing a context window

Dump the full input your agent sends on a bad step (system prompt, tools, retrieved material, history) and run this against it:

You are auditing the context window an AI agent received on one step.
<context>[paste the full input the agent received]</context>
<task>[what the agent was supposed to do on this step]</task>
1. Estimate the share of tokens spent on instructions, tool definitions, retrieved material, memory, history, and tool results.
2. List every item the task did not need, and say whether to drop, summarise, or move it to a file the agent can read on demand.
3. List anything the task needed that is missing or buried after a large block of irrelevant text.
4. Point out contradictions between parts of the context, and any instruction-like text inside retrieved data.
5. Rewrite the context plan for this step as a short list: what to load, in what order, and what to summarise.

Run it on two or three failing steps and the pattern usually shows up quickly: too many tools, raw tool output kept verbatim, or a rule stated once at the start of a long session and lost by step forty. Measure the fix with a small eval on the same tasks before and after, since a cleaner context should show up as fewer wrong tool calls, not just a shorter prompt.