A retry budget is a language-agnostic idea, but the place you enforce it is not. Python’s tenacity decorators, Go’s context-plus-backoff, and JavaScript’s promise chains each make a different mistake easy and a different guarantee hard. Where the shared budget lives, and the per-language trap that leaks it.
A per-step retry cap bounds a step. It never bounds a run, and it never bounds a fleet — twelve workers each retrying ‘reasonably’ is how you turn one bad deploy into a bill. The four patterns that actually put a ceiling on what a fleet of agents can spend recovering from a failure: shared retry budgets, circuit breakers, decorrelated backoff, and poison quarantine.
Retrying a read is free. Retrying a write can charge a card twice, send two emails, or book two rooms — and the model has no idea it happened. Retry safety is a property you build into the tool, not a flag you set on the loop. Here’s why at-least-once delivery is the default you’re actually running, how to derive a stable idempotency key from an agent’s intent, and a dedup wrapper that makes any write safe to retry.
An agent burned ~$200 overnight retrying an HTTP 400 — a request that was defined to fail. No component was buggy; each layer retried “reasonably.” The teardown: why retryability is a property of the error and not a default, how three nested retry caps multiply into 75 doomed attempts per item, and why per-step caps never bound a bill. With the two-line fix and a circuit breaker.
Retries feel cheap and local. In a multi-step agent they’re neither. A small cost model shows why 20% per-step failure can more than double your bill — and how your recovery architecture, not your failure rate, decides the multiplier.