Originally published on Loop & Retry — field notes on building LLM agents that survive production.
A single agent that drifts keeps working: loop drift is the failure mode where an agent stays busy — narrating progress, burning tokens, taking actions — without getting any closer to done. A multi-agent crew has a stranger version of the same failure, and it's arguably worse, because nothing about it looks stuck. Every agent in the crew is making real, forward, individually defensible progress. The crew keeps shipping outputs. And the whole operation is still moving further from the goal you actually gave it with every step. Call it multi-agent goal drift: not a crew that stalls, but one that steadily walks off the original objective while every individual handoff looks like solid work.
This is the second companion post to failure modes in multi-agent teams, after split-brain. That post's third failure mode, context fragmentation, sits close to this one and is worth separating cleanly. Context fragmentation is a single lossy event — the goal gets split across agents at one handoff, and a load-bearing detail falls into the gap between two context windows during that one split. Goal drift isn't a single event, it's compounding. It shows up in crews that run several sequential handoffs — a planner to a builder to a reviewer to a closer, or the same handoff shape looped across iterations — where each individual hop reshapes the goal by an amount too small to flag on its own, and only the sum, after enough hops, is unrecognizable. Split-brain, for comparison, is agents disagreeing on facts — two copies of a store diverging on what the current state is. Goal drift is agents agreeing perfectly on the facts and quietly disagreeing, without anyone noticing, on what they're for.
It's also adjacent to multi-agent context drift — the information a crew holds about a fixed objective going stale or inconsistent across agents — but that's a claim about the crew's beliefs. This is a claim about the crew's target. A crew can have perfectly fresh, perfectly consistent context about the wrong goal, which is exactly what happens below.
A concrete failure
Three agents build a feature end to end: a planner turns a user request into a spec, a builder implements it, and a closer reviews the diff and merges. The request: "Add a cache in front of the search endpoint to cut p99 latency — do not change the public API contract." The planner writes a reasonable spec: add a cache layer, wire it into the search handler, add invalidation on writes, expose a metric for hit rate. Each subtask inherits the tasks from that decomposition. It does not inherit the constraint. "Do not change the API contract" never makes it past the planner's own reasoning, because it isn't a task — it's a boundary, and boundaries don't fit cleanly into a task list.
The builder implements the cache. To make it debuggable, it adds an optional ?cache=bypass query parameter — a small, sensible, entirely well-reasoned addition, and a genuine change to the public contract. The builder's own acceptance criteria — tests pass, cache works, hit rate is measurable — never mention the contract, because that criterion lived only in the original request, two hops upstream, and nothing carried it forward. The closer reviews the diff against the builder's stated intent — "add a debug bypass parameter" — and approves it, because relative to that spec, the change is correct. Ship it. The contract broke. Every agent along the way did defensible work. The diff that actually broke the promise passed review, because review was checking the wrong reference point: the nearest upstream spec, not the original ask.
Continue reading: the rest of this post — including the sections that follow — is on Loop & Retry: read the full article
Top comments (0)