/p/2026-08-07 · explainer
Paper explainer · 2608.05263 · Chen et al.

Retrying will not fix
your pipeline.

Multi-agent pipelines get scored on whether the final answer came out right, which tells you nothing about which hop broke or how far the damage travelled. This injects known faults into templated workflows and measures both. Two things fall out. A router that dispatches on keywords handles every well-behaved case and 0% of adversarial ones — while a crude baseline that merely reads the task description gets all of them. And retrying only repairs the failure you were least worried about: a failed tool call recovers fully, an ambiguous hand-off 30% of the time, and the three semantic faults never.

01 · The problem

Two kinds of fault, and only one of them announces itself

The harness injects five failure modes into a chain of dependent steps, then checks the final result against a value that can be verified exactly — no judge, no annotation. That design gives a clean answer to a question production teams rarely get to ask: when this breaks, does the pipeline notice? Pick a failure mode and watch what happens to the stages after it.

Interactive · inject a fault into a five-stage chainrecovery and spread measured
00.51.0 recovered
final answer still correct
stages corrupted downstream

The split is the whole finding. A tool that fails is loud — the agent sees an error, recomputes by hand, and the chain closes with a fully correct answer and zero stages damaged. A tool that lies, or a hand-off that was ambiguous, or a step that ran out of order, produces no error at all. The pipeline continues confidently on corrupted state, and the paper's line on it is blunt: retrying reproduces the fault and only lengthens time-to-detection.

02 · The router

Keyword routing is not a cheap version of routing

Every orchestration framework needs to decide which agent handles a request, and the cheap default is to match on keywords or flags in the input. On a gold-labelled diagnostic split into well-behaved and adversarial cases — where the surface markers are missing, or point the wrong way — that default does not degrade. It goes to zero. Step through the four policies.

Interactive · four routing policies26 gold-labelled cases · 16 aligned, 10 adversarial
050100% correct

The control that makes this land is the third policy. A plain term-frequency baseline — no model, no reasoning, it just reads the task description instead of the flags — scores 100% on the adversarial set. So the keyword router's blind spot is not that the cases are hard. It is that the mechanism looks at the wrong field. That is a bug you can fix without buying an inference call.

03 · The spread

Every stage you add gives the fault another stage to eat

Cascade radius counts how many downstream stages a single injected fault corrupts. For the three semantic modes it does not plateau and it does not decay — it tracks pipeline depth almost linearly, at roughly nine tenths of a stage for every stage you add. Drag the depth and watch the damage grow.

Interactive · pipeline depth against blast radiussemantic modes pooled · 120 runs per depth
02.55 stages

Read that as a design constraint rather than a curiosity. Adding a stage to a pipeline does not add one stage of risk — it adds one stage of risk multiplied by everything downstream of it that a silent fault can now reach. And because the three cascading modes produce no error to catch, depth buys you nothing but a longer interval before anyone notices.

04 · The catch

The right answer can come out of an unusable pipeline

The last experiment is the one that should change how you review an orchestration design. Two policies are given a composite task with a known three-step structure: one decomposes it, one answers it monolithically. Both get the final answer right, every time. On the metric everyone tracks, they are identical.

Interactive · same task, same final answer40 runs · known three-step structure
050100%
final answer correct
identical for both policies — this is the number a normal benchmark reports
delegable structure exposed

A monolithic solve that scores 100% on final accuracy exposes 37% of the sub-structure and wastes two sub-tasks doing it. You cannot route what was never decomposed, you cannot retry a step that was never a step, and you cannot attribute a failure to a stage that does not exist. The accuracy number is real and it is also completely uninformative about whether the thing is operable.

05 · In your stack

What to instrument first illustrative

The paper's own conclusion is that detection and attribution, not blind retry, are the containment mechanism — which is a statement about what you build, not what you buy. Set your pipeline depth and your rough split of loud versus silent faults, and see where the undetected work ends up.

Interactive · your pipeline against the measured spreadspread measured · your depth and fault mix are illustrative
stages corrupted per silent fault
at the measured cascade radius for your depth, pooled over the three semantic modes
faults a retry would actually fix
the loud ones — a retry recovers those completely and does nothing for the rest

The cheap instrumentation, in the order the paper's findings justify it: assert on the shape of each hand-off rather than only the final answer, log which agent was selected and why so a routing mistake is attributable after the fact, and route on the request text rather than on flags — the last one costs nothing and closed the entire adversarial gap here.

The numbers

What the paper actually reports

What this does not show

In practice