AI workflow retries: prevent duplicate actions with idempotency

Distinguish a failed request from a failed action

A network timeout tells the caller that it did not receive a usable response. It does not prove that the remote service rejected the operation. Retrying blindly can create two tasks or apply the same update twice.

Separate the model's proposal from the application command. Validate a structured proposal, confirm permission and any required approval, then execute a deterministic command with a durable identity. A new model response should not silently become a new identity for the same intended action.

A worked CRM task failure

Illustrative design: a reviewed support summary should create one follow-up task. The service records an operation key derived from the account, ticket, action type, and approved revision. It passes that key to the task service if the service supports idempotent requests.

1. Persist the approved payload and operation identity.
2. Send the create request with the same identity on each permitted attempt.
3. If the request times out, mark the outcome unknown.
4. Look up the remote result by its idempotency key or a durable external reference.
5. Record the remote task identifier when the outcome is known.

If the provider cannot enforce duplicate protection or support reliable reconciliation, do not claim exactly-once behavior. Pause ambiguous cases for review, or accept and document the specific duplicate risk.

Use retries only where they are safe

Retry transient failures with a bounded attempt count, increasing delays, and jitter. Respect provider rate limits. A validation error or revoked permission needs a correction, not repeated traffic. Keep the approved payload stable while the operation is being retried.

A database outbox can help when an application must commit a local change and notify another service. AWS describes the transactional outbox pattern as a way to address inconsistent dual writes, while calling out duplicate delivery and idempotent consumers. An outbox does not automatically make every downstream action execute once.

Make recovery inspectable

Use explicit states such as proposed, approved, in-progress, unknown, succeeded, and failed. Record the operation key, payload version, attempt history, and remote identifier. Restrict log access and avoid storing secrets or unnecessary customer text.

Test the ambiguous boundary: let the remote service accept the request, then interrupt the response. Confirm that the next attempt either returns the original result or enters reconciliation without creating an extra task. Also test concurrent workers claiming the same operation and an approval being withdrawn before execution.

These are design checks, not measured Arrow customer results. The right policy depends on the provider and the cost of duplication. Read the architecture guide for execution boundaries and the evaluation guide for testing the proposal before it becomes an action.

Sources and editorial scope

Engineering guidance by Arrow AI, published and reviewed October 15, 2026. Worked examples are illustrative designs; they are not customer deployments or measured results.

• AWS: transactional outbox pattern