Give the same task to an agent three times and you’ll get three different implementations. Give a long task to one agent and by the end it’s solving a slightly different problem than the one you started with. Neither of these is a malfunction. It’s the nature of the thing. Agents drift, the way water finds a slope, and any plan for operating them that assumes they won’t is a plan that fails on contact with a real run.
The mistake I see people make, and made myself, is treating drift as something to eliminate. Write a better prompt, add more rules, be more precise, and surely this time it’ll stay on track. It won’t, not reliably, and the effort spent trying to prompt drift out of existence is effort not spent on the thing that actually works: building a system that expects divergence and is designed to catch it.
What drift actually is
Drift is the gap that opens between what you intended and what the agent is doing, and it opens for reasons that are structural, not fixable by being nicer to the model.
An agent works from its context, and its context is always a partial, decaying picture of your intent. Some of the intent was never written down. Some of it got compacted away mid-session, the same context loss that erases decisions and invariants. Some of it the agent inferred and inferred slightly wrong. So the agent is always steering by an approximation of the target, and small errors in the approximation compound over a long run. It fixes the thing in front of it, which subtly shifts what “the problem” means, and it fixes the next thing against the shifted meaning. Step by step, each locally reasonable, it walks away from where you pointed it.
Multiply that by several agents working at once and the divergence isn’t just between agent and intent, it’s between the agents themselves, each drifting in its own direction from a target none of them can see fully. That’s the acute form, the one that shows up as agents poisoning each other at the merge.
Why you can’t prompt it away
The instinct to fix drift with a better prompt fails for a simple reason: the prompt is a snapshot, and drift is a process. You can point the agent very precisely at the target at time zero. You cannot make that precision persist through a long run, because the thing that erodes it, compaction, inference, the accumulation of small local decisions, happens after the prompt is delivered and keeps happening.
A perfect prompt reduces the initial error. It does nothing about the accumulation. This is the same reason a bigger model doesn’t fix long-running work: the model can be smarter and still drift, because drift isn’t a smartness problem, it’s a distance-from-a-fading-target problem. The intended behavior lives in the specification, and the agent’s connection to that specification degrades over the run. Which is why the durable answer is to keep re-anchoring the agent to something that doesn’t fade, and the thing that doesn’t fade is a spec that exists before a line is written and stays readable throughout.
Engineering for divergence
Once you accept drift as a constant, the design changes completely. You stop asking “how do I make the agent not drift” and start asking “how do I catch drift early and cheaply and pull it back.” That’s a system with three properties.
Frequent re-anchoring. The longer an agent goes without being reminded of the target, the further it drifts. So you don’t hand over a huge task and check at the end. You break work into pieces small enough that the agent can’t wander far before it’s re-grounded against the contract. Durable, loadable memory is what makes re-anchoring cheap: the target is right there, in the context, every time, instead of something you have to re-explain.
Checkpoints that measure distance from intent, not just correctness. A normal test asks “does this work.” A drift-catching checkpoint also asks “is this still solving the problem we started with.” Those are different questions. Code can work perfectly and be the answer to a question that drifted away from the one you asked. The checkpoint has to hold the original criteria, not the agent’s current understanding of them, because the agent’s understanding is exactly the thing that drifted.
Reconciliation as a first-class step. When you have divergence, whether between an agent and intent or between multiple agents, you need a deliberate moment to bring it back together, not a hope that it merges cleanly. Reconciliation is where you detect that two changes drifted into conflict and decide which one is right. In multi-agent work it’s the merge. In long single-agent work it’s the checkpoint where you re-score against the original contract. Either way it’s a place in the system, not a stroke of luck.
The coordinator that expects it
Put those together and you get a coordinator whose whole design assumption is that the things it coordinates will diverge. It doesn’t trust an agent’s report that it stayed on track, because a drifted agent believes it’s on track, from inside its shifted understanding. It re-checks against a target the agent can’t move. It catches the divergence at a checkpoint instead of at the end. It reconciles deliberately instead of merging hopefully.
Building that coordinator deliberately, instead of improvising it every session, is the emerging craft of harness engineering: the discipline forming around how you operate agents rather than how they think.
This is the difference between operating agents and hoping agents behave. Hoping doesn’t scale, because every added agent and every added hour is another opportunity to drift, and hope’s success rate falls as the surface grows. A coordinator built for divergence gets steadier as you add agents, not shakier, because catching drift is a designed step and not a lucky outcome.
The whole reason this coordination work is expensive is that today it usually runs on one person, watching for the moment an agent wanders and yanking it back by hand. That’s the most literal version of being the runtime: you, personally, as the drift-detection system. Engineering for divergence is how you move that off yourself, by making “expect drift, catch it, reconcile it” a property of the system instead of a thing you do by staying vigilant. Drift is not the enemy. Pretending it won’t happen is.
Do you catch your agents drifting at a checkpoint, or when something breaks downstream? Tell me on the forum.
Frequently asked questions
What is agent drift?
Drift is the gap that opens between what you intended and what the agent is doing. An agent steers by its context, which is always a partial, decaying picture of your intent — some never written down, some compacted away mid-session, some inferred slightly wrong. It fixes the thing in front of it, which shifts what “the problem” means, then fixes the next thing against the shifted meaning. Step by step, each locally reasonable, it walks away from where you pointed it.
Can you prevent agent drift with a better prompt?
No, not reliably. The prompt is a snapshot; drift is a process. You can point the agent precisely at the target at time zero, but you cannot make that precision persist, because what erodes it — compaction, inference, the accumulation of small local decisions — happens after the prompt is delivered and keeps happening. A perfect prompt reduces the initial error and does nothing about the accumulation over a long run.
Does a bigger model reduce drift?
Not on its own. Drift is not a smartness problem, it is a distance-from-a-fading-target problem. A smarter model can still drift, because the intended behavior lives in the specification and the agent’s connection to that specification degrades over the run. The durable answer is to re-anchor the agent to something that does not fade — a spec that exists before a line is written and stays readable throughout.
How do you stop AI agents from going off track?
You do not prevent drift, you catch it early and cheaply. Break work into chunks small enough that the agent cannot wander far before it is re-anchored to the contract. Use checkpoints that measure distance from intent, not just whether the code works. And treat reconciliation as a first-class step where divergence is brought back deliberately. A coordinator built this way gets steadier as you add agents, not shakier.