AI agent runtimes risk repeating payments, messages and other real-world actions when they automatically retry tool calls after network failures.
A timeout does not necessarily mean an external action failed. For example, a payment provider may complete a refund even if its response never reaches the agent. If the runtime retries blindly, the second call can create another refund.
The tool contracts should describe side effects, not just input and output formats. It separates tools into read-only, idempotent writes, deduplicated writes and non-repeatable writes.
For deduplicated operations, the runtime should create a stable operation ID before the first external call. Every retry must reuse that same identity.
Read: OpenAI Releases ChatGPT 5.5 With Stronger Agentic AI Capabilities
If a timeout leaves the result uncertain, the operation should move to an outcome_unknown state. The runtime should then reconcile the external state before attempting another write.
Only a definitive not_found result should authorise another attempt for a non-repeatable action. Human approval should also attach to the business operation rather than an individual attempt.
Changing the amount, recipient, destination or operation identity should require fresh approval. For workflows that combine database changes with message queues, the material recommends a transactional outbox.
Consumers should still deduplicate messages because delivery may occur more than once. The underlying principle is simple: an agent may propose an action, but the runtime must control and verify its real-world effect.
AI agent runtimes can duplicate real-world actions after timeouts unless tool contracts distinguish failed responses from unknown business outcomes.
