/p/2026-08-31 · explainer
Paper explainer · 2608.26225 · Shaikh, Bombarde, Pathak

Every call succeeded.
The run was dead for eleven minutes.

When an orchestrator has to retry, resume and budget its agents, everyone reaches for the same toolkit: retry, timeout, error-rate circuit breaking. That toolkit was built for stateless service calls, and this is a failure study of what happens when you point it at delegations an agent cannot un-do. Over 147 numbered incidents across 81 runs of one production agent platform — most with a mutation proof reproducing the failure — all three of its assumptions break. A loop issued the same tool call 54 times in eleven minutes and every single call returned success, so no error-rate breaker could ever have fired. A progress signal computed over a value that is constant by construction guaranteed a healthy run would be declared stalled on its third repair round, taking it from six working components to three. And twelve incidents record the safety layer blocking correct work, the worst burning 107 agent turns for zero accepted writes.

01 · The problem

Three assumptions, none of them true here

A service mesh gets to assume three things, and every one of them is load-bearing. Requests are idempotent, or can be made so with a key you supply in advance. Failure shows up as an error, so counting errors tells you when to stop. And a discarded request costs nothing, so retrying is free.

An agent delegation breaks all three at once. The set of operations it will perform is generated at inference time, so you cannot enumerate an idempotency key before it runs. It can fail while every call in it returns success. And it spends tokens whether or not you keep the work, so a discarded delegation is a real, billed loss.

Interactive · run the loop past your breakererror-rate breaker, threshold 50%
error rate
what the breaker is watching
distinct payloads
what would actually have told it something

02 · The incidents

Five ways a healthy run gets killed

The study's value is that these are numbered incidents with costs attached, taken from the platform's own durable records — persisted attempts, recovery leases, budget documents, structured failure envelopes — rather than reconstructed after the fact. Where a diagnosis is called confirmed, it means the fix was reverted and the failure came back.

Step through them. The pattern that connects them is not a bug in any one guard; it is that each guard made a confident decision on evidence that could not have told it otherwise.

Interactive · step the incidents, flip the point of viewcosts from the platform's own records
03 · The diagnosis

An identity that cannot tell two things apart

Five separate subsystems failed the same way, and two of the teams derived the corrective rule independently without knowing the other had. In each case a guard keyed its decision on an identity that could not discriminate between the two situations it needed to separate — and then answered confidently anyway.

The dual of that is the rule worth taking away. A reliability decision may only be taken on evidence that is capable of moving, attributable to the thing it claims to measure, and deterministic under identical conditions. Every incident above fails at least one of those three tests, and you can check your own guards against them this afternoon.

Five subsystems, one failurewhat each keyed on
04 · The proposal

Break on progress, not on errors

Seven primitives come out of the study, and their common move is to change the unit of enforcement from the message to the delegation. Trip the breaker on a no-progress signature rather than an error rate, and compute that signature against a vocabulary the strategy re-emits unchanged by construction. Compile the effect declarations rather than hand-writing them, and observe committed effects at a boundary that needs no cooperation from the agent.

Two are worth calling out for anyone running agents today. Budgets should attenuate rather than kill — the first graded stop grants one more round on a stronger model. And the enforcement layer has to prove at runtime that it is not blocking correct traffic, with refusal verdicts distinct enough to tell "suppressed as duplicate" from "refused as stalled".

Interactive · pick a primitiveseven, keyed to the incidents above
05 · For your own orchestrator

Audit your guards against the three tests illustrative

Take the guards you already run. For each one, ask the three questions: can the signal it reads actually move when the thing it measures changes? Is it attributable to that thing, rather than to something correlated with it? And does it give the same answer twice under identical conditions?

Toggle them below. A guard that fails any of the three is not conservative or aggressive — it is confidently wrong on a schedule, and it will cost you an incident like one of the five above.

Interactive · check a guard against the three testsillustrative
The numbers

What the paper actually reports

What this does not show

In practice