Is it safe to retry an AI agent action after a timeout?

Only if the operation is idempotent or you can prove the request never reached the server. Otherwise the action may already have happened, so check the real state first instead of retrying.

What is an idempotency key?

A unique value sent with a request so the server can recognise repeats. If the same key arrives again with the same payload, the server returns the original result instead of performing the action twice.

What should an agent do when the outcome of an action is unknown?

Stop, verify the target system’s actual state with independent reads, and escalate to a human if verification is inconclusive. Never assume success or retry a non-idempotent action blindly.

Safe retries and idempotency for AI agent actions

Why naive retries duplicate payments and records in agent systems, and how to retry safely with idempotency keys and verification of unknown outcomes.

By the Voidex team · Updated 13 October 2026 · 7 min read

The duplicate-action problem

Agents and job queues love retries. But if an invoice was posted and only the response was lost, a retry posts it twice. Agents make this worse: they may retry on their own after a vague error, or re-plan the same step.

Idempotent operation — An operation that has the same effect whether it is performed once or several times with the same input — for example “set stage to won”, or “create invoice with idempotency key X”.

Classify every failure

Pre-send failure (DNS error, connection refused, blocked egress): the request never left — safe to retry.
Rejected (4xx validation, 429 rate limit): the server refused — fix or back off; nothing was applied.
Unknown (timeout after sending, 5xx, connection reset mid-response): the change may or may not have happened.

A safe retry protocol

Give every action an idempotency key (client-provided or the action id) and forward it to APIs that support it.
Before calling out, persist an “execution started” marker in the same store as the job.
On pre-send failures, retry with backoff.
On unknown outcomes, retry only if the tool is declared idempotent.
Otherwise, do not retry: run the postcondition checks to learn the real state and send it to human review.
If a worker crashes mid-call, treat the restart as an unknown outcome using the marker.

POST /api/v1/runs
Idempotency-Key: order-8812
…
# Same key + same payload → returns the original run (no duplicate)
# Same key + different payload → 409 idempotency_conflict

How Voidex does it

Voidex stores idempotency keys per workspace, forwards them to tools that support them, writes an execution-started marker before every external call, and classifies outcomes as succeeded, failed or unknown. Non-idempotent actions with an unknown outcome are never re-sent: Voidex verifies the real state and marks the run needs_review. This behaviour is covered by integration tests and the sample benchmark suite.

Try it in the sandbox Read the API docs

Frequently asked questions

Is it safe to retry an AI agent action after a timeout?: Only if the operation is idempotent or you can prove the request never reached the server. Otherwise the action may already have happened, so check the real state first instead of retrying.
What is an idempotency key?: A unique value sent with a request so the server can recognise repeats. If the same key arrives again with the same payload, the server returns the original result instead of performing the action twice.
What should an agent do when the outcome of an action is unknown?: Stop, verify the target system’s actual state with independent reads, and escalate to a human if verification is inconclusive. Never assume success or retry a non-idempotent action blindly.