Context Rot and Governing Context

Why long agent sessions degrade well before any token limit, and what part of that is yours to fix. The mechanism half is general to every frontier model; the practice half is written around Claude Code but the principles carry to any agentic tool.

Related: Claude Code Has Four Agent Modes (the subagent and agent-team remedies in depth) · Building-Claude-Code-with-Harness-Engineering (this is its “context preservation” layer) · AGENTS.md vs SKILLS.md in the AI Agents primer course (the compressed-index pattern, which is this problem solved for docs).

The one idea

Context is not storage. It is active input. Everything in the window shapes the next token, whether it is relevant or not. A session is a feedback loop — output becomes input — so a confused step doesn’t just sit there, it conditions every step after it.

That splits the problem in two, and only one half is yours:

• Intrinsic rot — a property of the architecture. The floor. Not promptable-around.
• Content rot — the stale, wrong, and contradictory material that accumulates in a session. Yours to manage, and where all the leverage is.

1. Intrinsic rot: why the floor exists

Worth understanding not to fix it, but because it explains why the practices below are shaped the way they are — and because it kills the intuition that there’s a little engineer back there accumulating an understanding of your project.

• Attention runs on a fixed budget. Each attention head scores how much every token should draw on every prior token, and those scores pass through softmax, which forces them to sum to one.

  • Because softmax is built on exponentials, no token’s share can ever reach exactly zero
  • So every irrelevant token in the window still takes a slice
  • Irrelevant context is never free — this is not an implementation bug, it’s the property that makes attention learnable

• What erodes is the margin, not the ranking. As context grows the model may still rank the right tokens highest, but the gap between the signal and the diffuse mass of everything else narrows. The read arrives blurred.

• Position matters, and the middle is the weak spot. Place a fact at varying positions in a long context and retrieval traces a U-curve — best at the very start and very end, worst in the middle (Liu et al., 2024).

  • In an hours-long session the broad middle is where most of your real content lives
  • It is not safe storage

• The stated limit is not a performance cliff. Erosion is gradual and starts early.

  • Vendor needle-in-a-haystack curves look flat because the task is easy — direct word overlap between question and answer
  • Strip that overlap so the model has to match on meaning (NoLiMa, Modarressi et al., 2025) and the drop arrives far earlier
  • Ask it to hold several facts and reason across them and performance degrades well inside the window even with perfect retrieval (Du et al., 2025)
  • A model that can find a fact at 100k tokens cannot necessarily think with it there

• The 2026 frontier models measure the same way, and the drop is not subtle. Figures reported by Kim and Hoekstra, Agentic Engineering (The System Design Newsletter, 2026-06-17):

  • GPT-5.5: 98.1% on short documents, 74.0% at a million tokens.
  • Claude Opus 4.7: 59.2% at 256K, falling to 32.2% at 1M — roughly halving across the top of its own advertised window.
  • ⚠️ The newsletter names no benchmark and cites no paper for these. They are consistent with the NoLiMa and Du results above and are recorded as corroboration, not as independently verified measurements. Chase them to source before quoting them to a customer.
  • The framing that travels best: “double the context, and each token’s share of that weight roughly halves” — the same softmax argument as the first bullet, in a sentence an audience can hold.

Working assumption: your useful context budget sits well below any stated limit.

2. Content rot: the four failure modes

Drew Breunig’s taxonomy, grounded in agentic coding. The article adds a fifth observation that matters more than any single mode.

• Confusion — loading too much into scope.
  • A bloated roster of tools, skills and MCP servers degrades tool selection, not just token count (Kate et al., 2025)
  • Models with many tools reach for them even when their own knowledge would do (Zeng et al., 2026)
  • An idle tool is not free — its definition sits in the window every turn whether you call it or not
• Clash — letting a debugging detour set the theory.
  • Models commit early to a reading and struggle to drop it
  • Tasks solved cleanly when handed everything at once get fumbled when the same information arrives muddled across turns (Laban et al., 2025)
  • The path itself becomes sticky
• Distraction — searching broad and pulling in look-alikes.
  • A wide grep drags in test fixtures, dead implementations, mocks, similarly-named functions
  • Models do not treat context as optional reference; they reliably incorporate it even when irrelevant (Shi et al., 2023)
  • A single topically-related distractor measurably drops performance (GSM-Symbolic, 2024) — and a codebase is full of them
• Poisoning — letting a wrong note harden into truth.
  • The agent records a finding in NOTES.md; you later correct it in chat but never update the file
  • The correction slides out of the window; the stale file is the version that survives
  • A note the model wrote is not evidence. It is a claim waiting to be confirmed. The failure is stale state, not state itself

They compound. A wrong note sends the agent searching for a fix that was never needed; the search drags in look-alikes; those suggest a fresh wrong theory; the detour to sort it out lays down another note. Mistakes don’t add up, they make the next one more likely.

And the model rarely hedges as it degrades. It builds on the error rather than flagging it, so a session deep in rot reads like a healthy one right up until the output breaks. It cannot see its own rot — correction has to come from outside the window.

3. The practice

Before the first prompt — curate

• A fresh start is worth more than any recovery path. The upfront investment is what makes a reset cheap, so it’s paid once and every reset after is close to free.
• Keep always-loaded context minimal and high-signal. Treat CLAUDE.md as the minimum required reading for a new engineer on day one — what they could not work out from the code alone.
  • Leave out anything inferable, anything that changes often, anything only sometimes relevant
  • General knowledge is wasted as context; the model already has it
• Move what you cut somewhere that loads on demand.
  • Procedures and domain knowledge → skills, dormant until invoked
  • Rules that must always hold → hooks, which run outside the session context
• Audit what’s in scope. /mcp and /skills — disable what this task doesn’t need.
• Seed with what narrows. Name the files with @path/to/file rather than letting it search.
• Let it plan before it writes. A wrong plan costs a paragraph.

While you work — keep it clean

• Keep the goal recent. The middle of the window is the weak spot, so restate objective, constraints, and task list at each milestone.
• Push verbose work to subagents. Test runs, log trawls, dependency audits — you only need the conclusion. See Claude Code Has Four Agent Modes.
• Externalise durable state, and keep it true. A stale memory is worse than none.
• Return to ground truth, and make it a habit. Check the file, the test, the actual error — not the model’s memory of them.
  • The ! prefix drops real shell output straight into context: !git status, !npm test
  • If you do it often, make it a skill that injects the project’s real state in one go

When it turns — reset, don’t push

The hardest one to follow, because the history feels like progress you’d be throwing away. It’s sunk cost: those tokens are spent whether you keep the window or clear it.

• Two corrections on the same point is the signal. Told it twice the bug isn’t in the auth layer and it circles back? Stop.
• Catch it mid-step. Ctrl+C to redirect before a bad change lands; Esc+Esc to rewind conversation, code, or both.
• Regenerate, don’t carry forward. For re-derivable work a clean session beats a distilled history.
  • In Letta’s Recovery-Bench, agents given the full history of their failed attempts did worse than those starting clean
  • The rotten context actively dragged down recovery rather than informing it
• Match the action to the state:

For long or parallel jobs

• Decompose at verifiable seams — a test that passes, a build that compiles, a number that reconciles. Not the smallest possible unit.
• Fan out subagents only when the parts are independent.
  • Works for breadth: parallel research, independent lookups
  • Fails for coding, where subtasks are coupled — isolated agents make conflicting assumptions and you inherit the reconciliation
  • For isolation without coordination risk, a git worktree (claude -w) gives a parallel task its own branch
• Isolate the debugging. Send the investigation somewhere disposable, let it form and discard wrong theories, bring back only the cause and the fix.
• Bring in fresh eyes. A reviewer reading from a clean context catches what a rotten session cannot see in itself.

4. The session-as-git-tree model

The author’s own workflow, offered as one practitioner’s synthesis rather than a benchmarked result — but the framing is the most portable idea in the article.

• Your main thread is the orchestrator, and its context stays clean and on-task
• A detour forks off (claude --continue --fork-session) carrying the history so far, and the messy work happens there
• The fork is disposable by design — it can accumulate as much rot as it needs, because you throw the window away and keep only the result
• Branch → explore → distil → merge. Nothing that happens in the branch pollutes main

Fork vs subagent, which is the distinction worth keeping:

• A subagent handles parallel, independent work — spawn, explore, return a summary
• A fork handles the sequential detour off your main thread — the messy investigation that needs your full session history to make sense, where there’s no automatic path back and you want to choose what returns

Why this matters in practice

Every mechanism above shows up in ordinary work long before it shows up as a dramatic failure:

• Poisoning is the expensive one, because it compounds. A false statement written into a document is read back later as established fact, and it outlives the correction — the wrong version is in the record and the right one is in somebody’s memory. The damage is not the original error; it is every decision taken from it afterwards.
• Stale state outliving a correction is the reason duplicated facts are dangerous where duplicated prohibitions are not. A fact copied to three places drifts; a rule copied to three places just gets restated. Duplicate constraints freely, duplicate facts never.
• Ground truth beats model memory, and the gap is invisible from inside. A model that has read a stale document will report its contents with exactly the confidence it reports a fresh reading. Distinguishing what you checked from what you inferred is the whole defence.

The article’s own conclusion is the useful one: this is not about maximising context, it is about governing it — someone outside the window deciding what enters, what stays out, and what survives.

Source: Jake Minns, Context Rot: Why Claude Code Sessions Decay, and How to Govern Them, Towards Data Science.