The Context Lifecycle

This volume opened by arguing that context, not the prompt, is the actual unit of leverage in AI-assisted engineering — that what a model does is a function of everything sitting in its window, and a well-phrased instruction inside a poorly curated context loses to a plain instruction inside a well-curated one. Everything since has been that argument worked out in practice. Context rot showed the failure arriving from inside the session, as reliability degrades unevenly with length in ways the advertised window size does not predict. Context drift showed a second, different failure arriving from outside it, as the world keeps moving — a file edited elsewhere, a decision reversed in a channel the session never read — while the session’s understanding stands still. Health scoring, compaction contracts, and deliberate recovery took those two failure modes and turned them from something a session merely suffers into something a team can measure and act on. And the memory ladder, file-based memory, decision memory, and knowledge graphs asked the harder question underneath all of it: once a team manages context well inside one session, how does any of that survive into the next one.

The claim this chapter closes with is simple enough to state in one sentence, and worth stating plainly because the rest of the volume was building toward it without saying it outright: context is not a container a session fills and forgets. It has a lifecycle, the same way any finite resource in a well-run system does, and every failure this volume named — rot, drift, context lost at compaction, debt compounding across sessions — is what happens when a stage of that lifecycle goes unmanaged.

The lifecycle, named

Volume I introduced the figure below early, in the chapter that named Context Debt, to make an economic argument: unmanaged context has a cost, and the cost compounds like any other debt left unpaid. The economics were the right place to start, because a cost figure is what gets a lifecycle taken seriously in the first place. But the figure was never really about accounting. It describes five stages every session’s context actually moves through, and this volume has spent ten chapters developing what happens — and what can be done — at each one.

Two ways spending goes wrong

The spent stage carries two of this volume’s central chapters because it fails in two structurally different ways. Context rot is an internal failure: it is a property of how a model attends to its own window, degrading unevenly as input grows regardless of what is true in the world. Context drift is an external failure: the session’s understanding stops changing while the world it is reasoning about keeps changing underneath it, so a context that was accurate when created becomes wrong without ever being corrupted. Rot is addressed by curating what goes into the window and how much of it there is. Drift is addressed by re-checking what is already in the window against what is currently true — a different discipline entirely, and one most teams have no habit of practicing, because nothing about a stale-but-plausible-looking context announces itself as stale.

What actually retires the debt

Every other stage in the lifecycle is a form of triage. Compaction contracts make the lost stage deliberate instead of accidental. Recovery makes the cost of loss visible and bounded instead of absorbed silently into a degraded session. Only the persisted stage removes the cost rather than managing it, and it is the stage the second half of this volume was built around. The memory ladder named the shape of the problem — retrieval that only reads (RAG), retrieval the model itself directs, and memory the agent also writes to — as three rungs of increasing autonomy, each one closing a gap the rung below it left open. File-based memory turned out to be the converged, unglamorous answer most teams reach for regardless of how much infrastructure they have: git history, a progress log, a task file, an AGENTS.md-style record the agent itself keeps current, none of it exotic, all of it durable enough that the next session inherits work instead of re-deriving it. Decision memory took the single highest-leverage category of persisted context — not what changed, but what was decided and why, and what it superseded — and gave it the same structured, queryable treatment a mature engineering org already gives its architecture decisions. Knowledge graphs closed the volume by naming when prose stops being the right shape for persisted context at all: past a certain density of entities and relations, a graph answers a multi-hop question a paragraph search cannot, and most teams already have the raw material for one without knowing it.

None of the four is a competing answer to the others. They are the same lifecycle stage implemented at increasing levels of structure, and a team should expect to run more than one at once — a file-based log for the cheap, high-frequency case, a decision record for the expensive, hard-to-re-derive case, a graph only once the queries being asked actually need one.

Where the Library goes next

Two threads from this volume continue elsewhere in the Library rather than closing here. Volume III, Intent Architecture, picks up the created stage from the other direction: a prompt is itself one kind of context, and that volume argues it should be engineered as a specification rather than issued as an instruction — the discipline this volume assumed a session already had going in. Volume IX, Engineering Knowledge, picks up Decision Memory’s throughline and asks what the same what-and-why-and-what-it-superseded structure looks like at organizational scale, across teams and quarters, well past what any single session’s memory was ever built to hold.