Context Debt

Every engineer who has run more than a handful of AI coding sessions recognizes the same first ten minutes. A new session opens, and before any code changes, someone re-explains what an earlier session already knew: why the auth module is shaped the way it is, which two approaches were tried and discarded last week, what the migration script is waiting on. Three days earlier, an agent worked through all of this. Today’s agent — sometimes literally the same agent, on a session that compacted its way through the intervening work — does not remember doing it.

That ten minutes rarely gets logged anywhere. It is absorbed as ambient friction, the cost of working with a tool that has no persistent memory of its own. Multiply it across a team running dozens of sessions a week and the pattern sharpens: sessions that hit a wall an earlier session already solved, decisions re-litigated because nobody wrote down why the first one was made, architecture explained fresh each Monday because Friday’s context evaporated over the weekend. None of it shows up on a token invoice. All of it is cost, and it is a cost the rest of this volume has not yet named.

What context rot actually shows

The instinct is to solve this by throwing more context at the problem — paste in the whole file, the whole thread, the whole design document, and let the model sort it out. The evidence says that instinct is incomplete at best. Chroma Research’s 2025 evaluation of eighteen models found that language models do not use context uniformly: reliability degrades as input length grows, and it degrades unevenly, with some information effectively invisible to a model depending on where in the context it sits and what else is competing for the model’s attention at that position. The finding has a name in the field now — context rot — and it means a context window is not a bucket that fills evenly. It is a resource that degrades under load in ways that are hard to predict from outside the model.

This is not a new observation dressed in new language. In 2023, researchers studying how language models use long contexts found a consistent U-shaped performance curve: models retrieve information reliably from the start and end of a context and unreliably from the middle, a primacy-and-recency bias that showed up across model families and persisted even in models explicitly built for long-context use. Two years and several model generations later, Chroma’s work shows the pattern has not disappeared so much as changed shape and grown harder to see coming. The lesson holds across both studies: a context window’s advertised size is not the same as its effective size, and pretending otherwise is exactly how a re-explained architecture decision turns into a re-broken one.

The pattern nobody names

Every engineering organization already has a name for the cost of skipping work that would have prevented rework later: technical debt. A shortcut taken under deadline pressure accrues interest — in bug reports, in onboarding friction, in a codebase’s growing reluctance to be touched — until someone pays it down deliberately or the system collapses under the weight of shortcuts nobody tracked. The pattern repeating itself around AI sessions is structurally identical, denominated in a different currency. Call it Context Debt: lost conversational and decision context that must be re-earned before productive work resumes.

Context Debt accrues the way technical debt does — quietly, as a side effect of moving fast — and it compounds the same way too. A session that ends without persisting anything forces the next session to rediscover, at minimum, what was tried and why it failed; if that rediscovery is itself lost, the session after that pays the same cost again, now with less certainty about what was previously known, because the rediscovery was a paraphrase of a paraphrase. Nobody schedules a sprint to pay this down, because almost nobody is tracking that it exists. It shows up instead as a session that runs longer than it should, a decision that gets reversed and then reversed back, a team that quietly starts avoiding a part of the codebase the way it once avoided a part of the codebase with no tests.

Context Debt, defined

The precision matters because Context Debt is easy to conflate with the token spend Chapter 1 already covered, and it is not the same thing. The AI Cost Iceberg is about costs hidden below a visible invoice — context rebuilding is one line inside it, alongside review time and rework. Context Debt is the mechanism that produces that specific line: the gap between context that once existed and context that is available now, multiplied by the number of times someone has to close that gap by hand. A team can have a small token bill and a large Context Debt problem — cheap sessions, constantly re-litigating the same ground — and the invoice will never show it.

The Context Lifecycle

Debt implies a lifecycle: something is created, spent, and either paid down or allowed to compound. Context moves through the same shape, and naming its stages is what turns an ambient, unmeasured tax into something a team can actually manage.

Context is created the moment a session starts: a goal is stated, files are opened, a plan takes shape. It is spent continuously from there, drawn down against the finite working-context budget every session operates under, whether or not anyone on the team thinks of it in those terms. It is lost at two distinct points — when the session ends and nothing outlives the terminal window, and again, more subtly, whenever a harness compacts a long-running session and some detail that seemed unimportant at the time gets summarized away with the rest. It can be recovered, at a price: an engineer re-reads the thread, or a fresh session re-derives the reasoning by re-reading the code, paying in time what was not paid in storage. And it can be persisted — written somewhere durable enough that the next session inherits it instead of re-earning it: a decision record, a memory file, a comment that survives the session that wrote it.

Compaction: the harness’s repayment plan

Anthropic’s framing of context engineering treats the context window as a finite, curated resource rather than a bottomless pipe: the practical question is not how much can be crammed in, but which configuration of context — static context loaded up front, versus information retrieved just-in-time as the work actually requires it — is most likely to produce the behavior a team wants. That framing matters here because it reframes Context Debt from an accident into a design problem. A harness that loads everything up front spends context fast and rots faster; a harness that retrieves just-in-time spends less per turn but has to get retrieval right, or it silently loses context it never loaded in the first place.

Compaction is the harness’s attempt to manage the lost stage on a team’s behalf, and it deserves to be understood as real debt management rather than a workaround. Anthropic’s guidance on long-running agents describes compaction as summarizing a session as it approaches its context limit, with explicit rules for what survives the summary and what does not — an open architectural decision or an unresolved thread is the kind of thing worth preserving deliberately, because a generic summarizer has no way of knowing it matters more than the intermediate debugging output sitting around it. Compaction converts an unbounded loss into a bounded, deliberate one, which is a genuine improvement. But it is bounded by exactly what the summarization rules were told to keep, and by definition nothing else. Anything outside those rules is lost precisely as if the session had simply ended with no summary at all.

Compaction does not prevent Context Debt. It decides, in advance, which parts of the debt get forgiven and which get called in later.

On summarization as a survival policy, not a memory

What to check this against

Operon does not yet have a fleet of instrumented sessions large enough to publish a real distribution for Context Debt specifically, and this chapter will not manufacture one. What follows is the shape of the check, not a result — illustrative figures, offered as a starting instrument rather than a finding.

Paying down the debt

None of the five stages require new tooling to manage, and persistence is the only stage that actually retires debt rather than deferring it. The discipline is close to the one software engineering already learned for its other kind of debt: write down the decision and the reasoning while it is fresh, in a place the next person — or the next session — will actually find. Architecture Decision Records did exactly this for human teams more than a decade ago, for exactly the same reason: the hardest thing to track during a project is the motivation behind a decision, and a decision stripped of its motivation is a decision someone will end up re-litigating from scratch.

1. Persist decisions, not just code. A short record of what was decided and why costs less to write once than it costs to re-derive twice.
2. Treat compaction rules as a policy, not a default. Know what a harness’s summarization keeps and what it drops, and do not assume the defaults protect whatever matters most on a given project.
3. Tag sessions that open with re-explanation. It is the cheapest signal of Context Debt a team has, and almost nobody is currently collecting it.
4. Make persisted context queryable, not just stored. A memory file nobody reads is a debt payment nobody can cash.
5. Budget context like the scarce resource it is. A working-context window that is 80% full is not 80% as reliable as one at 40% — closer to unreliable, per the context rot evidence above.

None of this argues for writing everything down — an over-documented project drowns in the same way an under-documented one starves, and the actual discipline is judging which decisions are worth the persistence cost and which are not. What it argues for is treating context the way the rest of this volume treats cost: as something to measure, not assume. The next chapter turns that same lens on the session itself, asking what a session actually returns for what it costs — because a team that has paid down its Context Debt has removed one confound from that answer, and a team that has not is measuring session value with a thumb already on the scale.