Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsTo stop an AI agent from repeating a side effect after a timeout, give the intended action a stable idempotency key, enforce deduplication where the action executes, and check what happened before retrying. A timeout means the caller did not receive a timely response; it does not prove whether the payment, message, or other operation occurred.
Why an agent can repeat an action after a timeout
A tool call crosses a boundary between the agent or workflow and another system. The external system may complete the action even if its response is delayed or lost. The agent then sees an error or timeout while the payment, message, file change, or other side effect may already exist.
As an Amazon Associate I earn from qualifying purchases.
This is an ambiguous outcome, not evidence of success or failure. If the workflow blindly sends the call again, it can create a duplicate. Idempotency addresses this by making repeated requests for the same logical action return or preserve the same effect, provided the layer receiving the request actually implements that contract.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Instructions to a model such as “never call this twice” can help shape behavior, but they are not an execution guarantee. The deduplication check belongs in the application, tool, or orchestration path that controls the side effect. AWS summarizes the risk in its Agentic AI Lens: “Retry is the most common recovery mechanism, and without idempotency it can produce duplicate side effects.”
Give each logical action a stable identity
An idempotency key identifies an intended operation, not one network attempt. Create and persist it before dispatch, then reuse it for retries of that same operation. Use a new key for a distinct intended action—even when its inputs or message text are identical. OpenAI’s session guidance makes this distinction for message submissions: reuse the same key, session ID, and message after a timeout or lost response; use a different key for a distinct submission.
Choose the operation boundary
Define what counts as one action in the business workflow: one payment instruction, one outbound message, or one durable task occurrence are possible boundaries. A retry is another attempt to carry out that action. If an agent replans and intentionally requests a new action, represent that intent as a distinct operation rather than deriving identity from payload alone.
Create the key before sending
Use an application-controlled identifier or a deterministic derivation from stable workflow inputs, such as the workflow ID, task type, and request body. Persist the key with the operation before dispatch. Do not create a fresh UUID or timestamp when retrying: a new value makes a duplicate look like a new request. AWS describes deterministic key derivation and warns against generating a new key at retry time in its idempotent task execution guidance.
Enforce deduplication at the execution boundary
Before performing a side effect, the tool or orchestration layer should look up the operation identity. If a successful result is already recorded, return that result rather than executing the action again. For a new operation, record its identity and execution state using a uniqueness constraint or conditional write where possible, then perform the work and persist its outcome.
That sequence has an important engineering limit: recording a result and changing an external system are often not one atomic transaction. A process can fail after the external effect but before saving the result. A later retry must therefore verify external state or use an idempotency contract offered by that external service; a local record alone cannot resolve every failure window.
Carry the key through every step
Pass the original key, or a deterministic derivative scoped to a child operation, through delegated tasks and downstream APIs. A workflow can otherwise deduplicate its first tool call but duplicate a later side effect. For services that accept their own idempotency keys, forward a stable key rather than relying on the agent runtime’s retry behavior.
AWS recommends conditional writes for idempotency records and discusses TTL expiration to bound record growth while retaining protection during the expected retry and recovery window. Set retention to cover the longest delay in which a retry or operational recovery may occur. Expiring the record sooner can allow a late retry to execute again.
Recover safely when a tool call times out
- Check the operation record. Look up the stable key and inspect whether the action is recorded as complete, still running, or unresolved.
- Verify external state. When the record is inconclusive, query the provider or target system for evidence of the effect. OpenAI’s Agents API recovery guidance warns that a failed turn may already have changed files or called external tools, and recommends inspecting completed actions before asking the agent to repeat work.
- Return or reconstruct a completed result. If the effect occurred, return its recorded response or reconstruct the result from authoritative state rather than resubmitting the side effect.
- Retry only when the outcome supports it. If the effect did not occur, retry with the same key when the receiving API supports idempotency. Follow that API’s retry guidance, including any
Retry-Afterresponse, limiting attempts, and stopping automatic retries if the error changes or the retry limit is reached. - Escalate an unresolved irreversible action. If state cannot be checked and the external API offers no deduplication contract, surface an uncertain outcome for reconciliation instead of blindly replaying it.
These checks are especially important when a workflow resumes after interruption: replay may revisit a step whose external effect completed before the interruption was recorded.
Choose retry semantics according to the side effect
Workflow runtimes may expose at-least-once and at-most-once behavior. AWS’s durable execution documentation describes these as SDK semantics, not universal behavior across all workflow systems. Neither setting alone provides exactly-once execution across an entire workflow.
| Decision point | At-least-once | At-most-once per retry |
|---|---|---|
| After an interrupted attempt | The runtime may rerun the step on replay. | The runtime can mark the attempt interrupted rather than rerunning it. |
| Suitable cases | Idempotent reads, upserts, or operations whose endpoint deduplicates requests with a stable key. | Side effects for which an automatic second attempt is unsafe, such as an unkeyed payment call or one-shot message. |
| Main trade-off | The operation must be safe to repeat. | An action may remain uncertain or incomplete and need recovery. |
| Workflow-wide result | Does not by itself ensure one execution across the workflow. | Also does not ensure one execution across the workflow; a higher-level retry can start another attempt. |
AWS recommends matching semantics to the side effect and says at-least-once is safe only for idempotent operations. Its example pairs at-most-once behavior with retries disabled for a side-effecting payment call. For an external API that accepts idempotency keys, AWS advises generating the key inside the step so it remains stable during replay. See AWS’s durable execution guidance.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Understand what a provider’s key contract actually guarantees
An idempotency key is only as protective as the receiving service’s documented behavior, including its retention period, parameter checks, and treatment of errors. Do not assume one provider’s rules apply to another.
OpenAI Agents API sessions
For the documented Agents API session flow, OpenAI says to create a key for each logical message submission, save it before sending, and reuse it when retrying that submission. The Python SDK sends the key in the Idempotency-Key header and reuses it for automatic retries. A new, intentional submission gets a different key even if its text matches the earlier message. The session and recovery details are documented in OpenAI’s session guide and errors and recovery guide; because the guidance describes the API, revisit it as the beta evolves.
AWS agent and durable execution patterns
AWS’s Agentic AI Lens covers deterministic keys, checking for prior results, propagating identity through multistep work, conditional writes, and TTL expiration. Its durable execution guidance explains replay behavior and the limits of retry modes. These are AWS patterns and SDK semantics; other runtimes may define different controls.
Stripe API behavior
Stripe’s idempotent request contract illustrates provider-specific details. Stripe says it saves the first request’s resulting status and body and returns that result for subsequent requests using the same key, including when the saved result is a 500 response. It compares later parameters with the original request and returns an error if they differ.
Stripe says keys may be removed after they are at least 24 hours old; after removal, reuse may result in a new request. It also says it does not save a result when validation fails before endpoint execution begins or when a concurrent request conflicts before execution. These retention and response rules apply to Stripe’s documented contract, not to idempotency keys generally.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Test the failure windows, not just the happy path
A test that merely sends the same request twice will miss the difficult cases. Exercise failures around dispatch, execution, and result recording, including:
- A timeout or lost response after dispatch, when the external action may already have completed.
- Delayed visibility of the effect when checking external state immediately after a timeout.
- Two concurrent retries using the same key.
- An interruption after the side effect but before the workflow records the result.
- A retry after the idempotency record has expired or after the external provider’s retention window has passed.
- A repeated key paired with changed parameters, where the receiving service may reject the mismatch.
A 2026 paper by Isham Kalappurackal Mansoor, Abhishek Phadke, and Pratip Rana, Verified Tool Calls Improve LLM Agent Reliability Under Non-Atomic Failures, reports results from a controlled simulated environment with injected non-atomic failures. Its baseline reported about 58% task success and about 42% duplicate actions; its verify-only condition reported about 80% success and about 20% duplicates; its full method reported about 72% success and about 28% duplicates. The paper describes a verification-aware wrapper involving postcondition checks, verify-before-retry logic, and idempotency keys. These figures characterize that simulation, not production rates or a guarantee for a particular implementation.
Review the whole idempotency contract
When implementing or evaluating a tool integration, make the contract explicit for the parts that determine whether retries remain safe:
Quick Recap
- What constitutes one logical operation, and how is its key scoped and derived?
- How long are records retained relative to retry, replay, and human recovery windows?
- What happens when concurrent requests use the same key?
- Does the service reject a reused key with different parameters?
- Which downstream services accept and enforce keys, and where does propagation stop?
- How can operators see completed effects and reconcile unknown outcomes?
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
