MyDot Consultancy

Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.

Imagine a test agent submitting a purchase request. The remote application accepts it, but the response is lost before the agent receives confirmation. The agent sees a timeout and tries again. Without a deliberate recovery design, one authorized request can become two records.

This is a distributed-systems problem that becomes especially important when an agent decides what to do after an error. “Try again” is not a universally safe policy. The application must distinguish operations that can be repeated harmlessly from operations whose outcome must first be established.

A timeout means uncertainty, not necessarily failure

A connection can fail before a request reaches the server, while the server is processing it or after the action commits. The client may see a similar error in all three cases. Treating every timeout as proof that nothing happened creates a duplication risk.

The Amazon Builders’ Library article on idempotent APIs explains why retries can create unwanted side effects and how explicit request identity can help. Its examples concern service APIs, but the principle applies to an agent calling those services through tools.

For the hypothetical purchase workflow, the correct next step may be to check the operation’s status or locate the request by its unique reference. If the integration cannot determine the result, the agent should report uncertain completion and route the issue for review rather than silently creating another request.

Give the intended action an identity

Create an operation identifier for the specific business action before executing it. Preserve that identifier across retries and resumed sessions. Do not generate a fresh identity merely because the first attempt timed out, or the destination may interpret the retry as a new action.

The identifier should represent the intent, not just the current network attempt. A user intentionally submitting a second distinct purchase request needs a different operation identity. A retry of the first request should retain its original identity. Confusing those cases can either duplicate work or suppress legitimate work.

Keep sensitive information out of identifiers when a random reference will do. Link the reference to business details in an appropriately controlled record. This supports diagnosis without embedding customer names or email addresses in every log line.

Use the destination’s actual idempotency contract

Some APIs support an idempotency key or a comparable request token. Others do not, or support it only for particular operations. Read the endpoint’s current documentation and test the behavior. An application-generated key has no protective effect if the destination ignores it.

Stripe’s idempotent-request documentation provides a concrete example of a provider-supported mechanism for retrying create or update operations. It also documents version-specific behavior. That is an illustration of the pattern, not a claim that every payment or business API behaves the same way.

Understand the contract’s scope, retention and handling of changed parameters. A retry outside the supported window may be treated differently. Reusing a key for a materially different action may be rejected or have unintended results. Keep these rules in the integration rather than expecting the model to remember them from prose.

Put retry policy in application code

The model can interpret a business failure and explain next steps, but low-level retry behavior should be bounded and explicit. Classify transient service errors, rate limits, invalid inputs, permission denials and uncertain writes separately. Each category needs a suitable response.

A permission denial should not lead to repeated attempts with alternate identities. An invalid identifier should trigger correction or clarification. A transient read failure may support a limited retry. An uncertain consequential write requires reconciliation or the destination’s documented idempotency mechanism.

The OpenAI Agents SDK tools guide documents function-tool error handling. Use such mechanisms to return a meaningful status to the agent, while keeping the safe execution and retry policy in the application layer.

Watch for retries at several layers

An SDK, connector, job queue and agent can all retry the same operation. If each layer acts independently, the total number of attempts may be surprising. Map where retries occur and decide which layer owns the policy for each operation.

Preserve the operation identity through those layers. A queue redelivery should not create a new business intent. A resumed agent should inspect the existing action record before issuing another write. Monitoring should show all attempts associated with the same intended outcome.

Do not claim exactly-once business execution merely because one component has deduplication. End-to-end behavior depends on the full path, including external systems and delayed callbacks. Describe the guarantees you can actually test and the remaining uncertainty.

Test the uncomfortable timing windows

• Failure before the destination receives the request.
• Failure after the destination commits but before confirmation reaches the caller.
• Two concurrent attempts using the same operation identity.
• A resumed task retrying after a process restart.
• A changed request accidentally reusing an old identity.
• A late response arriving after the user cancels the task.

Use a sandbox with synthetic records and inspect the destination after each test. Verify that the agent’s final message matches the observed state. The key result is not merely that the application avoids an exception; it is that the intended action occurs no more often than authorized and uncertainty is not hidden.

Give operators a reconciliation path

When the system cannot establish an outcome automatically, show the operation reference, attempted action, last known state and relevant destination. An operator should be able to investigate without repeating the entire request. Preserve a clear distinction between pending, confirmed and unknown.

Reliable agents need safe recovery as much as successful execution. Design retries around business intent, destination guarantees and observable state. That lets the system be persistent without turning persistence into duplicate messages, duplicate records or duplicate commitments.

Sources and further reading

Amazon Builders’ Library: Making retries safe with idempotent APIs. Primary distributed-systems explanation of retry side effects and request identity; checked October 2026.

Stripe: Idempotent requests. Concrete provider-specific idempotency behavior; checked October 2026, not generalized to other APIs.

OpenAI Agents SDK: Tools. Function-tool error handling mechanisms; checked October 2026.