Your agent sends a request. The tool returns an error. The agent tries again.
That sounds like recovery. It can also repeat an action that already happened.
The retry decision should depend on evidence about the earlier attempt.
Three situations that should not share one retry rule
Here, dispatch means handing the request to the component that sends it. The receiver is the service on the other end.
| What you can establish | What it tells you | Next decision |
|---|---|---|
| The operation never reached dispatch, with reliable evidence covering the attempted path | No request was sent through that path | Recheck current authority, target and input before considering another attempt |
| The receiver recorded the body, then returned an error | The body arrived; the error does not erase that fact | Inspect what effect occurred; use an established reconciliation or idempotency mechanism |
| The response is missing and receiver evidence is incomplete | Whether an effect occurred remains unknown | Preserve that uncertainty; investigate before an automatic replay |
These are policy choices to evaluate, not a universal recipe. Receiving a body also does not prove that a business operation completed. A service may validate, enqueue or reject it later.
Likewise, “nothing was sent” does not make an expired approval valid again. Evidence about the earlier effect and authority for the next attempt answer different questions.
A deliberately constructed 404
In an ARC synthetic loopback experiment, a local receiver deliberately recorded a fixed 50-byte body and then returned HTTP 404.
The caller observed the error. A separate receiver observation showed that the body had arrived.
We included two controls: a normal 204 response with one recorded receipt, and a no-send case with no dispatch or receiver connection. Repeating the request after the first send was refused by a consumed grant inside the test host.
That refusal was limited to one running process. The receiver ran under the same OS account. This was a fault-injection lab, not a discovered production incident, independent attestation, or a demonstration of durable recovery or exactly-once delivery.
Stable Agent Role Contracts checks supplied declarations. It does not supply a general runtime enforcement layer or prove that a real service deduplicated an action. We have not established an advantage over an equally informed existing retry/readback control.
A useful review question
Look at one side-effecting tool in your own system: sending a message, creating a ticket, or submitting a job.
Find the branch that handles an error. Check whether it distinguishes a request that never left from one that may have completed. Also check whether a new attempt retains the logical operation identity your receiver actually recognizes.
For a broader worked example, this earlier article separates approval, unknown outcomes and settlement.
Which evidence does your retry rule actually check: the response code, an idempotency record, receiver-side readback, or something else?
Top comments (9)
A retry is not a cheap second call. Every attempt sends the whole conversation again, so a retry costs the first call again, history included. Retry only what can change on the next try, like a 429 or a timeout.
Thanks, Paul. That's an important cost consideration, especially when a retry resends a large context.
I'd separate two questions: is another attempt worth the cost, and is it safe to replay the operation?
For a side-effecting tool call, even a timeout can mean the receiver completed the action but the acknowledgment was lost. So I'd check the operation ID, idempotency record, or receiver-side evidence before replaying it, while also respecting the retry budget and current authorization.
How are you approaching that distinction in practice?
The 404 case is a good reminder that a status code describes the response, not what happened to the request. MDN's page for 404 only says the server "cannot find the requested resource", and it can't tell you whether anything ran before that.
One small addition to the "retry only what can change" point: 429 and 503 are the two where MDN's pages both mention a Retry-After header, so an agent can wait the stated time instead of using a fixed backoff. 400 and 403 are documented as "repeating the request without modification will fail with the same error", so those are safe to treat as never-retry without changes.
Thanks for the thoughtful addition. I agree, especially with your point that a 404 response doesn't necessarily prove that no side effects occurred.
I think this suggests two separate questions an agent should answer before retrying:
Retry-Afterfor 429/503 when available, and avoid repeating unchanged requests after 400/403.That second distinction becomes particularly important for autonomous agents executing real workflows, where a duplicate action may have consequences beyond another failed HTTP request.
I'll incorporate this distinction into the article. Thanks for making the retry decision model more precise.
For side-effecting calls the idempotency record is the only reliable evidence. A 500 or a timeout can't tell you whether the receiver committed, but a key it already stored can.
Good point, Junfeng. A 500 or timeout tells us very little about whether the receiver committed the operation.
One nuance I'd add: the presence of an idempotency key alone doesn't necessarily prove completion. The record needs to be durably linked to the actual effect and its outcome.
A key marked as "processing" or "unknown" still leaves us with a reconciliation problem.
That's why I'd distinguish the logical operation from individual retry attempts, and verify the receiver-side outcome before replaying a side-effecting call.
How would you handle a case where the key exists, but the final effect is still uncertain?
This highlights why fault handling needs to be part of an AI agent's architecture from the beginning. In multi-step workflows, one incorrectly repeated action can affect everything that follows. At IT Path Solutions, we see execution tracking, idempotency, and outcome verification as essential building blocks when developing reliable agentic AI systems that interact with external APIs and business applications.
@suirindo My rule: a replay is only safe when the receiver can recognise an operation it already did. Without an operation ID or a check on its side, a timeout can't tell 'never ran' from 'ran, reply lost'.
Reliable AI automation depends on handling failure scenarios just as carefully as successful executions. A retry mechanism that ignores whether the previous action actually took effect can create duplicate records, messages, or transactions. At IT Path Solutions, we consider execution verification, idempotency, and controlled retries important design principles when building agentic AI workflows for real-world applications.