Your agent is working great. You shipped it two months ago, the outputs are clean, the team trusts it. You've moved on to the next thing.
Then, quietly, something shifts. A prompt that worked perfectly last month now produces inconsistent results. An agent that was reliable starts hedging where it used to decide. A pipeline that shipped clean outputs has started requiring more human correction. Nothing broke. The system just... drifted.
This is the Drift Problem. And it's one of the least-discussed operational challenges of running agents in production.
What Drift Is
Drift isn't a single failure. It's an accumulation of small disconnects between the world your agent was designed for and the world it's operating in now.
It shows up in a few forms.
Prompt-world misalignment. Your agent was prompted with assumptions about your codebase, your team's conventions, your API contracts. Those assumptions were correct when you wrote them. Three months later, you've refactored, renamed things, changed your deployment process. The agent's mental model is from an earlier version of reality. It mostly works, because most of the old assumptions still hold. The failures are subtle and intermittent.
Behavioral accumulation. In systems where agents build on previous agent outputs — where this week's analysis starts from last week's summary — errors compound. Small biases in one pass become confident assertions by the third pass. By the time someone notices, the drift is load-bearing. The downstream analysis depends on the upstream framing. You can't easily untangle it.
The updated baseline. The world changes and the agent doesn't know. Regulations shift. APIs deprecate. A competitor launches. A library version breaks a behavior your prompt relied on implicitly. The agent wasn't told. It proceeds on stale ground.
Why It's Hard to Catch
The frustrating thing about drift is that it tends to stay below the detection threshold for a long time.
A full failure is easy to catch. The output is obviously wrong, the CI breaks, someone gets paged. You find the root cause and fix it.
Drift produces outputs that are _mostly right_. The outputs pass a quick scan. They're in the right format. They address the right question. The subtle problems — the slightly off recommendations, the quietly wrong assumptions baked into the analysis — only become visible when you compare against what you'd expect from a well-oriented agent, and you stopped doing that carefully around month two.
There's also a psychological component. Once an agent has established trust, you apply less scrutiny. That's the rational response to a reliable tool. But it means that drift in a trusted agent can run longer and deeper than drift in a new one.
The Compounding Effect
The worst form of drift is when one drifted agent feeds another.
We had this in an early Paperclip configuration. The Growth agent was summarizing content performance and writing briefs for the Content Writer. The summaries started including a framing — "SEO-first, conversion-second" — that the Growth agent had developed over time based on early experiment results. This framing was fine when it started. By the third month, we'd learned that for our specific audience, the opposite was true: trust-building content converted better than keyword-optimized content.
The Growth agent's briefs never updated the framing. The Content Writer was working on a brief that was two experiments out of date. Nobody caught it for six weeks, because both agents were producing outputs that looked fine in isolation.
When the framing is wrong, the copy is wrong. When the copy is wrong, the conversions are wrong. But you don't see it immediately, and you don't know where to look.
Drift vs. Bugs
There's a reason the AI engineering community talks constantly about bugs and almost never about drift: bugs are solvable with existing tools. You reproduce, you trace, you fix.
Drift doesn't reproduce cleanly. It's not a specific failure with a specific cause; it's a gradual divergence between expectation and reality. The tools we have — unit tests, integration tests, CI/CD — were built for bugs. They're necessary but not sufficient for catching drift.
What you need instead is context hygiene. Periodic review of the assumptions baked into your prompts against the current state of the world. Structured comparisons between what an agent is saying and what you'd want it to say if you were writing the prompt fresh. An understanding of which assumptions are load-bearing and which are ambient.
This is harder than writing tests, because you can't fully automate it. A test checks that a function returns the expected output given the expected input. Context hygiene asks a harder question: are your inputs still the right inputs?
What CDD Gets You
Context-Driven Development is a discipline for making context explicit, versioned, and reviewable.
The core practice is simple: treat your agent's operational context — the prompts, the assumptions, the framing, the background knowledge — as a first-class artifact. Not a comment in a script file. A document that gets reviewed, updated, and tested against the current state of the world.
In practice this means:
Version your context. If you can't diff what changed, you can't diagnose why behavior changed. Context that lives in unversioned config or in someone's mental model is context you will lose.
Review context on a schedule, not just when something breaks. Most teams only look at prompts when there's a visible problem. That's too late. A quarterly context review — does everything I've told this agent still accurately describe the world? — is a forcing function for catching drift before it compounds.
Document what assumptions you're making. The most dangerous assumptions are the implicit ones — the things so obvious you didn't write them down. When a new team member onboards, they ask obvious questions that expose implicit assumptions. The same discipline applied to agents (what would we tell a new agent?) surfaces the drift risk.
Build comparison tests. For high-stakes agent outputs, maintain a reference set: examples of correct, well-oriented outputs from when the system was working well. Run new outputs against the reference set periodically — not to check format, but to check framing. Is this agent still oriented the way we want it oriented?
Drift Is an Operations Problem
The reason teams don't catch drift is partly psychological, but mostly structural: we don't have operations practices for agent systems the way we have for conventional software.
Conventional software operations include performance monitoring, error tracking, alerting, on-call rotations, runbooks. We have entire roles — SRE, DevOps, platform engineering — dedicated to keeping software running correctly over time.
Agent operations is a nascent discipline. Most teams are still in the "build and trust" phase. The work of keeping agents oriented — reviewing context, updating assumptions, catching behavioral drift — is work nobody owns, so it doesn't happen until something breaks.
The Drift Problem is a sign that agent systems need ongoing maintenance, not just initial deployment. The context isn't done when you write it. The prompt isn't done when the agent ships. They're living documents in a changing world, and they need the same operational rigor as any other component that runs in production.
Build a chain of command so your agents stay aligned with each other. Then build a context review practice so they stay aligned with reality.
Both problems are older than software. The answers are too.