What is context engineering?
Context engineering is the discipline of managing what a model sees. It covers what gets retrieved, what gets kept, what gets summarized away, and what gets pushed out of the window entirely. For agents that run many turns, it is the largest single lever on reliability.
The term arrived because prompt engineering stopped describing the actual work. When a system was one instruction and one response, phrasing that instruction well was most of the job. An agent running fifty turns, calling tools, retrieving documents, and accumulating history has a different problem: at every step, something has to decide what goes into the window and what does not.
So the relationship is containment rather than replacement. Prompt engineering asks how to phrase an instruction. Context engineering asks what should be in the window at all. Wording still matters, and on a long agent run it is a small share of the variance compared with what surrounds it.
The reframe that makes the discipline tractable is to stop thinking of the window as storage. A context window is not a container you fill to capacity; it is a budget you allocate. Every token competes with every other token for a finite amount of the model's attention, which means adding something relevant can still make the output worse by displacing something that mattered more.
The metric that matters is context precision, not context size. Teams instinctively measure how much they can fit and how large a window a model advertises. The useful measure is what proportion of the tokens in the window are actually load-bearing for the current step. A run that fills two hundred thousand tokens to answer a question that needed four thousand is not using a capability. It is paying for latency, cost, and degraded attention.
Why does more context make an agent worse?
Because model performance degrades as input length grows, an effect now called context rot. Controlled studies show accuracy declining steadily as token count rises across every major model, even inside advertised limits and even when the relevant information is present in the window.
This is the empirical finding that turned context engineering from a style preference into an engineering discipline, and it is worth understanding precisely because it contradicts the intuition that larger windows solve the problem.
- Attention is finite and shared. Every token in the window competes for the model's attention. Doubling the input does not double the model's capacity to attend to it, so precision falls as the window fills.
- Position matters, and the middle is worst. A long-standing bias means information placed in the middle of a long context is recalled less reliably than material at the beginning or end. Where something sits is a design decision, not an accident.
- A larger window is not a fix. A million-token limit describes what the model will accept, not what it will use well. Filling it degrades quality while increasing both cost and latency, which is the worst combination available.
- Irrelevant content is not neutral. This is the counterintuitive part. Adding material that does not help is not free; it actively competes with material that does, so a retrieval step that returns ten documents where two were relevant has made the task harder.
The practical consequence is that the discipline is subtractive. Most teams arrive at context engineering looking for better retrieval and discover the larger win is in aggressive removal: trimming raw tool output, dropping resolved sub-tasks, and summarizing history that no longer bears on the current step.
What competes for the context window?
Seven claimants compete: system instructions, tool definitions, retrieved documents, conversation history, memory, examples, and the output schema. Only two of them grow without limit unless something stops them, and those same two are where almost all context bloat actually originates.
Naming the claimants makes the allocation visible. Most teams have never audited what is actually being sent to the model on a real task, and the audit is usually surprising.
| Claimant | What it is | How it behaves | Control |
|---|---|---|---|
| Instructions | The system prompt: role, constraints, policy | Fixed, and usually smaller than teams assume | Edit rarely; it is not the bloat |
| Tool defs | Schemas for every tool the agent may call | Grows with the tool count, silently | Scope tools per task, not per agent |
| Retrieved | Documents, records, and tool output pulled in | Unbounded. The largest source of bloat | Retrieve less, trim raw output hard |
| History | Prior turns in the current run | Unbounded. Grows every single turn | Compact on a threshold, not at the limit |
| Memory | Facts carried across runs or sessions | Accumulates unless curated | Select the slice this step needs |
| Examples | Demonstrations of the desired behaviour | Fixed, and often stale | Fewer and better beats more |
| Output schema | The structure the response must follow | Fixed and small | Leave it alone |
The two highlighted rows are the ones worth instrumenting first. Retrieved content and conversation history are the only claimants with no natural ceiling, and in most production agents they account for the large majority of tokens. The system prompt, which is where teams instinctively look when a run gets expensive, is almost never the problem.
What are the four ways context fails?
Poisoning, distraction, confusion, and clash. The taxonomy comes from Drew Breunig and has become the standard framing in the field. Three of the four degrade quality visibly and clear when the window is trimmed. The first corrupts silently and persistently, which makes it the one that matters most.
Knowing which failure you have determines which remedy applies, and the four are commonly conflated into a general sense that the agent has become unreliable.
| Failure | What happens | Why it is hard to spot | Primary remedy |
|---|---|---|---|
| Poisoning | A false fact enters the context and is treated as true from then on | It looks like every other fact in the window, and is reinforced each time it is read | Validate what enters durable context, especially summaries and tool output |
| Distraction | Accumulated context pulls the model away from the current task | The output is reasonable, just about the wrong thing | Compress history and drop resolved sub-tasks |
| Confusion | Superfluous content influences the response in ways nobody intended | No single piece looks wrong; the aggregate is noisy | Select less, and scope tool definitions per task |
| Clash | Contradictory information sits in the window at once | The model picks one and does not flag the conflict | Isolate work into separate windows |
Poisoning deserves the emphasis for a specific structural reason. The other three degrade the current step and clear when the window is trimmed. A poisoned fact propagates: it gets written into a summary, the summary gets compacted into the next summary, and the false claim survives every compression because it is indistinguishable from a true one. Compression is the mechanism by which poisoning becomes permanent, which is why validating what enters a summary matters more than validating what enters the window.
How do you manage context over a long agent run?
Four operations, now the standard frame: write context out to storage, select the slice each step needs, compress what remains, and isolate work into separate windows. Production agents combine all four rather than picking one, and the hard judgement sits in compression.
This factoring comes from LangChain's synthesis of practice across several agent teams and has become the common vocabulary. Each operation solves a different part of the allocation problem.
-
Write: put it somewhere other than the window
Persist information outside the context so it survives pruning. The common pattern is a scratchpad the agent maintains during a task, holding progress, intermediate results, and decisions. Anything written out can be retrieved later, which converts a capacity problem into a retrieval problem.
-
Select: pull in only what this step needs
Retrieve the relevant slice rather than everything available, and do it per step rather than once at the start. Just-in-time retrieval keeps the window small and has the side effect of making each step's context auditable, because you can say what the agent was looking at when it decided.
-
Compress: reduce what is already in the window
Summarize resolved turns, trim raw tool output, and drop finished sub-tasks. Long-running agents commonly compact automatically when the window approaches a threshold, replacing the raw transcript with a summary of decisions made, facts established, and open questions.
-
Isolate: give separate work separate windows
Split a job across sub-agents or sandboxed steps so one task's accumulated noise never reaches another's window. A supervisor decomposes the work, each worker gets a narrow context, and workers return summarized outcomes rather than their full trajectories. Multi-agent architecture is, among other things, a context isolation strategy.
Compression is where the judgement sits
The other three operations are largely mechanical. Compression requires deciding what the agent will still know afterwards, and getting it wrong is expensive in a way that does not surface immediately. A summary that drops the one identifier that turns out to matter three steps later produces a failure with no obvious cause, because the information was present earlier in the run and is simply gone.
Two practices reduce that risk. Preserve concrete artifacts verbatim rather than paraphrasing them: identifiers, file paths, amounts, dates, and decisions. And compact on a deliberate threshold rather than at the limit, so compression is a designed step rather than an emergency one.
There is a governance consequence too, and it is rarely mentioned. What survives compaction determines what the agent can later be held to. If a summary drops the approval reference under which an action was taken, the agent's working context and the audit record now disagree about the basis for that action. The record is authoritative, and the agent is operating on something else.
Why is context engineering also a security discipline?
Because the context window is where instructions and data share a channel. Retrieved content that improves accuracy arrives through the same path an attacker uses, which means a retrieval pipeline tuned purely for relevance will happily admit a hostile document, precisely because it is relevant.
This is the connection the two literatures do not usually make. Context engineering is discussed as a performance discipline and prompt injection as a security one, and they are describing the same surface from opposite ends.
The clearest way to see it is to hold the two taxonomies next to each other. Context engineering calls it poisoning: a false fact enters the window and is treated as true from then on. Security calls it indirect prompt injection: adversarial content embedded in material the system retrieves. These are the same event. One community describes it as a quality failure with an accidental cause and the other as an attack with a deliberate one, and the mechanism, the propagation, and the remedy are identical.
Context poisoning is prompt injection that succeeded and persisted. A poisoned fact does not just affect the current step. It gets written into a summary, the summary is compacted into the next one, and the false claim survives every compression because nothing distinguishes it from a true one. That means the compression machinery built for efficiency is also the mechanism that makes a successful injection durable. Anything that enters long-lived context deserves the scrutiny you would apply to code, not the scrutiny you apply to a search result.
Three practical consequences follow, and they change how a context pipeline should be built.
- Relevance is not trust. A retrieval system optimizes for similarity to the query. An attacker who wants their content retrieved writes content that is highly relevant. Ranking cannot separate the two, so provenance has to: know which source each piece of context came from and how much authority that source has.
- Validate what enters durable context, not just what enters the window. Transient context clears. Summaries, memory, and scratchpads persist and are trusted by later steps, which makes them the higher-value target and the one usually left unguarded.
- Isolation is a security control as well as a quality one. Giving a sub-agent a narrow window limits distraction and simultaneously limits what a compromised step can reach and contaminate. The same architectural move pays twice.
For the attack itself see prompt injection, and for the controls that constrain what an agent can do once its context is compromised see AI guardrails. The upstream question of whether the data being retrieved is even unambiguous is covered in data intelligence.