Task derailment

Task derailment is the failure mode in which the objective a multi-agent system is working to moves away from the objective it was handed. Each agent restates the goal a little differently as it passes work along, every restatement is defensible on its own, and after several hops the system is solving an adjacent problem with full competence and complete confidence. The thing that drifts is the task. That is what separates derailment from role drift, where the objective stays where it was and what widens is one agent’s sense of which parts of it belong to that agent.

The mechanism is accumulation, and it is the reason the mode survives review at the step level. No hop introduces an error large enough to fail a check written against that hop. A researcher asked to gather evidence on a claim returns evidence on a slightly broader claim; a writer given that evidence frames the piece around what the evidence supports; a reviewer checks the piece against the frame it arrived with. Each transformation is small, locally reasonable, and legible in the trace. The deviation only becomes visible when a late artifact is held against the brief the run opened with, and by then the intermediate work that led there is all internally consistent.

MAST, the empirical taxonomy of multi-agent LLM failures, files derailment as FM-2.3 under inter-agent misalignment, and the category’s own definition names it as one of the four behaviors that constitute the class: “failures arising from ineffective communication, poor collaboration, conflicting behaviors among agents, and gradual derailment from the initial task” (Cemri et al., Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657, v3, NeurIPS 2025 spotlight poster). Its published distribution puts derailment at 7.40% of annotated failures, second of the six modes in that category behind reasoning-action mismatch at 13.2%. Treat those as shares of what a labeling pipeline annotated rather than as rates you should expect from your own graph. MAST built the taxonomy from 150 execution traces read by expert human annotators at kappa 0.88, scaled the labeling across seven frameworks with an LLM-as-judge pipeline, and attributes the distribution to an analysis of 1,642 execution traces with no confidence interval on any of the figures. The revisions do not count the same objects either, since the April 2025 version described over 200 tasks and the October 2025 one reports 1,642 traces. The percentages on this page are from the October 2025 revision.

Downstream, a derailed objective behaves like any other corrupted premise: the next agent treats the restated goal as authoritative and derives more work from it, which is error propagation with an unusually clean audit trail, since every message in the chain is well formed and responsive to the one before it.

How to measure task derailment

The measurement turns on one discipline: score each hop’s working objective against the original brief, never against the hop before it. Compared against its predecessor, every step in a derailed run passes, because the step size is what makes derailment gradual. Compared against the opening brief, the divergence accumulates into something a scorer can see.

Write the objective down in checkable form before the run starts, at whatever granularity the work has: the question to be answered, the artifact to be produced, the constraints that bound an acceptable answer, and the things explicitly out of scope. Then capture each agent’s working objective at each hop, which in most stacks means the task description it received plus whatever restatement it produced. Score each of those against the original as aligned or deviated, and read derailment as the position in the chain where alignment breaks rather than as a single end-of-run verdict. A run scored only at the end tells you that it derailed and leaves you to find where.

Each hop’s score is a proportion over a small denominator, so the same interval discipline that governs any eval confidence interval applies before anyone reads a trend across hop positions, and the pass-rate interval calculator brackets the counts. Two conditions belong beside the rate. Chain length is one, since derailment is a function of how many restatements the objective passes through and a rate quoted without it compares a three-hop pipeline to a twelve-hop one. Whether any hop reformulated the goal in its own words is the other, because a system that forwards the brief verbatim and a system that has each agent paraphrase it are exposed to entirely different amounts of this failure.

Task derailment vs role drift

The two are the same erosion applied to different objects, and our failure-mode pillar draws the line that way: derailment erodes the objective, and the same process applied to an agent’s remit is role drift, where a worker widens what it considers its job over a long run while still returning well-formed output every turn.

They separate on where you look for the evidence. Derailment lives across agents, in the sequence of restatements the objective passes through, so it is found by comparing the goal at hop six against the goal at hop one. Role drift lives inside one agent across time, so it is found by comparing that agent’s late turns against the contract it opened with, holding the objective fixed. A run can carry either alone. A pipeline where every agent stays rigidly inside its remit can still derail, when each one faithfully executes a slightly rewritten task. A single agent can drift far outside its remit on an objective that never moves, which is how a worker ends up making decisions that belonged to the orchestrator while the deliverable is still the one that was asked for.

They also compound in a way that makes each harder to see. An agent that has widened its remit is well placed to restate the objective, since deciding what the task really is now falls inside what it treats as its job. MAST files the two under different categories, and the levers follow the categories: drift is answered by re-asserting the agent’s brief against the original specification at intervals, and derailment by carrying the objective through the run as a fixed artifact rather than as something each hop re-derives.

The wiring decides how far it travels

Derailment needs hops, so the topologies that give it the most of them are where it does the most damage. Our topology analysis names it among the modes that bite hardest in an orchestrator-worker arrangement, where the hub redistributes a worker’s return and every subtask it then derives stands on that return. It is equally at home in a sequential pipeline, where the propagation behavior is monotonic compounding: each stage consumes the last, an early deviation is amplified by everything downstream, and there is no path back.

The structural counter is to stop treating the objective as something that flows through the pipeline at all. Hold the original brief as a fixed artifact every agent reads from directly, rather than as a description each agent receives from its predecessor and passes on rewritten. That converts a chain of restatements into a set of independent readings of one document, which does not remove the failure and does remove its ability to accumulate. Which pattern you pick sets how much of this you are exposed to before any agent code is written, an argument made in full in the reliability case for choosing an orchestration pattern.

A system that derails returns work no one asked for, on time and in the right format, which is why the check that catches it has to be against the original brief and not against the run’s own account of itself. The rest of the terms in this family are indexed in the term-by-term guide to multi-agent failures, and how each category propagates and which lever bounds it is worked through in the multi-agent failure taxonomy.