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 (0)