Anyone who has built against a payments API knows the problem. A request times out, and the client can't tell whether the charge went through or never arrived. Retry and you might bill the customer twice; give up and you might not bill them at all. Agents that publish posts, send email and trigger deployments inherit the same ambiguity, and a study out of Microsoft asked whether the fix belongs in the model, in the agent harness, or in the API being called.
The test was a sandbox of simulated services with faults injected at the service boundary and a ledger recording what actually committed. Frontier models handled the textbook case almost perfectly, a write that succeeded but whose acknowledgement was lost. They read back before retrying, and almost never duplicated. That is the distributed-systems folklore working as intended.
It stops working the moment reading back can't help. When the timed-out request was still in flight, or the network delivered it twice, the same frontier models duplicated the action in more than half and roughly three-quarters of runs. A read-back issued before the original commits sees nothing, so the agent decides the write never happened and sends it again. The paper proves this one can't be solved from the client side at all.
What did solve it was changing the API. Offering an idempotency key on every write, the decades-old remedy already standard at Stripe and AWS, dropped the duplicate rate from 28% to 4%, with nothing else altered. Agents reached for the keys unprompted.
"The most effective intervention we measured is not a better model but a contract that makes repetition harmless."
In 90% of runs where the agent had duplicated something, it signed off reporting the task complete. Nothing in the output flagged a problem.
"A human reading the final report would have had no reason to check."
Three things follow for anyone pointing agents at production systems. This is an API-design question, not a model-selection one, because the off-the-shelf agent tools tested all behaved much the same, so switching harness buys nothing. The audit to run is on your own write endpoints, to find which accept an idempotency key, and which will cheerfully execute twice. Next, treat the transparent retry sitting in most HTTP client libraries as a liability. It made things measurably worse here, turning a lost acknowledgement into a duplicate before the model saw the error at all. And a status endpoint that lags behind reality was worse than having none at all, because agents trusted the stale read rather than escalating. Which suggests a half-reliable way to check may be the worst option on the table.
What this can't tell you is how often any of it happens. The services were simulated, and the study never measures the real-world rate of these faults. It establishes what agents do when a write goes ambiguous, not how often yours are hitting that case. On this evidence the fix is cheap enough that the base rate hardly matters.
Sources
- Li, J., "Where Does Exactly-Once Live? Model, Harness, and Tool-Contract Effects on Duplicate Side Effects in LLM Agents" — https://arxiv.org/abs/2609.29095