Context engineering explained: what it is and why a good prompt is not enough

Context engineering is choosing what an AI model gets to see before it answers: your request, but also the tools, the examples, the conversation so far, retrieved documents and whatever the agent has remembered. This article covers what it is, why more information in the window often produces a worse answer, how it goes wrong and what you can do about it, even if you do not write code yourself.

You may have seen it. An AI assistant does great at the start of a conversation. After an hour of work it forgets agreements, contradicts itself or repeats something you already rejected. Your prompt was not the problem. There is too much in the window the model works with, and part of it no longer belongs there.

That is what context engineering is about. The term became popular in June 2025 and has been a common concept among people building AI agents since Anthropic's write-up in September 2025. It has no fixed definition, and part of what falls under it, like retrieving documents, already existed. What is new is that the whole picture now has a name. Status as of November 9, 2026.

Context engineering at a glance

The facts first.

What context engineering is, in plain language

Imagine you ask a colleague to handle a complaint, but he may only work with what fits on one table. On that table are your instructions, the manuals for his tools, a few examples of good replies, the email thread so far and the documents he fetched. When the table is full, he puts new papers on top of old ones or pushes something off the edge. What he sees at that moment decides what he does.

For an AI model that table is called the context window. At each step the model reads everything in it and nothing else. That is why Anthropic defines context as everything in the input, not just the prompt. It is more than it sounds. As soon as an agent uses tools, something gets added at every step: the result of a search, the contents of a file, an error message from a program.

The window is counted in tokens. A token is a piece of text, roughly a word fragment or a few letters. The window has a limit, but what matters more is that the model does not spread its attention evenly over everything. Anthropic calls this an attention budget. Every new piece of text uses part of it, and the budget is finite.

Context engineering is the work of spending that budget well. You decide what goes in, in which form, at what moment and what comes out again. Anthropic describes it as finding the smallest set of high-signal information that makes the desired result most likely.

Prompt engineering versus context engineering: what is the difference

Prompt engineering is writing the instruction well. You pick the words, the order and maybe an example. That stays useful and it is part of context engineering. But a prompt is one of the things in the window. As soon as a system has several steps, most of what the model sees is decided by something other than your text.

Take an assistant that answers customer questions. The prompt says how it behaves. The context decides which order, which piece of policy and which earlier email get looked up, how much of the conversation stays, and which tools the assistant may use. With a perfect prompt and the wrong order in the window, you still get a wrong answer.

There is also a difference in time. You write a prompt once and improve it afterward. You assemble context again at every step. Anthropic calls it iterative for that reason: each time the system decides what the model gets to see, that is a choice you either designed or left to chance.

Where the term comes from and why it is contested

In June 2025, Tobi Lütke, the CEO of Shopify, wrote that he found "context engineering" a better term than "prompt engineering". He described the skill as providing all the context a task needs to be plausibly solvable by the model. A few days later Andrej Karpathy came out in support of the term with his own version: the art and science of filling the context window with just the right information for the next step.

Simon Willison, a widely read writer on AI, predicted the term would stick. His reasoning is that a term mostly means what people read into it. Most people hear "prompt engineering" and think of typing into a chat box, while the work is more involved. "Context engineering" sits closer to the work itself. On September 29, 2025, Anthropic developed it in an article of its own, with the core idea that context is a finite and precious resource.

There is criticism. Some people see it as a new name for something that already existed: retrieving documents, managing memory, trimming conversations. The defense is that it is not a rebrand but a widening of scope. It is no longer about one part but about the whole. A fair summary is that the term is young, that most sources are blogs and trade articles, and that the underlying idea holds up whatever you think of the name.

Why more context often works worse

It is tempting to give a model everything you have: the whole document, the whole email thread, all the rules. Models now have windows of hundreds of thousands of tokens, so it fits. The research points the other way.

Chroma published the report "Context Rot" on July 14, 2025. They tested 18 models from Anthropic, OpenAI, Google and Alibaba, among others, with nearly 195,000 calls. For every model the result got worse as the input grew longer, while the task stayed equally hard. In one of the experiments, on a conversation, the models got the same question once with more than 113,000 tokens of conversation and once with only the roughly 300 tokens that mattered. Every model scored better with the short version.

Two other outcomes are worth remembering. A single distracting piece of text that resembled the right answer already made the result worse, and with four it got worse still. And a text that was logically structured turned out harder than the same text shuffled. Anthropic gives as the reason that models relate every piece of text to every other piece and that they mostly saw shorter texts in training. The damage builds up gradually. It is not a cliff.

Practitioners call this context rot: the context deteriorates as it grows. For your use it means that giving more is not a safe choice. Every piece in the window has to earn its place.

Four ways context goes wrong

Drew Breunig, who wrote a lot on this subject, distinguishes four failure patterns. They show up mostly in agents that work for a long time and use many tools.

Poisoning

A mistake or invention ends up in the context and then gets used again and again. Say the agent notes a date wrongly in step three. In step eight it calculates with it, in step twelve it is in the final report. Because the model reads its own earlier output as truth, the error repeats without anyone noticing it any more.

Distraction

A very long context can make the model focus too much on the context itself. It gets stuck in what has already happened and leaves its own knowledge and the original task alone. The agent starts repeating what is in the window instead of coming up with something new.

Confusion

Superfluous information pulls the answer in the wrong direction. You give the model thirty tools and only two fit the task. It picks one that is slightly off because the description looked right. If you cannot say yourself which of two tools you would pick, do not expect better from the model.

Clash

New information contradicts something already in the window. A customer says at the start that it is for ten people and later that it is twelve. Both are in the context. The model picks one, averages them or does not ask, and you cannot tell which of the three you will get.

Six ways to keep the context healthy

Each of these problems has a remedy. Anthropic discusses three for long-running tasks, and Breunig names six. Here they are in plain words.

Fetch when needed

You do not put everything in the window up front. The agent gets pointers, such as file names, searches and links, and fetches the content at the moment it needs it. Anthropic calls this just-in-time. Claude Code works this way with large files and data: it first runs a search or looks at the top of a file and does not load the whole thing. The downside is that it is slower and that the agent needs good hints so it does not wander. That is why many systems combine both: what is almost always needed goes in up front, the rest is fetched on request.

Choose the tools

You give the agent only the tools that fit this task. Breunig points to research in which some models got confused with more than twenty tools. Anthropic says the same in another way: if a human cannot say which tool fits a situation, the agent cannot either. Tools without overlap and with a clear description work better than a big toolbox.

Split off

A main agent keeps the overview and sends sub-agents off for parts of the job. Each sub-agent works in its own clean window, may spend tens of thousands of tokens searching there, and brings back only a summary of about 1,000 to 2,000 tokens. The searching stays out of the main agent's window. This is a small graph and matches what I describe in the article on graph engineering.

Prune

What is no longer needed goes out. The lightest form is clearing old tool results: the raw text a search returned three steps ago is not needed any more once the agent has drawn a conclusion from it. Breunig calls this pruning.

Summarize

A conversation that nearly fills the window gets summarized, and the work then starts over with that summary. Anthropic calls this compaction. In Claude Code the summary and the five most recently used files stay. The advice is to first make sure nothing important is lost and only then cut what is superfluous.

Notes outside the window

The agent writes down what it needs later, in a file outside the conversation, and reads it back when it can. That can be a to-do list or a file like NOTES.md. In Anthropic's example, an agent playing Pokémon kept precise track of where it was this way, even after its window was reset. Breunig calls it offloading.

Which approach fits depends on the task. Summarizing suits long conversations with a lot of back and forth. Notes suit work with clear intermediate steps. Sub-agents suit research you want to cover widely and then merge.

Skills and progressive disclosure: where things stand in 2026

A pattern that keeps coming back in 2026 is called progressive disclosure: reveal more step by step. You do not put the whole book on the table. You start with the table of contents and open a chapter only when it is needed.

Anthropic used this on October 16, 2025 for Agent Skills, small folders with instructions and files an agent can load. At startup the agent reads only the name and a short description of each skill. If a skill looks relevant, it reads the full instructions. If those point to extra files, it opens them only when the task asks for them. That way a skill can carry a lot without the window being full of it up front. It has since been published as an open standard.

A study from July 20, 2026, "Is Progressive Disclosure All You Need for Long-Context Agents?", adds a sober note. The authors compared several setups on questions about long documents. The benefit depended on the system around the model: large when the agent navigates raw documents badly, close to zero when it already does well on its own. One level worked well. A second routing level never helped and sometimes hurt badly. Their conclusion fits in one sentence: progressive disclosure buys context, not intelligence.

How I work with context myself

I use Claude Code to work on the Make it Matter website and admin panel. That is a lot of files and a long history, so context is a daily problem for us. What I do about it is simple and follows the principles above.

There is a file with working agreements that comes along in every session. It says where each part lives, what is and is not allowed, and which document goes with which task. Each part has a short card that loads by itself as soon as the agent touches a file of that part. A card holds the key files, the pitfalls and the tests, not the code itself. On top of that there is a generated overview of all files with just the function names and a short description.

The rule is that the agent reads the card and the overview first, then picks two or three files and opens only those, and with big files only the part it is changing. Broad searches across many files go to a sub-agent that returns only the conclusion. Each part gets its own session. That is fetching when needed, splitting off and pruning in one way of working, without building a complicated system for it.

Start small: design your first context

You do not need an agent framework to begin. It works for an ordinary chat with a model too.

1. Write down what the task minimally needs to succeed. That is your core: the request, the constraints and one or two good examples.

2. Remove what does not belong there. Check each piece of text by asking whether the answer gets worse if it goes.

3. Give pointers instead of full documents when the model can ask for more. A list of file names with one sentence each is a good start.

4. Split a long task into parts and give each part its own clean conversation. Carry over only the outcome to the next part.

5. Have the model write down what is settled along the way, such as decisions, open questions and agreements, and paste that at the start of a new conversation.

6. Test by running the same task again with less context. If the result is equal or better, that part did not belong.

When context engineering does not pay off

For a one-off question in a chat it is overkill. A short task with a few sources fits any window and needs no design. The same goes for a small set of documents you can simply put in. The research on progressive disclosure shows that the gain is small when the system already does well on its own and only becomes large when there is too much to read through.

Keep the costs in mind too. Every layer you add, such as summaries, sub-agents and notes, can make mistakes of its own. A summary leaves something out, a note can go stale, a sub-agent can bring back the wrong thing. Start with the smallest intervention and add something when you see where it goes wrong. Anthropic itself writes that better models need less prescriptive engineering, so what is needed today may be unnecessary in a year.

Frequently asked questions

Sources

• Effective context engineering for AI agents, Anthropic, September 29, 2025.

• Context Rot: How Increasing Input Tokens Impacts LLM Performance, Chroma, July 14, 2025.

• Context engineering, Simon Willison, June 27, 2025.

• How to Fix Your Context, Simon Willison on the work of Drew Breunig, June 29, 2025.

• Equipping agents for the real world with Agent Skills, Anthropic, October 16, 2025.

• Is Progressive Disclosure All You Need for Long-Context Agents?, arXiv 2607.17598, July 20, 2026.