PMaker home
Noise accumulates with each step, models do not degradeBloatRaw output enters context in fullHistory eats the budget earlyDilutionUseful instructions fall to 10%Argument error rates climbCorruptionCorrected errors stay in contextRetries push bloat back upAnxietyModel wraps up and declares doneWork ends before it is finishedMeasure context noise before changing models

Noise compounds; intelligence does not suddenly vanish.

How Context Gets Dirty

An agent rarely gets stupider mid-run. Noise accumulates as a share of context, so diagnose context quality before you shop for a bigger model.

An agent drifting off course has rarely gotten stupider. What happens is that noise grows as a share of context: clean at step three, buried by step eight, largely unusable by step fifteen. So when quality degrades, diagnose context first and consider a larger model second. Reverse that order and you spend two weeks buying a zero.

Measure the noise before you change the model

The Qwen platform team produced a hard-to-argue-with comparison. The same skill performed well at three steps, degraded noticeably at eight, and was nearly unusable at fifteen; swapping in a larger model changed nothing. They then spent two weeks evaluating bigger models with no metric movement, and one week on context management for a 40% gain. qwen-harness

Worth putting on the wall: do not use a bigger model to hide an engineering problem. Model capability is the multiplier and context quality is the multiplicand. When the multiplicand approaches zero, swapping multipliers buys nothing.

The diagnostic is mechanical. Dump the prompt at each step, count tokens by source, and compute the share the current step actually uses. Then decide what to change.

Dilution at 70/20/10

The step-by-step dump is stark. By step eight, 70% of the context was raw JSON from earlier tool calls, 20% was conversation history, and only 10% was instructions the current step needed. Physical capacity of 128K is not usable capacity: 128K that is 70% noise performs worse than a carefully managed 32K. qwen-harness

Worse, it feeds itself: bloat, then dilution, then rising argument error rates, then more retry messages, then more bloat. Each step adds noise to the next, so the decay curve accelerates rather than staying linear. Step five looks fine; step ten is already past saving.

There is also a positional effect. Attention is not uniform across the window: it is strongest at the beginning and end and weakest in the middle. A rules file injected at the top sinks into the middle as the session grows, and violations you already corrected reappear in the tail of long sessions.

The measured gap between compression strategies

One task, one budget, six strategies; four of them are enough to show the spread. The task was to track where a group of co-founders ended up professionally: several search rounds, each returning anywhere from a few thousand to over a hundred thousand characters. Capping a model with a native million-token window at a 128K budget is what forces the compressor to matter ai-agent-book:

Strategy Ratio Steps Total tokens Outcome
No compression 5 about 165,000 accumulated Overflow guard trips, task fails
Summarize each result alone 10.9% 12 276,608 Completes; the same event described by several pages, repeatedly
Summarize everything together 4.3% 10 93,449 Completes; must truncate the tail once input is long
Context-aware compression 3.0% 7 40,157 Completes; names and role changes still present

Ratio here is compressed size over original size, so smaller means more aggressive. What separates these rows is not aggression. It is whether the compressor was told what the task is looking for. A per-result summarizer sees one segment at a time and squashes each symmetrically; the context-aware version gets the current query intent and what has been gathered so far, and total spend falls from 276,608 tokens to 40,157 while the step count falls from twelve to seven.

Two misconceptions die in this table. Compression is not only about length — better thinking and less context anxiety are the other two motives, and length is the shallowest. And "too full" is not the same failure as "full enough to lose the thread": overflow trips a guard and announces itself, whereas dilution raises no error at all. It just moves your argument-error rate up a little each step.

Corruption: corrected errors are still in there

Tool errors that the agent has already fixed stay in context and keep steering later decisions. Cursor calls this context corruption: tools are the most defect-prone surface an agent touches, and accumulated errors degrade later decisions, sometimes stalling the agent and sometimes sending it completely off the rails. cursor-agent-harness

What works is classifying errors by cause. InvalidArguments and UnexpectedEnvironment mean the model was wrong. ProviderError means the tool's service is down. UserAborted and Timeout are environment conditions. Then compute baselines per tool per model and run anomaly detection, alerting when the unknown-error rate crosses a threshold. A single global baseline misses things, because normal error rates differ by orders of magnitude across tools and models. One focused sprint brought their unexpected tool errors down by an order of magnitude.

Anxiety: compaction does not fix it

Claude Sonnet 4.5 showed a specific long-run behavior: as the window filled, it started wrapping up early and finishing work carelessly, even when the task was nowhere near done. This is context anxiety. The model senses the window is nearly full and prefers to wrap up over pushing forward. anthropic-long-running

The important judgment: compaction does not solve it. Summarizing history in place just compresses the noise more densely. It never gives the model a clean start, so the anxiety remains. What works is a context reset: clear the window, start a fresh agent, and pass state forward through a structured handoff artifact.

Hold on to the counterexample too. Opus 4.5 eliminated the behavior on its own, at which point the reset became pure overhead. Assumptions encoded in a harness go stale as models improve, which means you have to periodically revisit why that logic exists.

The cost and how to check

The price of this diagnosis is observability: token accounting by source, error classification with baselines, per-step prompt dumps. Short tasks do not justify it.

Three questions localize the problem quickly. At step ten, what share of the context does the current step actually use? Does each tool-model pair have an error-rate baseline? When the agent declares completion, is that a judgment or is it afraid of running out of window?

References

  1. From Prompt to Harness: the evolution of enterprise Agent engineering
  2. Continually improving our agent harness
  3. Harness design for long-running application development
  4. AI Agents in Depth, Chapter 2: Context Engineering