The Model Retries Because It Cannot See the Result

The founding result of this domain is that a timeout tells you nothing about whether the work happened. [[timeout-ambiguity]] enumerates the five realities behind one observation, and three of them involve the work having completed. Nothing about that changes when the caller is an agent. The tool may have run.

What changes is *who decides to retry*, and how. In an ordinary service, retry is a policy: a library, a config value, a number of attempts, a backoff. It is deterministic, auditable and bounded. In an agent, retry is an *inference* — the model looks at a context in which a tool call has no result, concludes that it should try again, and emits a new call. Nobody configured this. It is not in the retry policy. It happens in the model’s output, which is one layer above every mechanism you built to control retries.

And the retry may not be identical. A retry library re-sends the same bytes. A model regenerates the call, and may phrase the arguments differently: "Subject: Order confirmed" becomes "Subject: Your order is confirmed". This single fact kills the most tempting deduplication scheme, and it is the reason this lesson exists as its own topic rather than as a paragraph in the idempotency module.

The first instinct is to deduplicate on the arguments: hash the tool name plus the payload and reject a repeat. It is cheap, it needs no changes to the model, and it is wrong in both directions.

False negatives. The model rephrases on the retry, the hash differs, and the duplicate sails through. Because rephrasing is the *normal* behaviour of a regenerated call, this failure is not an edge case — it is the common case for anything containing free text.

False positives. Two legitimately distinct calls have identical arguments. An agent processing a batch creates two tickets with the same title, sends the same reminder to the same person on two different days, or appends the same line twice on purpose. Argument hashing refuses the second, and the failure looks like a tool that "sometimes does not work".

The fix is to take identity from where the call *came from* rather than what it says. A key of (workflow_id, step_index, tool_name) survives rephrasing — the retry is the same step — and distinguishes legitimate repeats, which are different steps. Add a monotonic attempt discriminator only where a genuine re-execution is intended, and make that explicit rather than accidental.

The mechanism has one non-obvious ordering requirement, and it is the entire difference between a system that can recover and one that cannot.

Persist the intent to call before making the call. Write {key, tool, arguments, status: "intended"} to durable storage, *then* invoke, *then* write the outcome. A crash between the first write and the second leaves a record that says "this may have executed and I do not know" — which is precisely the state of the world, faithfully recorded. A crash with no such record leaves you unable to distinguish "never called" from "called and lost", and no amount of later cleverness recovers the difference.

This is the same discipline as write-ahead logging, and [[checkpoint-and-log]] is the general form. The cost is one durable write per effectful step, which for a workflow measured in seconds of model latency is negligible — and it is only needed for *effectful* tools, not for reads.

On the tool side, the handler stores the key with the result, in the same transaction as the effect where the effect is a database write. A repeat with a known key returns the stored result without re-executing. [[deduplication]] and [[idempotency-scope]] cover the mechanics and, importantly, the retention question — a key store that forgets after an hour provides no protection against a workflow resumed the next morning.

Applying keys and step logs to every tool is expensive and unnecessary. Four categories, and only one of them is genuinely hard.

Read-only — search, get_customer, list_files. Retry freely; a duplicate costs a little load. The overwhelming majority of tool calls are these, and they should stay cheap.

Naturally idempotent writes — set_status(id, "closed"), PUT of a whole document, add_tag. Retry freely; repeating produces the same state. Designing tools into this shape is the cheapest possible fix and is under-used: set_status is safe where advance_status is not.

Effectful and keyable — charge_card, create_ticket, send_email where the provider supports an idempotency key or a client-supplied message id. Use the key. This is the idempotency-key mechanism from API Design, and it is a solved problem at that level.

Effectful and not keyable — a third-party endpoint with no key support and no way to query what it did. There is no way to make this safe from the outside, so the choices are: wrap it in your own ledger and accept a small unavoidable window, require human approval so the duplicate is caught by a person, or design the workflow so this call is the last step and a failure means the workflow simply stops. Naming this category honestly at design time is worth more than any mitigation, because it is the one that produces the incident.

This is the detail most often got wrong, and it converts a working deduplication scheme into a runaway loop.

When a repeat arrives with a known key, the natural implementation returns 409 Conflict: duplicate request. For an ordinary client, correct. For an agent, this is fed back into the context as a tool result, and the model reads an error. Its trained response to an error is to fix and retry — perhaps rephrasing the arguments, which produces a new key if your keying is weak, or reporting to the user that the operation failed when it in fact succeeded.

So: a repeat must return the original success, indistinguishably. Same shape, same fields, same status. Add a deduplicated: true field for your own telemetry if you like, but the model’s view should be that the call succeeded and here is the result — because that is true. The email was sent.

The same principle governs errors generally: what you hand back to the model is not a log line, it is an instruction it will act on. tool-errors-retries-timeouts in Agentic Engineering is the treatment; the distributed-systems reason is that in this architecture the error channel and the control channel are the same channel, so an error message is effectively a command.