Context rot: why 1M-token windows make agents dumber

Here is the answer, up front: a bigger context window will not make your agents smarter, and if you use it the obvious way — by pasting in everything you have — it will make them measurably worse. Context rot is the decline in an AI agent's reliability as its context window fills with more, and less relevant, tokens. The July 2026 wave of 1M-token models did not solve the context problem. It changed the shape of it. The bottleneck is no longer how much you can fit. It is what you choose to put in.

If your team just watched OpenAI, Anthropic, and Google ship million-token windows and thought "great, now we can stop being careful about context," this post is the correction. The careful part is the whole game now.

The window got bigger. The problem got worse.

For two years the constraint was capacity. You had a few thousand tokens, then tens of thousands, and the craft was fitting the truly load-bearing facts into a small space. Teams built elaborate truncation logic and summarization passes to survive inside those limits.

The July 2026 model wave erased that constraint for most workloads. OpenAI's GPT-5.6 family — Luna, Terra, and Sol — shipped with 1M-token context. Anthropic's Claude Sonnet 5 and Google's Gemini Omni Flash landed in the same window (the ThursdAI July 2026 release roundup is a good snapshot of how tightly clustered that wave was). The frontier is now at near-parity on raw capability. When every model can hold a million tokens, "which model" stops being the interesting question. How you feed it becomes the entire differentiator.

And here is the trap. A million-token window feels like permission to stop curating. Paste the whole repo. Attach every doc. Dump the full ticket history. It all fits, so why not? Because "it fits" and "it helps" are different claims, and the gap between them is context rot.

What context rot actually is

Context rot is not the model getting dumber. The weights do not change between your good prompt and your bloated one. What changes is the ratio of signal to noise inside the window.

An agent attends across everything you give it. Every token you add is a token it has to reconcile against the task. When you add relevant tokens, you sharpen its aim. When you add irrelevant ones — a stale README, three superseded design docs, a Slack thread that reversed itself twice — you are not adding context, you are adding distractors. The model now has to figure out which of the contradictory instructions is the live one, which version of the function is current, which convention actually applies. Sometimes it guesses. Sometimes it anchors on the wrong thing because the wrong thing was longer, or more recent, or more emphatic.

The failure modes are recognizable once you name them:

• Distraction. The relevant instruction is in there, but it is one line in fifty thousand, and the model's attention gets pulled toward higher-volume, lower-relevance material.
• Contradiction. You pasted two versions of the truth. The model cannot know which one you meant, so it averages them or picks wrong.
• Anchoring on the stale. Old context that used to be true outranks the new context that is true now, because there is simply more of the old.
• Lost-in-the-middle. Facts buried in the center of a very long context are recalled less reliably than facts at the edges — a well-documented shape of long-context behavior that a bigger window does not repeal.

None of these are exotic. Every engineer who has pasted a giant blob into a chat and gotten a confidently wrong answer has already met context rot. The 1M-token era just makes the blob bigger and the confidence higher.

Why "just paste everything" is the wrong instinct

The paste-everything instinct comes from a reasonable place: you would rather the model have a fact and not need it than need it and not have it. Under tight limits that trade-off made sense, because the cost of omission was high and the window was too small to hoard anyway.

At a million tokens the trade-off inverts. The cost of omission is low — you can always retrieve one more fact — and the cost of hoarding is now dominant. Every irrelevant token you carry is a small tax on every inference the model makes. Carry enough of them and the tax compounds into wrong answers.

This is why the field has been saying "context engineering has replaced prompt engineering." The clever wording of a prompt matters far less than the discipline of what surrounds it. The research community has converged here fast; the 2026 context-engineering research survey is a good map of how quickly curation-over-volume became the consensus position. The skill is no longer writing the perfect sentence. It is assembling the perfect working set — the smallest slice of context that fully covers the task and nothing else.

Curation beats volume: the ACE argument

The strongest recent formalization of this is the ACE (Agentic Context Engineering) paper from ICLR 2026. Its core claim is structural: context should be structured, itemized bullets updated incrementally — not one giant block that gets rewritten from scratch each turn.

That sounds like a formatting preference. It is actually an architecture argument. If context is a monolithic blob you rewrite every time, you have no way to add, retire, or version individual facts. Stale items ride along forever because nothing prunes them. But if context is an itemized store — discrete, addressable, individually updatable units — you can retire the design doc that got superseded, promote the convention that got ratified, and hand the agent only the items that matter for the task at hand.

In other words: ACE is describing a managed, versioned, curated context store. Not a text box you keep pasting into. A source of truth you retrieve from.

That is the pivot the whole 1M-token conversation has to make. The window is plumbing. The store is the product.

The team problem hiding inside the session problem

Everything above is about a single session — one agent, one window, one task. But if you run a 20-to-80-engineer org with three or more AI tools in play, context rot is not a solo problem. It is a supply problem.

Where does the context that fills the window actually come from? Today, for most teams, it comes from wherever the individual developer scraped it: a local CLAUDE.md, a personal snippet file, a doc someone remembered existed, a copy-paste from a stale wiki page. Each developer is hand-assembling a working set from a different pile of sources, and half those sources are out of date the moment they are pasted. That is context rot manufactured at the input, before the model even sees it. (We dug into why the per-repo config file breaks down at team scale in The CLAUDE.md problem.)

A bigger window does not fix a bad supply chain. It just lets each developer pour more unvetted material into the funnel. And because MCP tool calls are stateless — each request arrives with no memory of the last — every session rebuilds its context from scratch, which means every session is another chance to rebuild it from the wrong sources. We wrote about that statelessness and what it demands of teams in MCP is stateless — so where does team context live?.

The answer is not to make individuals better at curating by hand. It is to move curation up a level — to make the right context a shared, retrievable resource instead of a per-developer scavenger hunt.

The fix: retrieve the right slice, on demand

The durable fix for context rot is to stop treating the context window as a container you fill and start treating it as a workspace you supply on demand. Keep the source of truth outside the window, in a store that is structured, versioned, and shared. Then, at the moment the agent needs context, retrieve the relevant slice — and only that slice — over MCP.

This is ContextOps: managing your team's AI context as shared infrastructure rather than as per-developer config files. The category matters because it names the level the fix has to live at. Prompt engineering is a per-message skill. Context engineering is a per-session skill. ContextOps is the team-level layer underneath both — the shared source of truth that every agent, in every tool, inherits from.

Contextium is that layer. It sits behind Claude, Cursor, Copilot, and every MCP-connected tool, so each agent pulls from one workspace instead of from whatever each developer happened to paste. One shared context. Your whole team's AI, drawing on the same source of truth. When the store is the authority and retrieval is scoped to the task, the window fills with signal, and context rot has nothing to feed on.

First-person, from us: we dogfood this every day, and the discipline is deliberate. We do not dump our whole workspace into every prompt. Our agents pull the relevant slice of the shared context via MCP at the moment they need it. The practical effect is that a bigger window does not mean a noisier one — going from a 200K to a 1M-token model changed our ceiling, not our habits. We still hand each agent the smallest working set that covers the task, because we learned the hard way that a full window is a slow, distractible window.

Rot vs. collapse: a quick distinction

It is worth separating two failure modes people conflate. Context rot is what this post is about: relevance and volume degrading inside a single session. Too much, too irrelevant, too contradictory, right now.

Context collapse is the team-scale cousin: convention drift across people and time, where different developers' agents slowly diverge because they are working from different, un-synced notions of "how we do things here." Rot is a session problem. Collapse is an organizational one. They share a root cause — no shared, curated source of truth — which is why the same infrastructure addresses both. But keep them distinct when you diagnose: if one agent gives a bad answer from a bloated prompt, that is rot; if two agents give confidently different answers to the same question, that is collapse.

What good looks like

If you want to pressure-test whether your team has a rot problem, look for these signals:

• Developers routinely paste large, undifferentiated blobs — whole repos, whole doc folders — into prompts "to be safe."
• The same stale fact keeps resurfacing in agent output weeks after someone "fixed" it in one place.
• Answers vary wildly depending on who prompted, because each person assembles context from a different pile.
• Nobody can point to a single, authoritative, up-to-date source that an agent reads from.

And here is what good looks like instead: a structured, itemized context store that is versioned so stale items can be retired; scoped retrieval so each agent gets the task-relevant slice and nothing else; and one shared workspace so every tool inherits the same truth. That is not a bigger window. It is a better supply chain for the window you already have. If you are evaluating where that store should live, we compared the landscape in the best AI memory tools of 2026.

The million-token window is a gift. Spend it on signal.

Bigger windows raised the ceiling. They did not change the job. The job is still to give each agent the right context — and only the right context.