Error propagation is what happens when one wrong output in a multi-step AI agent becomes the input to the next step, and the mistake spreads instead of being caught. A single hallucinated fact, a misread tool result, or a fabricated argument in step three does not stay in step three. Step four reasons over corrupted context, step five inherits both errors, and the final answer is confidently wrong. The arithmetic is unforgiving: an agent that is 99% accurate at every single step is only about 37% likely to finish a 100-step task cleanly, because reliability multiplies rather than averages. This is the failure mode a pilot almost never surfaces, because a pilot runs the happy path once while someone watches.
This post explains where propagation comes from, why demos hide it, and the architectural moves that actually contain it.
What is error propagation in an AI agent?
Start with the model that most teams carry in their heads and get wrong. If each step in a workflow succeeds with probability p, and the steps are independent, the chance that an N-step chain completes without a single error is p raised to the power N. Run the numbers and the intuition breaks. A per-step accuracy of 95%, which sounds strong, gives you roughly 77% success across five steps and about 0.6% across a hundred. Push per-step accuracy to 99% and a hundred-step chain still finishes cleanly only around 37% of the time. The Corvair.ai and Highland Edge write-ups on the compound-error problem lay this out plainly: excellent per-step numbers still add up to a coin-flip system.
Now make it worse, because the real world is worse than the independent-error model. Steps in an agent are not independent. When a language model reads context that contains its own earlier mistake, it tends to treat that mistake as established fact and build on it. Step three produces a flawed intermediate result, step four operates on corrupted context, step five operates on corruption plus whatever step four added. Errors are correlated, and correlation makes the true success rate lower than p to the N predicts. That is the difference between an error and a propagating error: an error is a local defect, propagation is a defect that recruits every downstream step into repeating and amplifying it.
What is hallucination propagation specifically?
Hallucination propagation is the sharpest version of the problem, because a hallucination looks exactly like a correct output to the next step. There is no exception thrown, no null returned, no status code to branch on. The model invents a plausible value and hands it forward with full confidence, and the rest of the chain has no signal that anything is wrong.
Agent architectures add failure surfaces that a single prompt never had. A 2025 survey on agent hallucinations catalogues the agent-specific modes: parameter fabrication, where the model invents an argument to satisfy a tool signature it does not fully understand; tool-output misinterpretation, where a correct result is read incorrectly; and cross-turn memory corruption, where a bad fact written to state early poisons every later retrieval. Each of these produces output that is well-formed and wrong. In a multi-agent setup the surface grows again, because one agent's fabricated claim becomes another agent's trusted premise, and coordination itself becomes a channel for spreading errors.
Why do pilots never catch it?
Because a pilot and a production run are different statistical events. A pilot is a short chain, executed a handful of times, on inputs the builder chose, with the builder watching each step. Under those conditions propagation barely has room to operate: few steps mean p to the N stays high, a friendly input means the model rarely hallucinates, and a human in the loop silently corrects the one drift before it compounds. The demo works. Everyone signs off.
Production inverts every one of those conditions. The chains are longer, the inputs are ones nobody anticipated, the volume is thousands of runs a day, and no one is watching step four at 2am. The same agent that looked 95% reliable in a ten-run pilot now executes a longer workflow across a much wider input distribution, and the compounding that the pilot's short happy path suppressed is suddenly the dominant behaviour. This is why teams are consistently surprised. The pilot did not measure the thing that breaks.
Anthropic made the point directly in its engineering write-up on building a multi-agent research system: agents are stateful and errors compound, so a minor failure early can cascade into large behavioural changes downstream (Anthropic, June 2025). The same team noted that their multi-agent setup burned roughly 15 times the tokens of a normal chat, which points to the second cost of propagation: a chain that has gone wrong often keeps working, retrying, and spending while it does.
Where do the errors actually start?
If you want to contain propagation you have to know where it originates, and the honest answer is that most of it is designed in before the model runs. The UC Berkeley Sky Computing Lab studied this directly. Its Multi-Agent System Failure Taxonomy, MAST, analysed execution traces across seven popular multi-agent frameworks and sorted the failures into 14 distinct modes under three categories: system design issues, inter-agent misalignment, and task verification failures. The headline finding for anyone building these systems is that failures cluster in specification and coordination rather than raw model capability. Step repetition, disobeying the task specification, and never recognising a termination condition were among the most common modes (MAST, March 2025).
Read that against the propagation lens and it fits. An ambiguous role definition or a vague tool contract is an invitation for the model to guess, and a guess is a hallucination waiting to be handed downstream. A missing termination condition is a chain with no upper bound on N, which is the one variable that most punishes per-step error. The errors that propagate worst are usually the ones the architecture never gave the agent a way to avoid.
How do you contain error propagation?
You cannot drive per-step error to zero, so you engineer the chain to stop errors from travelling. Four moves do most of the work.
Shorten the chain. Because reliability is p to the N, every step you remove raises whole-chain success more than a marginal accuracy gain does. Reducing per-step error from 1% to 0.5% lifts a 100-step success rate from roughly 37% to 61% (Lens, 2026), and cutting the step count outright often beats both. The most reliable agent is frequently the one that does less.
Break the chain into checkpointed units. Decompose the task so each sub-task produces output that can be validated on its own before it enters any downstream context. A typed, narrow tool contract with validation on every input and output turns silent corruption into an explicit failure the loop can catch. An error that is caught at the boundary of the step that produced it has no chain left to propagate through.
Verify at the seams, not only at the end. Add a distinct checking step between stages: a schema check, a constraint the intermediate result must satisfy, a second model asked only to confirm rather than to generate. MAST names task verification as its own failure category for a reason. Chains that verify at the seams catch the fabricated value while it is still local.
Cap N and hand off. Give every agent a hard step budget and an explicit definition of done, so a chain that has gone wrong stops rather than spending tokens forever. Where the stakes are clinical or regulatory, route the consequential decision to a human before the action fires. Autonomy is a dial you raise with evidence from your own traces, starting low.
None of this shows up in a demo, which is exactly why it gets deferred and exactly why the deferral is expensive.
Where this lands for regulated work
In a marketing chatbot a propagated error is an awkward sentence. In a clinical intake or a compliance check it is a wrong instruction delivered with total confidence, and under India's DPDP Act 2023 a fabricated action against a patient record counts as a governance event rather than a bug ticket. That raises the bar on the containment above from good practice to a requirement you have to be able to defend to an auditor.
This is the shape we build to at Nextdot. Our voice-first customer-experience agents run in production at Narayana Health and Gleneagles, with a further deployment in build at Fortis Mulund, on short verified chains with explicit stop conditions and a human handoff before anything consequential. Clients rarely ask about error propagation in the first meeting. It is usually the reason the system is still running in the eighteenth month.
Frequently asked questions
What is the difference between a hallucination and hallucination propagation?
A hallucination is a single fabricated or incorrect output. Propagation is what happens when that output becomes the input to a later step and the chain reasons over it as if it were true, so one local error spreads and compounds into a wrong final result.
Why does per-step accuracy matter so much in agents?
Because reliability multiplies across steps rather than averaging. If each step succeeds with probability p, an N-step chain succeeds with p to the power N, so even 99% per-step accuracy falls to roughly 37% over a hundred steps. Small per-step gains produce outsized whole-chain improvements.
Why do multi-step agents pass pilots and fail in production?
A pilot runs a short chain, a few times, on chosen inputs, with a human watching and quietly correcting drift. Production runs longer chains thousands of times on unanticipated inputs with no one watching, which is precisely the condition under which errors compound.
Do multi-agent systems reduce or increase error propagation?
They can do either. Splitting work across agents can isolate errors, but coordination adds new failure surfaces where one agent's fabricated claim becomes another's trusted premise. UC Berkeley's MAST study found many failures come from inter-agent misalignment and specification gaps rather than raw model limits.
How do you actually stop errors from propagating?
Shorten the chain, decompose it into independently validated units with typed tool contracts, verify at the seams between steps rather than only at the end, and cap the step count with an explicit stop condition and a human handoff before consequential actions.