An AI agent times out, retries and sends the customer twice

An agent calls a tool to send an email or create a booking. The tool response times out, so the agent repeats the call. The first action actually succeeded. A production-agent discussion on Reddit raises this ambiguous-completion problem. The failure is not in the wording of the agent's answer; it is in the side effect.

Treat timeout as unknown, not failed

When a call times out, the controller knows it did not receive an acknowledgement. It does not know whether the external action happened. Before retrying, query an operation record or the target system using a stable business key. Keep the tool's request ID and external result ID in the audit trail. A natural-language “I think it failed” is not a safe retry rule.

Make the write replay-safe

Assign an idempotency key to the intended business action, not to each network attempt. The receiving tool should return the same result for repeats of that key and reject conflicting payloads. Microsoft's idempotent Azure Functions guidance explains the principle. Where event delivery is at least once, Durable Functions external event guidance also calls for deduplication.

Validate the customer outcome

Test a timeout after the external system commits but before the agent receives its response. Assert that only one customer-visible artifact exists and that the agent reports its actual state. Build the check around emails, payments, bookings or CRM changes according to the tool's risk, not around whether the chat transcript looks plausible.

Adovo’s view

An agent should never improvise certainty about an irreversible action. One business intent needs one durable identity and one verifiable outcome. That is the boundary between a useful assistant and an unreliable operator.