Quick answer: Context rot is the gradual decay of an AI agent's working memory over a long session. As the conversation, tool output, and file reads pile up, the model leans on the most recent and most repeated tokens while the details near the start become weak. The agent does not crash. It quietly loses constraints, reintroduces decisions you already settled, and grows more confident as it gets less accurate.
Why it happens mechanically
A coding agent does not hold a stable, queryable database of your project. It holds a context window: a fixed token budget filled with the system prompt, the conversation, tool calls, and the files it has read. When that window fills, three things work against you.
First, the middle of the conversation gets compressed or summarized. Summaries keep the headline and drop the qualification. A decision recorded as "use the retry queue, but only for idempotent writes, because the billing path is not safe to replay" becomes "use the retry queue." The exception that mattered is gone.
Second, position inside the window affects attention. Tokens at the start and the end are easier for the model to use than tokens buried in the middle. The constraint you set in turn two is still present in the text, but it has less pull than the error the agent is looking at right now.
Third, the agent has no sense that it has forgotten anything. There is no signal that tells it a missing constraint exists, so it treats the context it can see as the complete picture and acts with normal confidence.
What context rot looks like in practice
The symptom is not random nonsense. It is drift that stays close to the work, which makes it easy to miss in review.
| Signal | What the agent does | The earlier decision it forgot |
|---|---|---|
| Reopened debate | Asks whether to use the retry queue you chose on day one | The architecture decision and its reason |
| Reintroduced bug | Adds back the broad catch you removed | Why swallowing the error hid the root cause |
| Contradictory style | Switches a file back to the old naming convention | The convention agreed at the start |
| Lost scope | Calls an internal helper from a public handler | The boundary set in the original spec |
| Duplicate work | Writes a utility that already exists | The file it read near the start of the session |
The common thread is that every one of these answers was already in the conversation. The agent did not lack intelligence. It lost access to the fact.
How to tell rot apart from a plain wrong answer
A wrong answer is a reasoning failure: the agent had the constraint and reached the wrong conclusion. Context rot is a retrieval failure: the constraint is no longer effective in the working context.
A useful check is to open a fresh session and restate the rule. If the agent then gives the correct answer immediately, the model was capable of the right call all along. The long session had simply stopped surfacing the relevant fact. If the fresh session still gets it wrong, you have a reasoning or prompt problem, and a longer memory would not have fixed it.
How engineering teams keep it under control
The practical fix is to stop treating one long session as a reliable worker and treat context as something that has to be maintained.
- Keep sessions short and scoped to one task, then start a new one rather than extending a run that has gone through dozens of tool calls.
- Persist durable decisions outside the chat. A short design note or a rules file in the repo survives when the session is summarized, and the agent can re-read it at the start of each run.
- Make the agent state the constraints it is about to follow before it edits, so a missing rule is visible before code is written.
- Re-read the ground-truth files for the task instead of assuming the agent remembers them from an earlier turn.
A desktop tool such as Powerduck leans on this by keeping the durable rules and specs in files that are re-read each run, rather than trusting a session whose early turns have weakened.
This is the same discipline behind the wider AI coding agent guide: the agent's output is only as good as the context that is actually reachable at the moment it acts.
Frequently asked questions
Does a bigger context window stop context rot? It delays it. A larger window holds more history, but the middle still gets compressed and the same attention effects apply. A long enough session will rot in any fixed window.
Is context rot the same as hallucination? No. Hallucination invents a fact that never existed. Context rot loses or weakens a real fact from earlier in the session, then reasons from the incomplete picture.
Should I just keep every file in context to prevent it? That makes it worse. Dumping whole files consumes the budget and pushes the actual constraints out of reach. Pass the specific file and the specific rule for the task, not the whole repository.
How long is too long for a session? There is no hard number, because it depends on how much tool output each turn generates. Watch the behavior: when the agent starts re-asking settled questions or contradicting itself, the session has run long enough to restart.
The bottom line
Context rot is a memory problem, not a skill problem. A capable agent on a long session will slowly lose the early decisions and edge cases that made its work correct, and it will not tell you it happened. The defense is boring but effective: short scoped sessions, durable decisions written down in the repo, and re-reading the rules instead of trusting the agent to remember. Treat the long-running session as a fresh, slightly forgetful contractor each morning, and you will stop reviewing code that quietly undoes work you already agreed on.
Top comments (0)