Real mitigations actively shrink or filter the context: sliding window, summarisation, and pruning. A bigger window or disabling retries does not fix the underlying noise.
Imagine a detective's desk that fills with notes as a case drags on. Every lead, every dead end, every coffee-stained scribble piles up. Soon the desk is so cluttered the detective wastes time re-reading junk and misses the one note that matters. To stay sharp they can keep only the newest pages, rewrite the old ones into a tidy summary, or throw out notes that turned out to be irrelevant. What does not help is buying a bigger desk. The clutter just spreads to fill it, and the useful fraction stays just as low. An agent's context window is that desk. The fix is to manage what sits on it, not to make it larger.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Context pollution, sometimes called context rot, is the slow decay of an agent's working context as a loop runs for many steps. Every iteration appends material: the model's reasoning trace, the tool call it chose, the raw observation that came back, and any error text. None of this is wrong to keep in the short term. The problem is cumulative. By turn thirty the window is dominated by stale observations and dead-end branches that no longer bear on the current sub-goal.
The critical insight is that pollution is a quality problem, not a quantity problem. The danger is the falling ratio of useful tokens to total tokens, not the absolute token count. A model reading a polluted context attends across far more irrelevant material, recall sags in the middle of long inputs, and decisions on later steps get measurably worse even though no exception ever fires. That is why the fix is hygiene, not capacity.
This question is really a category test. Three of the five options are content-management techniques that lower the stale-token ratio. The other two are imposters that either change capacity instead of content, or solve a different problem entirely. Understanding why each imposter fails teaches the underlying principle far better than memorising the three right answers.
Why a bigger window is not the answer
The most tempting wrong answer is to simply use a model with a larger context window so every step always fits. This conflates capacity with quality. A larger window changes how much can accumulate before a hard overflow, but it does nothing to the proportion of stale, noisy, or contradictory material the model must read on each turn. If a transcript is twenty percent signal at a hundred thousand tokens, it will still be roughly twenty percent signal at two hundred thousand tokens. The disease is unchanged; only the symptom of overflow is postponed.
Worse, long-context models do not attend uniformly. Recall degrades for information buried in the middle of a long input, a well-documented effect. So as the polluted transcript grows to fill the bigger window, the very content the agent needs is increasingly likely to sit in the low-recall zone. The window grew, the problem grew with it, and the agent is arguably worse off, because now the critical early goal is even deeper in the dead zone.
There is also a cost dimension. Most APIs bill per input token, so feeding a bloated context on every turn makes each step more expensive, and the spend compounds with the step count. A bigger window encourages exactly the lazy append-everything pattern that drives that bill up.
A bigger window is still useful as headroom. It buys time before you must compress, and it lets you keep more genuinely relevant detail when the task warrants it. But it is a complement to active context management, never a substitute for it.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Strategy | Mechanism | Main cost | Genuine mitigation |
|---|---|---|---|
| Sliding window | Keep recent N steps | Forgets early constraints | Yes |
| Summarisation | Compress old steps every K turns | Extra LLM call, lossy | Yes |
| Selective pruning | Drop low-relevance entries | Needs a relevance signal | Yes |
| Bigger window | More capacity | Noise still accumulates | No |
| Disable retries | Fewer failed calls stored | Breaks error recovery | No |
Real products, models, and research that use this idea.
- Claude Code compacts long sessions by summarising earlier turns into a condensed memory block once the transcript nears the window limit, then continues with that summary plus recent turns.
- LangGraph exposes a state reducer and trimming hooks so a ReAct loop can apply a sliding window or summarise old messages between iterations.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you protect the original goal and hard constraints when using a sliding window that forgets early turns?
Pin a small immutable system block holding the goal and constraints outside the windowed region, so trimming only ever touches the rolling action and observation history, never the anchor.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Assuming a larger context window solves pollution. It only postpones the overflow while the noise ratio keeps climbing, so the model still drowns in stale steps.
60 second bullets to scan on the way to the call.
Define context pollution as a signal to noise problem, not a capacity problem.
Name the three active mitigations and how each reduces stale content.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.