AI Agent Drift: The Five Failure Layers, Diagnosed
AI agent drift isn't one bug — it's five distinct failures in five harness layers. We run 10+ agents in production. Find the layer first, then fix it.
Every AI agent in production drifts. The question is from what, in which direction, and what it costs you when it does. We run ten-plus agents on our own capital, around the clock, and we’ve spent twelve months learning that “agent drift” is a useful word and a useless category. It describes five different failures that look similar and have nothing in common underneath. Death spirals are not the same problem as false-done claims. False-done is not the same as instruction bloat. Instruction bloat is not the same as session memory loss. Each lives in its own layer of the harness. Each has a different diagnostic, a different fix, and a different metric. This page is the map. Five named failure modes. Five linked guides that show you how to measure and fix each one yourself. One thread tying them together: when teams describe drift, they almost always describe a layer, not a tool. Find the layer first. Then pick the tool.
Drift is not one thing
“My agent drifts” is five different bug reports wearing one label. A death spiral that burns tokens has nothing in common with an agent that quietly violates a project convention, which has nothing in common with an agent that forgets yesterday’s decision. They look alike from the outside — the agent did something you didn’t want — and underneath they are unrelated failures with unrelated fixes.
This is why most “agent reliability” advice fails. It treats drift as a single condition and prescribes a single remedy — a better prompt, a memory plugin, a stricter system message. But a memory plugin does nothing for a missing verification gate, and a stricter prompt does nothing for an environment that can’t reproduce CI. Mixing up the five modes is the root error. Name the mode and the fix becomes obvious; leave it unnamed and you’ll keep applying the wrong tool to the wrong layer.
- Drift in intent. The agent solves the wrong thing — precisely. Clean execution, wrong target. (Layer 1.)
- Drift in honesty. It reports “done” on work that isn’t, and skips the gate that would have caught it. (Layer 4.)
- Drift in memory. Yesterday’s decisions get undone today; every session re-derives the same facts. (Layer 5.)
- Death spirals & bloat. Infinite loops burning tokens (L4+L1); instruction files so large the agent ignores them (L2+L1).
The five layers, recast as drift modes
Each drift mode lives in exactly one layer of the harness — the environment around the agent, not the model inside it. Attribute the failure to a layer, and you know which diagnostic to run and which fix to apply. Here is the whole map.
L1 — Vague spec → drift in intent
No explicit, checkable Definition of Done. The agent decides for itself what the task means and solves the wrong problem — precisely. The diff is clean; the target is wrong.
L2 — Unknown convention → drift in style
The project’s unwritten rules aren’t discoverable from local context. The agent ships a clean diff that quietly breaks a contract. Correct-looking, convention-violating.
L3 — Incomplete environment → drift in reproducibility
Build / test / run commands aren’t obvious, so the agent can’t actually exercise its change. It passes on its machine and fails in CI. Works-here, breaks-there.
L4 — Missing verification → drift in honesty (the false-done layer)
No one-command gate the agent must run, so “said done, wasn’t” ships. The agent claims green, the suite is red, and it never noticed because nothing forced it to look. This is gate blindness — the verification gap.
L5 — Context loss → drift in memory
Knowledge re-derived every session; no standing artifact carries decisions forward. Yesterday’s call gets reversed today, and the same mistakes recur on a loop.
Why “layers,” not a checklist. A layer tells you not just what broke but where the fix has to live. A false-done claim is never fixed by a better prompt — it’s fixed by a gate (L4). A forgotten decision is never fixed by a gate — it’s fixed by a standing context artifact (L5). The layer is the routing key.
Where each guide fits
Each drift mode has its own standalone guide — how to measure it, what the signature looks like in your logs, and the specific fix. Start with whichever failure you’re seeing most. Each guide maps to the layer it lives in.
- Layers 4 + 1 · death spiral. Stop the AI agent death spiral and token burn — Why your AI agent gets stuck in an infinite loop, retries the same failing action, and burns tokens — and the gate that breaks the spiral.
- Layer 4 · verification gap. Why your AI agent says “done” when it isn’t — The verification gap explained: how to measure how often your agent reports success on work that failed, and how to close it.
- Layers 2 + 1 · instruction bloat. The .cursorrules / AGENTS.md size problem — When your instruction file gets so big the agent ignores half of it — how to measure instruction bloat and what to cut.
- Layer 5 · context loss. Why your AI agent forgets between sessions — Cross-session context loss: why the agent re-derives the same facts every session, and the standing artifact that carries memory forward.
- Layers 4 + 3 · the local gate. The verification gate your AI agent is skipping — How to build the one-command local gate the agent must pass before it can claim done — the single highest-leverage harness fix.
The one diagnostic anyone can run today
You don’t need our tool to start. You need ten runs and an honest label. Here is the whole procedure — it takes about twenty minutes and it points you straight at where to invest first.
- Pull your last 10 agent runs. Any ten recent tasks where the agent did something you didn’t want, or claimed something that wasn’t true. Logs, diffs, transcripts — whatever you kept.
- Label each by layer. For each failure, ask: which of the five layers does it live in? Wrong target (L1), broke a convention (L2), failed in CI (L3), false-done (L4), forgot a prior decision (L5). One label each. Be strict.
- Read the histogram. Tally the labels. The tallest bar is your dominant drift mode — and the layer where one fix buys the most reliability. That’s where you invest first, not wherever the loudest blog post points.
The histogram is the insight. Most teams discover their drift is concentrated in one or two layers, not spread evenly. You don’t need five fixes — you need the one that clears your tallest bar. The label is what tells you which.
What the SERP misses
Search any of these failures and the internet hands you a tool. Better .cursorrules for bloat. A memory plugin for context loss. A cloud verifier for false-done. Each answer treats drift as a tooling problem — buy the right plugin and the symptom goes away.
They’re operating-model problems, not tool problems. Each has a measurable signature in your logs — a histogram of false-done claims, a count of re-derived facts, a token-burn loop length — and the tool only matters once you know which layer the signature points to. Buy a memory plugin to fix what’s actually a missing verification gate and you’ve spent money moving the wrong lever. The layer comes first; the tool is a downstream choice.
The signature, then the tool. Every one of the five modes leaves a measurable fingerprint. Measure it, attribute it to a layer, then choose a tool — and you’ll buy the one that actually moves your tallest bar instead of the one that ranked highest on Google.
Why a model upgrade doesn’t fix drift
The instinct, when an agent drifts, is to reach for a bigger model. We tested that instinct directly. In our harness experiments we held the model constant and varied only the environment around it — the spec, the conventions doc, the dev setup, the gate, the context artifact.
Same model, same task, varied environment:
| Environment | Success rate |
|---|---|
| Bare prompt, no harness | 20% |
| + spec / DoD (L1) | 45% |
| + conventions + dev env (L2/L3) | 70% |
| + verification gate (L4) | 90% |
| + cross-session context (L5) | 80–100% |
Model never changed. The harness did all the work.
Success went from 20% to 80–100% without touching the model. The harness was the bottleneck the whole time. A bigger model fails the same way — it just fails more confidently. If drift is killing you, the model is almost never the lever. The layer is.
What a Harness Health Check does
The five guides let you start by hand — pull ten runs, label them, fix your tallest bar. The audit closes the loop. It’s a Claude Code skill plus agent that maps your system against all five layers automatically, runs on your machine, and hands you a verdict you can act on.
- Maps your system against the five layers. Reads your specs, conventions, dev setup, gate, and context artifacts — and scores each layer against what we actually run on ourselves.
- Scores each layer and flags the heaviest drift. Tells you which layer is carrying your reliability and which is the open hole — your tallest bar, found for you instead of by hand.
- Gives a prioritized fix list (closes the loop). Not a generic checklist — findings anchored to evidence in your own artifacts, ordered by impact, with effort estimates. Start with the free guides; the audit tells you exactly where to spend the effort.
The guides start it; the audit closes it. Free, MIT-licensed, runs entirely on your machine, and honest enough to tell you when your harness already holds and the problem is elsewhere. No pricing page waiting at the end.
- Pull your last 10 agent runs — logs, diffs, transcripts of tasks the agent did something you didn't want, or claimed something that wasn't true.
- Label each failure by layer: wrong target (L1), broke a convention (L2), failed in CI (L3), false-done (L4), forgot a prior decision (L5). One label each.
- Tally the labels. The tallest bar is the dominant drift mode — invest there first.
- Attribute the failure to a layer before picking a tool. A false-done claim is fixed by a gate (L4); a forgotten decision is fixed by a standing context artifact (L5).