Context Rot: Why Long Agent Sessions Get Worse and Fresh Workers Fix It

The session that used to be sharp

You started this session at nine and it was good. It read the error, named the real cause, and fixed it in one pass. Four hours and a dozen files later, you ask it to do something just as simple and it gets it wrong, or it fixes a different bug than the one you described, or it repeats a change you already turned down twice. Nothing crashed. No error appeared on screen. The agent is still answering every message. It is just worse than it was.

That decline has a name, context rot, and it starts long before any context limit, usage limit, or compaction event. A session does not need to be anywhere near full for it to show up.

What context rot actually is

Context rot is a long agent session getting vaguer and making worse decisions as its context window fills, well before that window is actually full. The problem is not that the agent forgets what you told it. Every token is usually still sitting in there somewhere. The problem is that the model has to find the one instruction that matters inside thousands of lines of diffs, file contents, and back and forth that has piled up around it, and that search gets harder the more there is to search.

Think of a desk that starts the day clear. The first sticky note you put on it is easy to see. By the afternoon it is buried under printouts, old drafts, and three other notes that looked urgent at the time. The important note did not vanish. It is one more thing in a pile the same size as everything else now, and finding it costs more attention than it did at nine.

None of this requires a bug. It is a property of how a model reads a long input, not a defect in any one agent or any one vendor.

The research behind it, and a vendor that names it outright

This is not a guess about how models behave. Liu and colleagues' Lost in the Middle paper tested several model families, including GPT-3.5-Turbo, GPT-4, and Claude 1.3, on tasks where the useful information sat at different points inside a long input. Accuracy was highest when that information sat at the start or the end of the context, and it dropped significantly when the same information sat in the middle. Accuracy also fell as the input grew longer, even for models built to handle long context. The paper gives no single headline percentage for how much worse answers get in the middle, and a claim that quotes one specific number as the paper's finding is not reading the paper.

OpenAI's own Codex CLI documentation uses the exact term. It recommends routing read-heavy work to subagents specifically to avoid what it calls context pollution and context rot, and it separately warns that parallel write-heavy work can create conflicts. That is a vendor naming this failure mode in its own documentation, and giving delegation as the reason to avoid it rather than a bigger context window.

Context rot is not the same as compaction

It is easy to confuse context rot with compaction, because both show up as a session getting worse. They are not the same failure, and the difference changes what fixes each one.

Compaction is a discrete event. When a conversation nears its context limit, older turns get summarized or dropped to make room for new ones, and whatever detail that summary leaves out is gone from that point forward. You can usually tell when it happened, because the agent suddenly stops referencing something it clearly knew a few minutes earlier.

Context rot has no event to point to. It is a continuous decline that starts while a session still has plenty of room left, driven by how hard it is for the model to find and weigh the one relevant detail among everything else that has accumulated. A session can rot badly long before it ever reaches the point where compaction kicks in. Fixing compaction means managing what gets summarized. Fixing context rot means not asking one session to carry the whole job in the first place.

The symptoms a developer actually notices

There is no log line that says context rot. You notice it in the texture of the agent's answers, usually in a few recognisable ways.

• It restates a decision you already settled, as if the conversation had never covered it.
• A fix it proposes now is worse than one it proposed for a similar problem an hour earlier.
• It mixes up two files or two tasks that are unrelated but sat near each other in the conversation.
• It needs more corrections per message than it did when the session started.
• It states something about code it already showed you, and the two no longer match.
• It drifts from the instruction you gave at the start toward whatever it has been doing for the last several exchanges.

The fix, cheapest first

Every fix below costs nothing. They get more structural as you go down the list, not more expensive.

• Start a new session with a written brief. This is the cheapest move and the first one to reach for: close the long session, open a fresh one, and hand it a short brief covering the goal, the constraints, and what has already been tried. A clean context window has nothing to search through, so it performs the way the first exchange of the old session did.
• Keep the plan outside the conversation. Write the plan and the open decisions to a file in the repository, or to a board, instead of leaving them buried in scrollback. A plan that lives outside the conversation does not depend on any one session staying sharp, and a new session can read it in seconds instead of someone re-explaining the project.
• Delegate bounded tasks to fresh workers. For work that splits into independent pieces, hand each piece to its own session with just that piece's brief and the files it touches, instead of asking one long-running session to hold the whole project at once. This is the most structural fix, because it stops any single context window from ever growing past the point where it works well.

How a Forkbench squad is built around this

A Forkbench squad takes the third fix and makes it the default shape of the work, instead of something to engineer by hand each time. Every helper a lead agent calls in starts its own session, so each one begins with a clean context the same way the first fix above does, every time, not only when someone remembers to do it.

The lead stays usable for far longer than an ordinary long session would, for a specific reason: it is not writing code. It plans, splits the job, and reads what comes back, so its own context fills with task descriptions and short notes rather than thousands of lines of diffs. That is the same shape Anthropic describes in its own multi-agent research system, a lead that directs workers instead of doing the work itself.

The board is the second fix, built in rather than left to discipline. Tasks, progress notes, and blockers get written to a Thread's board as the work happens, and that board is written to disk, so it survives a closed pane, a compaction, a quit, or a reboot. What a rotted or reset session would otherwise lose is already sitting on the board, in whichever helper's own words put it there.

Claude Code's own subagents do the clean-context part well, and Codex's subagent support does too; both are real, documented features from each vendor. The difference is that both live inside one vendor's session: start that session over, switch vendors, or close the pane, and whatever was built stays nowhere outside that one conversation.

When one long session is still the right call

None of this means every task needs a fresh session or a squad behind it. A short, well scoped task, a one line fix, a question about a file just opened, finishes before context rot has anywhere to build up, and starting over for it would waste more time than it saves.

Cognition AI has argued the stronger version of this point in its own writing on multi-agent systems: a single linear agent is the safer default for work where every action carries an implicit decision and a second agent cannot see the context behind the first one's choices. Work that genuinely needs shared context the whole way through, rather than work that splits into independent pieces, is exactly where Anthropic's own account of its multi-agent research system says a many agent approach is a poor fit. Reach for a new session, a plan kept outside the conversation, or a fresh worker when the task is long, when it splits cleanly, or once you have already noticed one of the symptoms above, not as a rule applied to every single message by default.