Retry and backoff
Retry with backoff is the client pattern of reattempting a failed API request after a delay that grows with each attempt — usually exponential backoff, doubling the wait each time, with random jitter added so many clients do not retry in synchronized waves. It applies to transient failures such as timeouts, HTTP 429, and 5xx responses, and defers to a Retry-After header when the server sends one.
Agents are automated retriers, which makes retry guidance safety-critical documentation. The docs need to state which status codes are transient and worth retrying, which are permanent and should stop the loop, whether a `Retry-After` header is sent, and what backoff schedule the provider expects. An agent given these facts implements a well-behaved client; an agent without them either gives up on recoverable failures or hammers a struggling endpoint.
Retry guidance is inseparable from idempotency. Retrying a GET is always safe; retrying a POST is only safe when the API documents an idempotency mechanism the client can use. Documentation that presents the two together — retry this class of errors, with this backoff, using this idempotency key — hands the agent a complete recovery recipe.
This is also where docs quality shows up as runtime cost: an agent that must discover retry semantics by trial burns tokens and requests learning what one documented paragraph would have stated.
Discry assesses error-recovery guidance as a comprehension check on the API's profile — whether the public docs describe failure modes and how to recover from them, including retry behavior. It is graded from the documentation surface as agents fetch it; Discry does not execute live calls to test the retry behavior itself.
What does an AI agent make of your API?
Find out in about a minute — no signup.
Discry your API — free