The Smart Zone, the Dumb Zone and Poisoned Context

Every technique in the four pillars — writing, selecting, compressing, isolating — exists because of one inconvenient property of the machinery underneath: a context window is not a bucket that works equally well at every fill level. It is a resource that degrades in use. The million-token headline number on a model card tells you where the window ends; it tells you nothing about where it stops being good. This part is about that gap — how much of it is measured, how much is practitioner folklore, and what happens to the sessions that ignore it.

The budget nobody itemises

Anthropic's engineering guidance opens with the sentence I would put on the wall of any team running agents: "Context is a critical but finite resource for AI agents." My own blunter shorthand for the same idea — and I want to be clear this phrasing is mine, not theirs — is that intelligence is no longer the bottleneck; context is. The models crossed the capability threshold for most day-to-day engineering work some time ago. What separates a productive agent session from a wasted one is almost never how clever the model is. It is what the model was given to look at, and how much junk was in the way.

Finite would be manageable if the cost were linear — token in, small fee out. It is not. As a window fills, the model's ability to attend to any one piece of it erodes. The relevant fact is buried in a growing haystack, and retrieval from within the window is exactly the thing that long-context models are worst at. Practitioners call the phenomenon context rot, and it is the well-evidenced part of this story.

What the needle-in-a-haystack numbers actually show

The cleanest public evidence comes from long-context retrieval benchmarks, and one figure is worth quoting precisely because both halves of it matter. On the 8-needle 1M-token variant of MRCR v2 — a benchmark that asks a model to retrieve multiple specific items scattered through a million tokens of distractor text — Sonnet 4.5 scored 18.5%, a result Anthropic reported in its own Claude Opus 4.6 announcement in February 2026, where Opus 4.6 scored 76% on the same test.

Read both numbers, as of that release. The 18.5% says that a genuinely capable model — one that writes production code all day — could fail more than four times out of five at finding several needles in a full million-token haystack. That is context rot made visible: the window technically holds the information; the model cannot reliably use it. The 76% says the frontier moves, and fast — which is why I am time-stamping this paragraph rather than carving it in stone. But notice what even the better number concedes: a quarter of the needles still lost, on a task that is pure retrieval with none of the reasoning load of real work. The direction is not in dispute. Fuller windows are dumber windows, and the newest model buys you slack, not immunity.

One team's line in the sand

So where does “good” end? Here is where the honest ledger matters, because the most quotable answer in circulation is not a benchmark result.

Dex Horthy and the HumanLayer team argue that beyond roughly 40% context-window utilisation, output quality degrades — and their entire working method is built around staying under that line. Below it, in their framing, the model has room to think: the smart zone. Above it, every additional token competes with the task itself: the dumb zone.

I want to be precise about the claim's status, because I have watched the number harden into fake science as it travels. The 40% figure is one experienced team's working heuristic, not a measured threshold — nobody has published a curve with a knee at 40%, and the true degradation point surely varies by model, task and the composition of what is in the window. What the heuristic has going for it is that it points the same direction as the evidence that is solid: the MRCR-style results above, and Anthropic's finite-resource framing. Treat 40% the way you treat a colleague's “never let the disk pass 80%” — not a law of nature, but a defensible place to draw a line you were right to draw somewhere.

The practical consequence is the same whichever number you pick: the moment to compress is long before the tool forces you to. A session that coasts to 95% utilisation and then auto-summarises has spent most of its life in the dumb zone. The teams that get consistent results run the opposite pattern — small windows, frequent intentional resets, sub-agents absorbing the exploratory mess — so the main line of work never leaves the smart zone at all.

Poisoned context - when the problem is not the amount

Fill level is only half the failure surface. A half-empty window can still produce garbage if what is in it is wrong, and this failure mode — context poisoning — is nastier than rot because it does not announce itself with a gauge. Three sources account for nearly every poisoning I have had to debug.

Stale documentation. The standing context file that describes how the system used to work. The onboarding doc praising a module that was deleted in March. Written context ages the moment the code moves, and an agent has no way to know the description is out of date — it will confidently build against the architecture you had last year. The mitigation follows from the layering: the closer information sits to the code, the less chance it has had to drift. Function names and the code itself cannot lie about the present; comments can; external documents usually do, eventually. When implementation understanding matters, derive it fresh from source rather than trusting a written account of it.

Accumulated errors. A conversation that contains three failed attempts and three corrections is not a neutral record — it is training data for the next turn. The model continues the pattern the history exhibits, and if the pattern is try, fail, get corrected, the most statistically plausible continuation is another failure. This is why pruning resolved errors is not tidiness but self-defence, and why the strongest move after a derailed stretch is not a fourth correction but a fresh window seeded with a clean compaction artefact. Do not negotiate with a bad trajectory; abandon it and keep what it taught you.

Conflicting instructions. Two context files that disagree — the root conventions say one error-handling style, a directory-level file says another; an old plan contradicts a new decision that never got written back. The model does not adjudicate the way a person would. It oscillates, satisfying whichever instruction is nearer the surface on a given turn, and produces work that is inconsistent in a strangely faithful way: every contradiction in the context reappears as a contradiction in the output. The fix is unglamorous ownership — one source of truth per rule, and retiring superseded instructions with the same seriousness as deleting dead code.

Notice what the three have in common: none is a model failure. Each is an input failure that the model then amplifies with perfect diligence. An agent does not get confused the way people do; it gets exactly as confused as its context is. That is the most useful diagnostic sentence I know for agent work — when the output is wrong, read the window before you blame the weights.

Living inside the budget

Pull the threads together and the operating doctrine is short. The window degrades before it fills, so compress early and on purpose. The threshold numbers in circulation are heuristics, so hold them loosely — but hold one, because the direction is measured even where the line is folklore. And watch composition as closely as volume: stale, contradictory or error-laden context will poison a session that the fill gauge says is healthy.

What this doctrine wants is a workflow shaped around it from the start — one that structures an entire task as a sequence of small, clean windows instead of one long degrading conversation. That workflow exists, and it has the least mystical name in the field. Next, Research, Plan, Implement.