Exponential backoff

A retry policy that increases delay geometrically after failures, usually with jitter and a maximum delay or attempt budget.

The multiplier need not be exactly two. Jitter reduces synchronized retries, while caps and deadlines prevent unbounded waiting. A server's Retry-After guidance can take precedence. Backoff is appropriate only for transient failures and operations whose retries are safe or made safe through idempotency.

Builder example

When you tell an agent to keep working through a flaky connection, naive retries make the problem worse: a service that is briefly overloaded gets pounded by instant retries from every agent at once, which keeps it down longer. If your agent sends fifty messages and the provider stutters, fixed one-second retries can pile on and stall the whole run. Ask your agent to retry with exponential backoff and jitter, and to give up after a set number of attempts so a permanent outage does not loop forever.

Common confusion: Retrying and exponential backoff are different retry methods. A plain retry tries again right away and can flood a struggling service; exponential backoff stretches the gap between attempts and adds randomness so the load eases and recovery has room.