Context engineering

What is context engineering?

Context engineering is the practice of deciding what an AI model sees on each call, and in what shape. That bundle is more than the question you type. It includes the system instruction, retrieved documents, tool definitions and their results, earlier messages in the conversation, saved notes, and the format you want the answer back in. Get the bundle right and a modest model behaves; get it wrong and the strongest model on the market still guesses.

The term took off in 2025 as teams moved from one-off chatbot prompts to AI agents that run many steps against real systems. A single clever sentence stops being enough once a model has to read files, call tools, and track a task across dozens of turns. The common one-line version of the idea: fill the context window with just the right information for the next step, and no more.

One way to picture it: prompt engineering is writing a good question, and context engineering is packing the bag the model carries into the task. Space is limited, so what you leave out matters as much as what you put in.

Context engineering versus prompt engineering

Prompt engineering is about wording: how you phrase an instruction so the model does the right thing. It is mostly a single-call concern, and often stays fixed once you find phrasing that works. Context engineering is about everything around that instruction, and it changes on every call as documents are retrieved, tools return results, and the conversation grows. Anthropic calls context engineering the natural progression of prompt engineering, and that ordering is right: you still write good prompts, but the harder problem becomes getting the right context in front of the model at the right moment.

The sibling techniques slot in underneath. RAG is one way to select knowledge to add to the window. MCP is one way tools show up so the model can fetch or act. The context window is the budget all of it has to fit inside. Context engineering is the discipline that decides how to spend that budget across a whole task, rather than any one of those techniques on its own.

How teams keep context tight

Once you treat the window as a budget, the work becomes deciding what to load, what to drop, and what to set aside for later. Four patterns show up in almost every serious agent.

The first is retrieving just in time. Instead of loading a whole knowledge base or codebase up front, the agent keeps lightweight references such as file paths or record IDs and pulls the actual content only when a step needs it. A coding agent in a large repository works this way: it holds the file tree, then reads a specific file the moment it has to change it, rather than carrying the whole project in the window.

The second is compaction. When a conversation nears the window limit, the agent summarises the story so far and continues from that summary. Claude Code does this automatically once the running context gets close to full, which lets one session keep going long past what the raw message log would allow.

The third is offloading: the agent writes intermediate findings to a scratchpad or a memory store outside the window and reads them back when they matter, so a plan survives even after the older messages are dropped. The fourth is isolation, where a main agent hands a focused job to a helper that has its own clean window and keeps only the result, so no single window has to hold everything.

More context is not better context

Model context windows keep growing, and a large one is tempting to treat as room to dump everything in. It is not. As the amount of text grows, a model gets worse at reliably finding and using any single fact inside it, an effect often called context rot. The drop tends to show up well before the window is technically full, and it varies from one model to the next. Every extra token also spends part of a finite attention budget and adds cost and latency, since most APIs bill per token and larger prompts take longer to process.

This is why curation beats volume. Picture an internal support assistant answering staff questions from a document store. The naive build stuffs a few hundred pages into every prompt and hopes the answer is in there somewhere. The engineered build retrieves the three passages that actually match the question, filters them to what the person is allowed to see, and adds one rule: if the passages do not cover it, say so instead of guessing. The second system is cheaper, faster, and far less likely to hallucinate, because the model reasons over a page of relevant text instead of hunting through a phone book.

What to watch out for with context engineering

Three failure modes come up again and again. The first is permissions: if your retrieval step can reach a document, the model can reach it too, so filter retrieved content by who is allowed to see it before it enters the window, never after. The second is edge cases. Context that looks fine on the happy path tends to break when no source matches the question, when two sources contradict each other, or when the request falls out of scope, so test those paths on purpose. The third is clutter, because every tool definition and every saved note competes for the model's attention. Offering too many tools makes it pick the wrong one more often, and stale memory quietly corrupts later answers, so prune both as the system grows.