In this article
A connection can fail after a system creates an order or sends a notification but before the assistant receives confirmation. Repeating the action from scratch may then create two effects instead of one. A missing response is not proof that execution failed; the outcome is uncertain.
Give the business operation a stable identity
Separate the operation’s identity from the network attempt. One customer request should retain its operation identifier across retries. Generating a new identifier for every attempt makes it harder for the executing service to recognise repeated work.
Stripe’s idempotent-request documentation provides a concrete example of keys used to retry requests while avoiding duplicate operations. It describes one provider’s mechanism. Do not assume another service provides the same protection or retention rules.
Represent uncertain outcomes explicitly
Useful states include not sent, in progress, succeeded, confirmed failed and outcome unknown. After a connection failure, look up the operation by its identifier or inspect the service’s execution record before creating it again.
Consider a hypothetical assistant reserving stock for order A104. The inventory system receives the request, but the network drops before confirmation returns. A second attempt with a different operation identifier may reserve the quantity twice. Keep the business identifier stable and use duplicate prevention in the executing service wherever it is supported.
Enforce the rule outside the prompt
Telling an assistant “do not repeat the action” can clarify intent, but it cannot replace a system constraint. Put checks in the tool-execution layer and record the identifier, intended action and observed result. Reject changed inputs presented under the same operation identity, because a retry and a new instruction are different events.
Check provider support, retention periods and concurrent-request behaviour. When the external service lacks duplicate prevention, a local execution ledger can help, but it does not by itself guarantee safety if a failure occurs between the external action and recording its result.
Test the difficult failure window
In a test environment, repeat an identical request, issue concurrent attempts and simulate a connection loss after execution but before acknowledgement. Count the actual business effects, not just success messages. An order that appears twice remains a failure even if the logs show only one clean response.
Route unresolved outcomes to a review queue instead of retrying indefinitely. Assign ownership and record how the result was established. Retry limits and reconciliation should be part of the operating process before the assistant receives permission to create customer-facing commitments.
The practical question is simple: if the response disappears, how will the team establish whether the action already happened? Answering it makes retries useful without silently multiplying their consequences.
Contact on WhatsApp
