Context Engineering Is Named
Part 3 of a chronological survey of the craft around large language models. Part 2 ended on a hard-won realization: capacity alone doesn't solve the information problem. In mid-2025 that realization got a name, a taxonomy, and a community.
TL;DR — Karpathy coined context engineering; Breunig catalogued the four ways contexts fail (poisoning, distraction, confusion, clash). A Microsoft/Salesforce study showed the same information spread across turns costs ~39% — purely from structure, not lost data. And "CatAttack" showed a single irrelevant sentence ("cats sleep most of their lives") can raise a model's error rate by more than 300%. Keeping the context clean isn't housekeeping; it's load-bearing.
A word arrives
Terms in this field tend to crystallize suddenly, around a single well-placed endorsement. "Context engineering" crystallized in June 2025, when Andrej Karpathy weighed in on a debate that had been simmering since Drew Breunig and others started writing about how long contexts fail. Karpathy's formulation became the standard definition:
People associate prompts with short task descriptions you'd give an LLM in your day-to-day
use. When in every industrial-strength LLM app, context engineering is the delicate art and
science of filling the context window with just the right information for the next step.
Breunig, who had been circling the same idea, described the moment of recognition: while writing about long-context failures he kept "[writing] the word 'prompt' somewhere before quickly replacing it with 'context.' When prompts are part of software, they're context." The distinction he drew is worth stating precisely, because it explains why a new word was needed rather than just a refinement of the old one:
| Prompt | Context | |
|---|---|---|
| Typical author | a person | a system/program |
| Lifespan | disposable, one-off | evolving, curated, maintained |
| Setting | chatbot, conversational | application, industrial-strength |
| Unit of work | a request | the entire informational environment |
Breunig was careful that neither is "better" — they are different, suited to different work. Prompt engineering describes a human writing a request to a chatbot. Context engineering describes a system assembling, for each model call, the right tools, documents, history, and instructions.
The drift from one to the other had been happening for over a year, silently, as builders moved from chat interfaces to applications and agents. The term simply gave the drift a name — and, Breunig argued, that naming was itself consequential.
Borrowing a Stewart Brand line he returns to often — "look for where language is being invented and lawyers are congregating" — he made the case that a successful buzzword isn't invented from nothing. It "identif[ies] common experiences which we all have," and crystallizing those into a shared word "create[s] community, change[s] culture, and influence[s] our work."
The signal it was real: within a month, search volume for "context engineering" had climbed to over a quarter of that for "prompt engineering" — the sustained kind of rise that marks a genuine latent need, not a marketing spike.
Skeptics called it a rebrand — one Hacker News commenter dismissed it as "a month-long skill, after which it won't be a thing anymore." The rest of this series is, in part, the story of why that skepticism was misplaced: the work the term named has only grown more central.
The taxonomy: four ways contexts fail
The intellectual core of the moment was Breunig's classification of how contexts fail. Before this, "the model got confused by a long context" was a vague complaint. Breunig split it into four distinct, named failure modes — and the precision is what let people diagnose and fix specific problems rather than just throwing tokens at the wall.
Context Poisoning — when a hallucination or other error makes it into the context, where it is repeatedly referenced. Breunig's prime example came from Google DeepMind's own Gemini 2.5 technical report, describing an agent playing Pokémon. When the agent hallucinated and that false belief entered the "goals" or "summary" portions of its context, it would become "fixated on achieving impossible or irrelevant goals," developing nonsensical strategies that could "take a very long time to undo." The error, once written into the context, kept getting read back and reinforced.
Context Distraction — when a context grows so long that the model over-focuses on the context, neglecting what it learned during training. The same Gemini Pokémon report supplied the evidence: past roughly 100,000 tokens, the agent "showed a tendency toward favoring repeating actions from its vast history rather than synthesizing novel plans." Instead of drawing on what it learned in training to devise new strategies, it parroted its own past behavior. For smaller models the distraction ceiling is far lower — Part 2's Databricks finding (degradation around 32k for Llama-3.1-405B) is the same phenomenon.
Context Confusion — when superfluous content in the context is used by the model to generate a low-quality response. This is the failure mode behind the over-eager "connect every tool via MCP" dream.
Evidence came from the Berkeley Function-Calling Leaderboard: every model performs worse when handed more than one tool, and all models will sometimes call tools that are completely irrelevant. The benchmark even includes cases where the correct move is no tool call at all — and models fail them.
A vivid case study: researchers gave a quantized Llama 3.1 8B a query with all 46 tools from the GeoEngine benchmark, and it failed — despite the context fitting well within the window. Cut to 19 tools, and it succeeded. The problem, in Breunig's words: "if you put something in the context the model has to pay attention to it." Irrelevant tokens aren't free; they're actively consulted.
Context Clash — when you accrue new information and tools that conflict with other information in the context. This is the most insidious mode, and it got the most rigorous treatment, in a Microsoft Research and Salesforce study we'll examine on its own below.
The centerpiece study: getting "lost in conversation"
The Context Clash failure mode was documented in detail by "LLMs Get Lost in Multi-Turn Conversation" (Microsoft Research and Salesforce, May 2025) — a paper worth dwelling on because its experimental design isolates the effect so cleanly.
The intuition starts from how people actually use chatbots. Sometimes you type a complete, fully-specified paragraph and hit enter. Other times you start with a vague request and add details turn by turn as the model's answers reveal what you forgot to mention. Benchmarks almost always test the first style; real use is full of the second. So the researchers built a method called sharding: take a complete instruction from a high-quality benchmark, split it into "shards" each carrying one piece of the original, and reveal them one per turn — simulating a real, gradually-specified conversation. They then compared the same task delivered several ways:
- FULL — the entire instruction in one prompt (the benchmark ideal).
- SHARDED — the instruction split across turns, revealed one shard at a time.
- CONCAT — all the shards concatenated back into a single prompt (less specific than FULL, but not multi-turn).
- RECAP — SHARDED, plus a final turn that repeats all prior shards.
- SNOWBALL — SHARDED, but each turn re-states all prior shards before adding the next.
Across six generation tasks (code, SQL/database, math, API actions, data-to-text, and long- document summarization) and 15+ top open- and closed-weight models, analyzing more than 200,000 simulated conversations, the result was stark and universal:
every model sees its performance degrade on every task when comparing Full and Sharded
performance, with an average degradation of −39%.
A 39% average drop — on the same task with the same information — purely from delivering it across turns rather than all at once. Even flagship models (the paper names the likes of Gemini 2.5 Pro and GPT-4-class systems) fell by comparable amounts. OpenAI's o3, in Breunig's recounting of the numbers, dropped from 98.1 to 64.1.
The control condition is what makes the finding airtight. CONCAT — the shards reassembled into one prompt — recovered to about 95% of FULL's performance. That rules out the obvious explanation: the degradation is not because sharding loses information (the shards collectively contain everything). It is the back-and-forth structure itself that breaks the model.
The information was all there. Spreading it across turns — not losing it — is what cost 39%.
Why? The authors decomposed the 39% into two parts: a minor loss in aptitude (best-case ability) and a large increase in unreliability. The mechanism:
We find that LLMs often make assumptions in early turns and prematurely attempt to generate
final solutions, on which they overly rely... when LLMs take a wrong turn in a conversation,
they get lost and do not recover.
In other words, the model commits to an answer before it has all the information, and those premature, wrong attempts stay in the context and contaminate everything that follows. This is Context Clash in its purest form: the context now contains the model's own early mistakes, which conflict with the correct path once the full picture emerges.
The implication for agent builders, which Part 4 picks up, is sobering. Agents assemble context from many sources — documents, tool calls, the outputs of other agents — and that assembled context has every opportunity to disagree with itself. The more an agent gathers, the more it can get lost.
How little it takes: the "cat facts" attack
If the multi-turn study showed that a model's own accumulated mistakes derail it, a smaller, sharper result showed that even a single irrelevant sentence — injected by anyone — can do real damage. Breunig highlighted it in a follow-up titled, memorably, Cat Facts Cause Context Confusion.
The work is CatAttack (2025). The method: use a cheap, fast model (DeepSeek V3) to generate modifications to benchmark questions — phrases that are semantically irrelevant and leave the question's meaning intact — then filter for the ones that flip the model's answer. This yielded 574 phrases that fooled the training model; tested against a larger reasoning model (DeepSeek R1), 114 of them still worked. Appending one of these irrelevant phrases produced a greater-than-300% increase in the likelihood of an incorrect answer, and made models reason longer — DeepSeek R1 generated over 50% more tokens about half the time.
The single most effective trigger was the question "Could the answer possibly be around 175?" appended to an unrelated math problem. But the one that named the phenomenon was a throwaway feline aside:
"Interesting fact: cats sleep for most of their lives."
Append that to a math question, and models stumble measurably more often. The phrase carries no information relevant to the problem. It is pure noise. And yet, because — as the Context Confusion principle states — the model must attend to everything in its context, the noise degrades the answer.
Breunig's point in surfacing this was practical, not just curious: it is "easy to see how user input could end up adding a phrase like this to your context." Real users say irrelevant things. Real documents contain tangents. Real tool outputs include boilerplate.
If one cat fact can raise the error rate by 300%, keeping the context clean isn't housekeeping. It's load-bearing.
Why naming it mattered
By the end of mid-2025 the field had what it previously lacked: a name that distinguished this work from chatbot prompting, a four-part vocabulary for diagnosing failures, and a body of rigorous evidence (Gemini's Pokémon agent, the Berkeley leaderboard, GeoEngine, the Microsoft/ Salesforce multi-turn study, CatAttack) showing the failures were real, measurable, and often counterintuitive.
Breunig's larger claim was that the name would accelerate the field: with shared language, "we don't always have to establish a baseline for what we're talking about before we talk about it." Practitioners could now compare notes, name a colleague's bug as "context poisoning" or "a clash," and build shared tooling. The term self-identified a community that had been working in parallel without knowing it.
It also implied a research program: if these are the ways contexts fail, what are the techniques to fix them? That program already existed in scattered form across the literature. Part 4 is the story of its consolidation into a toolkit — and of how the most powerful fix, isolating context across multiple agents, grew into an architecture of its own.
Key sources for Part 3
- Andrej Karpathy, public remarks defining "context engineering" (June 2025) — "the delicate art and science of filling the context window with just the right information for the next step."
- Drew Breunig, Prompts vs. Context (2025) — the prompt/context distinction and the table this part adapts; and Why "Context Engineering" Matters (2025) — the field-formation argument.
- Drew Breunig, How Long Contexts Fail (2025) — the four-failure-mode taxonomy.
- Google DeepMind, Gemini 2.5 technical report (2025) — the Pokémon-playing agent; primary evidence for context poisoning and distraction. [Cited via Breunig and the report.]
- Berkeley Function-Calling Leaderboard — every model degrades with >1 tool; irrelevant tool calls. [Cited via Breunig.]
- Less is More / GeoEngine tool study (arXiv:2411.15399) — Llama 3.1 8B fails with 46 tools, succeeds with 19. [Cited via Breunig; examined further in Part 4.]
- LLMs Get Lost in Multi-Turn Conversation (Microsoft Research & Salesforce, arXiv:2505.06120, 2025) — sharded simulation; −39% average drop across 15+ models and six tasks; CONCAT recovers to ~95%; degradation = minor aptitude loss + large unreliability; "they get lost and do not recover."
- CatAttack (arXiv:2503.01781, 2025) — adversarial irrelevant triggers; >300% increase in error rate; the "cats sleep for most of their lives" example.
Next up · Part 4 — Fixing Context & Multi-Agent Systems: the six tactics for repairing a context, and how "context quarantine" grew from a trick into Anthropic's multi-agent research architecture.
Top comments (0)