What Is Agent Drift (and How Do You Catch It)?

Quick answer
Drift is the gradual divergence between the task and what the agent is doing, usually caused by accumulated context rather than one wrong decision.
It shows up as scope creep, convention slips, repeated attempts at a solved problem, or a plan file that no longer describes the diff.
Long runs drift more, because compaction, tool output, and unrelated discoveries push the original objective out of context.
Catch it at checkpoints: compare the diff with the plan after every verified step, not at the end of the run.
The fix is to restate the boundary, not to ask the agent to try harder.

What does agent drift look like?

It looks like competence applied to the wrong problem. The agent starts on the requested fix, notices a related inconsistency, improves it, then adjusts the tests to match the improvement. Every step is locally reasonable and the final diff no longer answers the original request.

A second form is convention drift: the agent stops using the project’s helper, invents a new utility, or changes an error format. This often follows compaction, when the earlier instruction is summarised and its specifics are lost.

Why does it happen?

Context is finite and is continuously rewritten. Every tool output, file read, and correction competes with the original objective, and summarisation preserves the gist while dropping exact constraints. A constraint that was stated once at the start is the most likely thing to disappear.

Optimism compounds it. Agents prefer to make progress, so when a step is blocked they find a different step to take. Without a stop condition, that becomes an unplanned detour that the final summary presents as part of the work.

How do you catch drift early?

Put the plan in a file and diff against it. After each verified step, the agent should mark the step done and state what it is doing next. If the next step is not in the plan, that is the checkpoint where you decide whether to allow it.

Watch three signals: the changed-file list growing beyond the plan, the same test failing repeatedly with different attempted fixes, and the agent explaining why an unrelated change was necessary. Each one is a boundary question, not a technical one.

How do you correct it?

Restate the objective, the boundary, and the next step, and ask the agent to summarise the current diff against the plan. If the diff contains work outside the boundary, revert it rather than asking the agent to unpick it — reverting is deterministic and unpicking is not.

Then tighten the setup: add the missing constraint to AGENTS.md or the plan template, and shorten the run. Drift is a symptom of a run that was too long or too loosely specified for the context it needed.

Where this bites vibecoders
A generated final summary will describe the drift as initiative: “also improved error handling while I was there.” That is the moment to check the file list. The improvement may be fine, but it was not asked for, tested, or reviewed as part of the task.

Where AI coding assistants get this wrong

Letting the agent improve unrelated code it noticed along the way.
Treating a long run as evidence of thoroughness.
Skipping checkpoints until the run ends.
Asking the agent to unpick out-of-scope work instead of reverting it.
Stating a constraint once at the start and never again.
Accepting a final summary that does not match the diff.

Checklist

Keep the plan in a file the agent rereads.
Review the changed-file list at every checkpoint.
Revert out-of-scope work rather than negotiating it.
Restate the boundary after any compaction or handoff.
Keep runs short enough that the objective survives.
Record recurring drift as a rule in AGENTS.md.

FAQ

Is drift the same as hallucination?

No. A hallucination is a false claim; drift is a true statement about the wrong work. The agent may write correct, well-tested code that solves a problem nobody asked it to solve, which is harder to spot because nothing in the diff looks broken.

Does a bigger context window fix it?

It delays it. A larger window holds the objective longer, but attention still dilutes as the context fills with tool output and code. A written plan and periodic restatement are more reliable than capacity.

Can drift happen in a short run?

Yes, if the task is ambiguous. A short run can drift immediately by choosing the wrong interpretation. That kind of drift is better prevented with a spec or plan mode, because there is no checkpoint history to inspect.

How do I measure it?

Compare the changed files with the plan at each checkpoint and count the files that were not planned. A run with no unplanned files is on task; a run with several is drifting, regardless of whether the result works.