An agent that is sharp on a small task gets vague on a large one. Early in a session it respects your conventions, remembers the constraint you gave it, and reasons carefully about the change. An hour and forty tool calls later it contradicts a decision it made itself, reintroduces a pattern you told it to avoid, and edits a file as if it had never seen the rest of the module. Nothing crashed. The agent just quietly lost the plot. This is context rot, and it is the reason large and legacy codebases defeat agents that handle small ones with ease.
Context rot is not forgetfulness in the human sense and it is not a bug you can patch. It is a structural property of how these systems work, and once you see the mechanism, the mitigations become obvious.
What context rot actually is
A model reasons over a finite window of information. Everything it "knows" in the moment, the code it has seen, the instructions you gave it, the decisions it has made, competes for room in that window. As a task grows, the amount of relevant information grows past what fits, and something has to give.
Two things degrade. First, older information falls out of the window or gets summarized into a lossy paraphrase, so a constraint you set early stops influencing decisions made late. Second, even within the window, more content means more for the model to weigh, and the signal it needs gets diluted by content it does not. The result is an agent whose grip on the task loosens as the task gets bigger, not because it is careless but because the relevant world stopped fitting in its head.
Legacy codebases make this worse in a specific way. They carry more implicit constraints per feature, more history that matters, more coupling that has to be held in mind at once. A greenfield task might need three files of context. The same task on an eight-year-old system might genuinely require thirty, and thirty does not fit as cleanly, so the rot sets in earlier and bites harder. This is a large part of why the demo-to-production cliff is so steep.
How rot shows up in the output
Context rot rarely announces itself. It shows up as a cluster of symptoms that are easy to misread as the model being dumb.
The agent contradicts itself across a long task, choosing one approach early and an incompatible one later, because it no longer has the early reasoning in view. It reintroduces things you ruled out, because the instruction to avoid them rotted out of context. It makes locally correct, globally wrong changes, editing one file sensibly while breaking an invariant that lived in a file no longer in scope. And it grows more confident as it gets less grounded, because fluency does not decay with accuracy, which ties context rot directly to the plausible but wrong failure mode: a rotted context produces confident output built on a stale picture.
If you have seen an agent do beautifully for twenty minutes and then start making decisions that feel subtly off, you have watched context rot happen in real time.
Fighting it: less context, chosen better
The reflexive fix is to give the agent more room, a bigger window, the whole repository, everything at once. This makes the problem worse, not better. More content is more to dilute the signal and more to lose track of. The counterintuitive truth is that the answer to context rot is usually less context, selected more carefully, not more of it.
Give the agent the relevant slice, not the whole system. The change it is making touches specific modules, honors specific contracts, and follows specific conventions. That is what it needs in view. The rest is noise that accelerates rot. Selecting well on each step is a real discipline, and we cover the tradeoffs in context engineering for coding agents. The underlying principle, that feeding an agent the right slice beats feeding it more, is the subject of grounding beats prompting.
Treat the window as a budget you spend, not a bin you fill. Every token of context has a cost in dilution as well as in money, and reasoning about that budget deliberately is what separates a design that scales from one that rots. We make that case in the context window as an architecture constraint.
Break large tasks into small ones with clean boundaries. A task that needs thirty files of context to hold in mind at once is a task that will rot. The same work split into several focused steps, each needing a handful of files and each verified before the next begins, sidesteps rot by never letting the required context grow past what fits. Decomposition is a reliability technique as much as an architecture one.
Re-ground instead of relying on memory. Rather than trusting that a constraint set an hour ago is still in view, re-establish the relevant facts from the actual code at the point of decision. An agent that re-reads the current state before acting is far more robust than one leaning on a possibly-rotted recollection of it.
The honest limitation
These techniques push the onset of context rot back. They do not abolish it, because the underlying constraint, a finite window and a task that can always grow past it, does not go away. A task that is genuinely too large and too interconnected to decompose cleanly will strain any amount of careful context selection, and some legacy systems have coupling so pervasive that the "relevant slice" is uncomfortably close to the whole thing.
There is also a real tension between fighting rot and preserving continuity. Aggressively trimming context keeps the agent grounded but can drop a subtlety that mattered. Selecting context well is a judgment call, and getting it wrong in the other direction, starving the agent of something it needed, is its own failure. The skill is in the balance, and the balance is empirical.
Where this leaves you
Context rot is why the same agent that shines on a small task drifts on a large one, and why legacy systems are the hardest place to deploy agents well. The mechanism is a finite window meeting an ever-growing task, and the fix is not more context but better-chosen context, smaller tasks, and re-grounding at the point of decision instead of trusting a fading memory.
This is why grounding against the live, current state of the actual codebase, rather than a static or remembered picture of it, is a principle we hold to at Loopsfinity: an agent's understanding is only as good as how fresh and how focused its context is. The demo-to-production framing is in the demo-to-production cliff, the confident-wrong output rot produces is in plausible but wrong, and the full failure map is in why AI coding agents fail in production.