Context Rot: Why Your AI Agent Gets Dumber the Longer It Runs

A bigger context window is supposed to make your agent smarter. Most of the time, past a certain point, it does the opposite.

You have felt this even if you never had a name for it. The first hour with a coding agent is sharp. It reads your files, follows your conventions, ships the feature. Then the session runs long, the diff piles up, and somewhere around the fortieth message the same agent starts forgetting the function it wrote an hour ago, reintroducing a bug you already fixed, or confidently editing a file it clearly no longer remembers reading. Same model. Same prompt quality. Worse output.

That decay has a name now, and it is the most useful term in AI building this year.

#What Context Rot Actually Is

Context rot is the measurable degradation in an LLM's performance as its input context grows longer. The more you stuff into the window, the worse the model gets at using any of it.

The phrase was coined in June 2025 by a Hacker News commenter and then proven, hard, by a Chroma research study that tested eighteen models including GPT-4.1, Claude 4, and Gemini 2.5. The finding was uncomfortable and consistent: as context length increases, performance degrades across every model, not because the task got harder but because the input got longer. A model that aces a needle-in-a-haystack question at 1,000 tokens starts missing the same needle at 100,000, even though the answer is sitting right there.

Here is the part that breaks most people's mental model. A context window is not memory. It is attention, and attention is a budget. Every token you add competes with every other token for the model's finite ability to focus. Gergely Orosz, watching his own agents fail, put the confusion plainly:

I'm starting to realize just how important it is to understand context sizes, context rot, context compression & similar behaviors to understand why these models often fall short. Eg why it is that you give it a large block of stuff and the model "forgets" about parts of it.

The model did not forget. It was never able to attend to all of it at once. A 200,000-token window does not mean the model reads 200,000 tokens well. It means it can hold them, and holding is not the same as using.

#Why It Hits Coding Agents Hardest

Context rot is worst exactly where AI coding agents live: long sessions, big files, and a window that fills with things the agent generated itself.

Salesforce describes the mechanism cleanly. In production agents, rot happens when newer content, retrieved code chunks, tool outputs, and fresh conversation turns, displaces older history from the window. Your carefully stated constraint from message three gets pushed toward the edge by the agent's own file reads, test logs, and thinking, until the thing you told it to never do is no longer in effective focus. This is why a coding agent reintroduces a bug you fixed twenty minutes ago. The fix is technically still in the transcript. It is just buried under the last forty tool calls, and buried is functionally gone.

There is a shape to it, too. Performance is not just worse at the end of a long context, it is worst in the middle. Researchers call it the lost-in-the-middle effect: models attend best to the beginning and end of their context and quietly skim the vast middle where most of your session actually lives. The r/ClaudeAI community landed on the sharpest framing of what this means in practice: Claude Code is a context-engineering harness, and most "it got dumber" moments are context rot, not a worse model.

Compare the two sessions and the pattern is obvious.

Fresh session: you ask for a change, the agent reads three relevant files, makes the edit, tests pass, done in one pass.

Rotted session: two hours in, you ask for a similar change, the agent re-reads files it already has, misses the convention it followed an hour ago, edits the wrong module, and "fixes" a test by weakening it.

Nothing about the request got harder. The window got louder.

#Why Bigger Windows Don't Save You

The obvious fix, buy a bigger context window, is the one that does not work, and understanding why is the whole point.

If rot were a capacity problem, a million-token window would solve it. But rot is an attention problem, and attention does not scale linearly with capacity. Every model tested in the Chroma study degraded well before it ran out of room. The window was not full. The model was already distracted. Doubling the size of a room does not help someone who cannot focus on the person in front of them, it just adds more people to ignore.

The standard mitigations all help and all share one ceiling. You can prune the context, dropping stale turns to keep the window lean. You can use retrieval to inject only the relevant chunk instead of the whole codebase. You can start a fresh session when things get muddy. These are the Compress and Select moves from the four pillars of context engineering, and you should use them. But every one of them works by managing what is inside the window. They are all defense against a window that is always, structurally, going to rot as it fills.

Which points at the actual fix, and it is not a window-management trick.

#The Fix Is Keeping the Truth Outside the Window

The durable answer to context rot is to stop trusting the window to remember what your product is supposed to be. Keep the source of truth outside the conversation, in a record the agent re-reads instead of a constraint it is slowly forgetting.

Think about what actually rots. It is not your code, your tests, or your git history, those live on disk and do not decay. What rots is the intent: the constraint you stated in chat, the convention you explained once, the "never touch the auth flow" you mentioned forty messages ago. That intent lived only in the context window, so when the window rotted, the intent rotted with it. The agent did not lose your codebase. It lost the plan for your codebase, because the plan was never anywhere but the chat. This is the same mechanism behind why your agent keeps breaking things that already worked: the constraint that would have stopped it scrolled out of focus.

The primitive version of externalizing intent is a file the agent reloads every session, a CLAUDE.md or the state file pattern that carries durable facts across sessions. That helps, and it is worth doing. But a flat file is still a file you maintain by hand, and it drifts. The stronger version ties the record to the work itself.

This is exactly the gap BrainGrid is built to close. In BrainGrid, you describe what you want and the Planning Agent turns it into a requirement with explicit acceptance criteria, a durable record of what this feature means and when it is done. That record does not live in the agent's rotting window. It lives in the product, alongside every other spec and decision, and the Builder Agent, whether it runs in BrainGrid's cloud sandbox or in your own GitHub repo with Claude Code, Cursor, or Codex over MCP, builds against that record and gets checked against it. When the session gets long and the agent's own memory of the goal has decayed, the goal is still written down where it cannot rot. Every session starts from the same source of truth instead of from zero. The agent forgets. The record does not.

The reframe is the whole thing: context rot is not a reason to distrust AI agents, it is a reason to stop keeping your product's definition inside a conversation that was always going to degrade.

#What This Means If You Build With Agents Today

If you run long coding sessions with Claude Code, Cursor, or any agent, this changes how you should work starting now. Stop treating a long-running chat as your product's memory. The moment your intent matters, and it matters the instant the app is more than a throwaway, get it out of the transcript and into a record the agent reloads: a spec, acceptance criteria, a written definition of what "done" means for this feature.

The trade-off is real and worth stating. Writing intent down before you build costs you a few minutes up front, and if you are prototyping something disposable, that cost is not worth paying, just vibe it and throw it away. But the second the thing has to keep working across sessions, the few minutes you spend externalizing intent is the cheapest insurance you will buy, because the alternative is discovering at message sixty that the agent has been building against a goal it can no longer remember.

Context rot is not going away. Windows will get bigger, attention will still be finite, and the sessions where you actually build real things will always run long enough to rot. Keeping the source of truth out of the rotting window is the whole point of context engineering. The builders who stay ahead of rot are not the ones with the biggest window. They are the ones whose source of truth was never in the window to begin with.

#FAQ

#What is context rot?

Context rot is the measurable decline in an AI model's performance as its input context grows longer. Past a certain length, adding more tokens makes the model worse at using any of them, because a context window is a finite attention budget, not unlimited memory. It shows up as an agent forgetting earlier instructions, missing details it was given, or contradicting itself the longer a session runs.

#What causes context rot?

Two things. First, attention dilution: every token in the window competes for the model's finite focus, so a longer context means each individual instruction gets less attention. Second, displacement: in a running agent session, new content like file reads, tool outputs, and fresh messages pushes your earlier constraints toward the edges of the window, where they stop being attended to. There is also a lost-in-the-middle effect, where models focus on the start and end of their context and skim the middle.

#How do you prevent context rot?

The common techniques manage what is inside the window: prune stale turns to keep it lean, use retrieval to inject only the relevant code instead of the whole codebase, and start fresh sessions when things get muddy. These help but share a ceiling, because the window always rots as it fills. The durable fix is to keep your source of truth outside the conversation, as a spec or acceptance criteria the agent re-reads, so the definition of what you are building cannot decay along with the chat.

#Why does an AI coding agent forget files it already read?

Because reading a file loads it into the context window, and as the session grows, that file's contents get displaced by newer tool outputs and pushed into the low-attention middle of the window. The information is technically still in the context, but the model can no longer effectively attend to it, so it behaves as if it forgot, and often re-reads the same file rather than trusting the copy already in context.

BrainGrid is the plan-first app builder that keeps your product's definition in a durable record the agent re-reads, not a chat window that rots. Try it at braingrid.ai.