Your AI Context Has an Expiry Date. Most Teams Don't Know When It Passed

By Peter Maddison · 2026-07-09

The Second Control Loop

Your context file was accurate the day you wrote it. That was six weeks ago. The codebase has shipped three major changes since then. Your agent doesn't know.

This is not a model problem. The model is following the map you gave it. The map is wrong, and because nothing broke the day you wrote it, nothing flagged it as wrong the day it stopped being true.

Most engineering leaders haven't named this failure mode. They are debugging the model when they should be governing the map.

That distinction matters. Context is no longer passive documentation. It is now part of the delivery system. Agents use it to interpret intent, make design choices, avoid boundaries, and decide what kind of change is safe. Once context starts shaping execution, stale context becomes an operational risk.

Context has a lifecycle, and the slow layer is the dangerous one

This is where context starts to look less like documentation and more like infrastructure.

Patrick Debois's Context Delivery Lifecycle (CDLC) gives the problem a useful structure: context in AI-assisted development does not decay uniformly. It operates in layers, each changing at a different speed.

That structure is helpful because it shows why a single governance mechanism will not work. Some context fails loudly. Some fails quietly. Some gets corrected through use. Some only gets corrected if the organization deliberately goes looking for drift.

The fast layer (session state, active instructions, ephemeral conversation context) is temporary, not trivial. It can still degrade inside a session as assumptions accumulate, tools retrieve the wrong material, or the conversation fills with noise. But unlike durable project or architecture context, it expires when the session ends. A new session clears the accumulated mess, provided the durable context it reloads from is still accurate.

The medium layer (your CLAUDE.md, your system prompt, your README-level project descriptions) gets updated when something obviously breaks. A developer hits a wall, investigates, patches the context. Painful, but traceable.

The slow layer is where the real risk lives: architectural assumptions, team conventions, domain boundaries, integration constraints, ownership models, and implicit rules about what the system does and does not do. The “of course we don’t touch that” knowledge that exists in heads but not in files, or exists in files nobody reviews because it feels settled.

This layer doesn't break visibly. It drifts. By the time you notice something is wrong, the agent has been working from a flawed map for weeks.

What the slow layer looks like in practice

Consider Architecture Decision Records. ADRs have existed for years, and they've been hard to sustain because their primary beneficiary was human memory, unreliable and inconsistently consulted. Teams let ADR hygiene slip. Did it matter if nobody read them?

The old weakness was that humans forgot to read the map. The new weakness is that agents read it every time.

That changes the risk profile. A stale ADR used to be a memory problem. Now it can become an execution problem. The map is no longer just a record of past decisions. It is part of the input from which future changes are generated.

It matters now. An AI agent reads them every time, persistently. An ADR that accurately described a system two years ago but hasn't been touched since is still read as authoritative guidance today, because nothing in the context signals it's stale. The agent doesn't know what it doesn't know. It works confidently from whatever it's given.

A team building out interfaces for a system ran into this directly. An old spec that should have been retired was still accessible to the model, and the agent kept building interfaces wrong, calling things by names nobody had used in three months, referring to functions that no longer existed. The whole reason was simple once someone traced it: the agent was pulling data out of an old spec. It wasn't hallucinating. It was being accurate to the wrong source.

The intervention was not about the model. It was governance: being intentional about what context gets fed to which agent, who owns that context, how its authority is signalled, and when it gets retired.

Spec-driven development raises the stakes on this same question. A team writing specifications for an AI agent to build software from ran into the questions that have always plagued documentation, now with higher stakes: Where does the spec live? What format? Who can see it, and who can change it? These are not new questions. They are old documentation questions with new operational consequences. When documentation starts generating the system, it stops being an archive and becomes an execution contract. Ambiguity a human developer might challenge, ignore, or resolve through conversation can now become working code.

When missing context is the problem, not stale context

A related failure mode is just as costly: context that was never written.

This is where partial context becomes dangerous. A human developer may know that an undocumented module is politically sensitive, technically fragile, or simply out of scope. An agent does not inherit that caution. If the boundary is not written down, the boundary may not exist.

A legacy application project ran into this. Context files described two modules, the ones the team was actively working to change. The rest of the application was undescribed. When a feature request touched those two modules, the agent changed code across all of them, including legacy components nobody intended to touch. The database was modified too, and the team had to undo everything. The missing context wasn't about what to do. It was about what not to touch, and few teams can honestly say they own the AI-generated code they're shipping when the boundaries were never written down.

The boundaries of the map matter as much as the detail inside it. An agent operating in partial context fills the unmapped territory with inference. Sometimes that inference is correct. When it isn't, the consequences spread further than expected.

The statistics frame the stakes, but the pattern is the real problem

Atlan cites research showing a 40% or greater reduction in hallucinations with governed context metadata. That number represents the value of context that's present, current, and maintained. The cost of getting it wrong shows up elsewhere too.

Code churn, code written then deleted or reworked within two weeks, rose from 3.1% in 2020 to 5.7% in 2024, a period that correlates directly with AI coding tool adoption (GitClear, 2025 analysis of 211 million lines of code). Separately, 45% of developers report that debugging AI-generated code takes more time than expected (Stack Overflow Developer Survey 2025). Neither is a model-quality problem. Both are context problems, the same reason faster code has translated into slower shipping: when the agent works from a stale or incomplete map, rework follows. Not all of this is a model-quality problem. Much of it is a context problem, the same reason faster code can still translate into slower shipping: when the agent works from a stale or incomplete map, rework follows.

Most teams believe they're managing context well because they have context files. They may not be. A context file that was accurate six months ago and hasn't been reviewed since is worse than no context at all. It actively misleads. The model reasons from it with the same confidence it would bring to current, accurate context. It doesn't flag uncertainty when it follows a stale spec. It delivers.

That is why hallucination rates in coding benchmarks (RubberDuckBench 2026) do not always feel like a pure model problem from inside an engineering team. Some of what reads as hallucination has a context explanation upstream: stale assumptions, missing boundaries, conflicting sources, or instructions that were once true and no longer are.

PR review is one control loop. Slow context needs another.

Most teams try to solve this inside the pull request. That is necessary, but not sufficient.

A pull request is an activity-triggered control. It asks whether this change has context implications. Did the architecture change? Did an ADR need updating? Did the agent introduce a new convention or violate an existing one?

That matters. But it only catches risk introduced through visible change.

Slow-layer context fails differently. Nobody opens a pull request when an architectural assumption quietly stops describing reality. Nobody gets a failing build because the team topology changed, an integration became deprecated, or a constraint that used to be absolute became negotiable three planning cycles ago.

That is why AI-assisted delivery needs a second control loop. One loop validates change. The other validates the assumptions future changes will depend on.

This is not more bureaucracy around pull requests. It is a different governance question:

The PR loop asks: does this change remain consistent with our architecture?
The context loop asks: does our architecture still describe the system?

Those are not the same question. Treating them as the same question is how stale context survives.

Context is now part of the delivery system. That means it needs the same kind of governance discipline we already apply to code, infrastructure, environments, and production controls.

In practice, that means ADRs treated as live documents, with version discipline closer to code than archive. It means a PR-level check for whether a shipped change has context implications, not just whether the code works. It means a separate audit cadence for slow-layer context, asking whether architectural descriptions, domain boundaries, integration assumptions, and team conventions still reflect how the system actually operates.

And where critical constraints exist, the things an agent must never do, those constraints should not live only in the context window. They need deterministic hooks, tooling rules, tests, policy checks, or guardrails that fail when violated.

The context window is not the right place to enforce every constraint. It is the right place to describe the system accurately. The distinction matters.

The map is only as good as the last time someone checked it

Most engineering leaders have invested in model selection, prompt engineering, onboarding workflows, and tool adoption. Fewer have invested equivalent discipline in keeping the context accurate over time.

That gap matters because AI has not made documentation more important. It has turned context into operational infrastructure.

Infrastructure needs ownership. It needs versioning. It needs review. It needs retirement rules. It needs controls that operate when something changes, and controls that operate because time has passed and assumptions drift.

The fast layer gets attention because it breaks visibly. The slow layer does not. It just keeps being read as true.

When did you last review the architectural assumptions baked into your context? Not the file that updates when something breaks. The layer underneath it. The assumptions your agents will use to generate the next change.

That is where the drift lives.

Further reading: