Context engineering is subtraction
In short: Prompt engineering is about writing one instruction well. Context engineering is about curating what stays in the window across a long agent loop — and the governing constraint is that models have a finite attention budget which depletes as tokens accumulate. Recall degrades as context grows, so the discipline is subtraction: the smallest set of high-signal tokens, a system prompt at the right altitude, a lean tool list, and data fetched just in time rather than pre-loaded.
Ask most teams how to improve an AI system that is giving weak answers and you get the same instinct: give it more information. Feed it more documents. Load more history. Put the whole handbook in the prompt.
The published research says this is backwards. Anthropic's guidance on effective context engineering states the goal as finding
"the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome."
Smallest. Not largest. That single word is the whole discipline, and it is the opposite of what almost everyone does first.
The distinction people keep asking about
The two terms get used interchangeably and they are not the same thing. Anthropic draws the line precisely:
Prompt engineering is "methods for writing and organizing LLM instructions for optimal outcomes."
Context engineering is "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference."
The difference is scope and time. Prompt engineering is about getting one instruction right for one task. Context engineering is about what is in the window at every step of a loop that keeps running — where the model acts, gets tool output back, acts again, and the window fills with material nobody chose deliberately.
That is why the term changed. It is not rebranding. Agents made the old frame too small.
Why more context actively hurts
This is the part worth internalising, because it explains behaviour that otherwise looks like the model being lazy or forgetful.
Anthropic describes an attention budget: "LLMs have an 'attention budget' that they draw on when parsing large volumes of context." Every token drawn into the window spends some of it. The measured consequence is blunt:
"As the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases."
The published name for this is context rot. The mechanism is architectural — transformers relate every token to every other token, so the same finite capacity gets stretched across more and more material as the window grows.
So the document you added "just in case" is not free. It competes for attention with the instruction you actually care about. A window stuffed with everything relevant performs worse than a window holding only what this step needs.
The four levers
Anthropic's guidance is practical, and it comes down to four places where the decision gets made.
The system prompt, at the right altitude
Two failure modes sit on either side of a narrow target.
Too specific: "engineers hardcoding complex, brittle logic in their prompts to elicit exact agentic behavior." This works on the cases you thought of and breaks on the first one you did not, and every fix makes it more brittle.
Too vague: "vague, high-level guidance that fails to give the LLM concrete signals for desired outputs or falsely assumes shared context." That last clause is the one that catches people — falsely assumes shared context is what happens when you write instructions the way you would brief a colleague who already knows how your company works.
The target is "specific enough to guide behavior effectively, yet flexible enough to provide the model with strong heuristics."
The tool list
Tools should be "self-contained, robust to error, and extremely clear with respect to their intended use." The named failure is "bloated tool sets that cover too much functionality or lead to ambiguous decision points about which tool to use."
Every tool definition also sits in the window permanently, spending attention budget on every single turn. A tool the agent uses twice a month is not free — you pay for it on every request.
Just in time, not up front
This is the lever with the biggest practical payoff and the one most systems get wrong.
Instead of pre-loading everything an agent might need, keep lightweight identifiers — "file paths, stored queries, web links" — and let the agent load the contents at runtime when a step actually calls for it.
The comparison Anthropic draws is to how people work: you do not memorise the filing cabinet, you keep an index and open the drawer when you need it.
Long tasks: compaction, notes, subagents
When a task outruns the window, three techniques apply. Compaction — summarise and restart the window, "preserving architectural decisions, unresolved bugs, and implementation details while discarding redundant tool outputs." Structured note-taking — write notes to memory outside the window and read them back. And subagents, which explore in their own window and return one to two thousand tokens of conclusion.
Note what those three have in common. Every one of them is a way of throwing context away while keeping the part that mattered.
Where this connects to everything else
Read across the last few pieces and the same discipline keeps appearing under different names.
Subagents work because each gets a clean window and returns a summary — that is context engineering with a process boundary around it. Splitting agents by role instead of by context fails for exactly the reason described here: it moves material without curating it.
An LLM wiki is context engineering with a memory. The reason the pattern beats stateless retrieval is that it decides once what the durable, high-signal version of a fact is, instead of reassembling it from fragments on every question.
And the Firefox pipeline worked because the model could discard its own wrong guesses automatically — the cheapest possible form of keeping noise out of the window.
What to ask if someone is building this for you
"What is in the context window at each step, and who decided?" If nobody can answer, nobody is doing context engineering — the window is whatever the framework happened to put there.
"How many tools can the agent choose between?" A long list is a warning sign, both for cost and for the ambiguity it creates.
"What happens on a long task?" If the answer is that it eventually gets confused, there is no compaction or note-taking strategy, and the system will work in a demo and fail on real work.
"Is anything pre-loaded that could be fetched instead?" Usually yes, and it is usually the fastest improvement available.
The honest summary
Context engineering sounds like a new specialism and it is mostly an old discipline with a new name: deciding what matters and leaving the rest out.
The reason it has a name now is that agents made the cost visible. In a single-turn chat you could get away with dumping everything in, because there was one turn. In a loop that runs twenty steps and calls tools at each one, the window fills with material nobody chose, the attention budget drains, and the system quietly gets worse at the exact moment the task gets interesting.
More context is not more capability. It is more competition for the same finite attention. The work is deciding what earns its place.
Frequently asked questions
What is context engineering?
Anthropic defines it as the set of strategies for curating and maintaining the optimal set of tokens during inference. In practice it means deciding what is in the model's window at each step of an agent loop — the system prompt, the tool definitions, the retrieved documents, the history — and, more importantly, what is kept out.
How is context engineering different from prompt engineering?
Prompt engineering is about writing and organising instructions for a single task. Context engineering is about managing the whole window across many turns, where the model is repeatedly deciding what to do next and each step adds material. The shift happened because agents run in loops: writing one good instruction stopped being the hard part once the loop started filling the window with tool output.
Why does adding more context make results worse?
Because models have what Anthropic calls an attention budget, and it depletes as tokens accumulate. The published effect is that as the number of tokens increases, the model's ability to accurately recall information from that context decreases. Transformers relate every token to every other token, so a longer window stretches the same finite capacity across more material.
What is just-in-time context?
Instead of loading every document an agent might need into the window up front, you keep lightweight identifiers — file paths, stored queries, links — and let the agent fetch the contents at runtime when a step actually calls for them. It mirrors how a person works from a filing system rather than memorising the filing cabinet.
What does this mean if we are buying an AI system?
Ask what is in the context window at each step, and who decided. If the answer is that everything relevant is loaded up front, you are buying a demo. Ask how the system prompt was written, how many tools the agent can choose between, and what happens to the window on a long task.
About the author
Filip has spent his career between media and technology — filming for ŠKODA, Pilsner Urquell and Range Rover, then co-founding a startup in San Francisco, working with a YC-backed company and serving as CIO at Renato. He built ZEUS Legal AI and now runs the systems Salamon Capital operates on.