Imagine tapping “pay” on your phone. The screen freezes, then an error appears. You open your bank app before trying again because the message cannot tell you whether the charge went through.
That small pause matters. An AI assistant can face the same uncertainty after it sends a payment, adds a customer, books a reservation, or emails someone. The outside system may complete the action while the reply gets lost. If the assistant treats every timeout as a failed action, its second attempt can become the mistake.
Because a timeout does not settle the external result, a new paper tests a way to handle that gap. Its results come from a simulation, so they cannot tell us how often deployed AI agents create duplicates. They can still help us ask a sharper question about any system that acts in the world: What happens when the assistant cannot tell whether its first move worked?
The message and the world can disagree
An AI assistant reaches outside itself through tools. One tool may talk to an appointment service. Another may update an invoice system or send a message. The agent issues a request, the external service acts, and a reply comes back.
A clean reply makes the next step easy. A timeout does not.
The request may have failed before reaching the service. It may have succeeded while the reply died on the way back. The service may have completed only part of the work. Engineers call this kind of uncertainty a non-atomic failure. From the agent’s point of view, “error” and “nothing happened” are no longer the same thing.
This mechanism is the subject of a July 31 preprint by researchers Isham Kalappurackal Mansoor, Abhishek Phadke, and Pratip Rana titled Verified Tool Calls Improve LLM Agent Reliability Under Non-Atomic Failures. They built a controlled simulator with two workflows: activating a customer and recording an invoice. One version of the agent retried after an ambiguous failure. A second version checked the outside system first, then retried only when that check indicated the action had not completed.
At the highest fault level, the retry-only agent produced duplicate effects in 72 percent of customer-activation runs and 76 percent of invoice runs. The verify-before-retry wrapper reduced both figures to 20 percent. On customer activation, successful completion rose from 64 percent to 100 percent. Invoice completion was already high under both approaches.
The authors describe the danger plainly: “When the agent retries without checking the true state of the world, it can create duplicate actions, incorrect final reports, or false success states.”
Why the percentages need a warning label
But these results are evidence from a recent preprint, rather than a field measurement of products people use today. The experiment used one model, Google Gemini Flash-Lite, inside a simulator. It covered two tasks, hand-designed checks, and 25 episodes for each method at each fault level. The faults were injected by the researchers. The wrapper also left duplicates on the board. Verification can read stale information or miss a partial result. A check that asks only whether a record exists may overlook whether every field is correct. The study’s separate ablation used a different setup, so its percentages cannot be combined with the main results.
This paper supports a mechanism: uncertain replies can trigger harmful retries, and checking external state can reduce that risk under the tested conditions. It does not establish a universal duplicate rate, prove that one wrapper fits every workflow, or show how well the approach performs across real payment, email, database, and booking systems. That boundary matters because a dramatic laboratory percentage can travel farther than its limitations. The practical lesson survives without inflating the claim.
Payment systems already recognize the problem
Distributed systems have dealt with uncertain replies for years. AWS engineer Malcolm Featonby explains the issue in the company’s Builders’ Library: “Simply retrying the request could result in multiple workloads, which could have dire consequences.”
So engineers often use an idempotency key. Think of it as a stable claim ticket attached to one intended action. If a client repeats the request with the same key, a service can recognize that both attempts belong to the same job.
This is where Stripe offers a concrete example. Its API accepts an idempotency key with a POST request, stores the first result associated with that key, and returns that result when the same request arrives again. Stripe also compares the request parameters. Reusing the key for a different request produces an error instead of quietly treating two intentions as one.
This design does useful, bounded work. It can stop a repeated request from producing a second effect when both sides honor the same contract. It cannot fix a wrong instruction, complete missing steps in a larger workflow, or guarantee that another service implements the pattern. Late requests and reused identifiers also need rules.
Meanwhile, an AI agent adds another layer. The model may decide whether to retry, while the tool wrapper, API, and external service each hold different pieces of the evidence. Reliability depends on how those pieces fit together. Better reasoning inside the model cannot recover a receipt the surrounding system never records.
What to ask before an agent gets authority
A vendor demo usually shows the clean path: instruction, action, confirmation. Ask to see the timeout path.
Choose one action that would cost time, money, trust, or repair work if it happened twice. Find out whether the system pauses after an uncertain reply and checks the destination. Ask what identifier links the first attempt to the second. Then ask what happens when the check is stale, incomplete, or inconclusive.
A low-stakes action can wait and be checked again. A high-stakes action may need a person to decide. Sending a duplicate internal note is different from placing a second order or contacting a customer twice.
Look at one automated workflow you already use. After a timeout, can it prove what happened before it acts again? If nobody can show you that proof, the system may be treating uncertainty as permission for a second click.