An agent an hour into a task starts repeating a mistake it already fixed, forgets a constraint stated at the start, or re-reads a file it already read. The instinctive diagnosis is that the model got worse over the course of the session. Usually it didn't — the context window filled with the wrong things. A hundred lines of a file grep that turned up nothing, a full tool-call response that mattered for ten seconds, three abandoned approaches — all of that competes for the same finite space as the one constraint the user stated at the start. Managing the window well is a design problem, not a model problem, and it looks the same whether the window is 8K tokens or 800K: it just gets a longer runway before the mistakes start.
Treat context contents as three different categories, because they decay at different rates. Decisions and constraints — what the user asked for, what approach was chosen and why, what's explicitly out of scope — are cheap to state and expensive to lose; they belong near-permanently. Raw tool output — file contents, command results, search hits — is expensive to keep and usually only useful for the next step or two; once its conclusion has been extracted, the raw form is dead weight. Exploration and dead ends — the approach that got tried and abandoned — has a shelf life of "long enough to not retry it," not the whole session. Conflating these three into one growing transcript is what causes both failure modes: important constraints get buried under exploration, and stale tool output gets treated as if it's still authoritative.
| Weak pattern | Stronger equivalent |
|---|---|
| keeping every tool call's full raw output in context for the rest of the session | extracting the one or two facts that mattered, then letting the raw output age out |
| letting a stated constraint compete for space with a page of exploration that followed it | re-stating active constraints in a running summary that gets refreshed, not just written once |
| truncating from the oldest message forward when the window fills | summarizing dead-end exploration first, since it's the least likely thing to be needed verbatim later |
| one undifferentiated transcript for the whole session | separating "what we decided" from "what we tried" so the first survives compaction the second doesn't |
| assuming a bigger context window removes the need to manage this | treating window size as runway, not a fix — the same crowding happens later, not never |
Compaction done under pressure, at the moment the window is nearly full, tends to be crude — cut the oldest half, keep the newest half — because there's no time to be selective. Compaction done proactively, at a natural checkpoint (a subtask finished, a decision made, a dead end confirmed), can be much more precise: fold the resolved exploration into one sentence, keep the decision and its reasoning in full, and discard the raw evidence that led to it. The difference isn't cosmetic — a crude compaction can silently drop the one constraint that happened to fall in the "oldest half," while a deliberate one is choosing what to drop with the actual content in view.
Before concluding "the model can't do this," check whether the fact it needed was still in context, stated recently enough and prominently enough to compete with everything else present. A constraint mentioned once, forty tool calls ago, buried under three pages of file listings, has effectively been forgotten even though it's technically still in the transcript — that's a context-management failure, not a reasoning failure, and the fix is re-stating or restructuring, not a bigger or better model. Reserve "capability problem" for cases where the relevant information was prominent, recent, and unambiguous, and the agent still got it wrong.
The test to apply mid-session: pick the constraint the user cares about most, and check whether it's still stated somewhere recent and prominent, or whether it's technically present but buried under a thousand tokens of resolved exploration. If it's buried, the session doesn't need a bigger window — it needs a summary written now, before the next crowding failure happens.
Related: writing tool descriptions agents actually use correctly — a different kind of clutter, the same underlying lesson that ambiguity gets resolved the same wrong way every time. Also related: designing persistent memory for agents, the same "what deserves to survive" question applied across sessions instead of within one.
Context crowding wastes tokens; it doesn't necessarily stop the task. A stuck loop wastes both tokens and money without ever finishing — see cost and token budgets for autonomous agents.
This guide is about what an agent does with tool output already sitting in its context. A tool can also make that job easier or harder before the output ever arrives — see sizing tool output for agents for the source-side decision of how much a call should return in the first place.