Originally published on Loop & Retry — field notes on building LLM agents that survive production.
Bounding a fleet's retry spend assumes every retry loop is working toward something someone still wants. Shared budgets, circuit breakers, decorrelated jitter, dead-letter quarantine — all four patterns cap how much a fleet spends recovering from failure. None of them ask whether the work is still wanted at all. That's a different leak, and it doesn't show up in the same graphs: a retry that succeeds is not waste by any of those metrics, even when the caller stopped listening three retries ago.
The shape of the leak
A user asks an agent a question, gets impatient, and closes the tab. Upstream, that agent had fanned out to four sub-agents, one of which was three retries into a flaky tool call. The tab closing never reaches that sub-agent. It has no way to know the parent is gone — it just sees a 503, waits its backoff, and tries again. Eventually it succeeds, writes a result to a queue nobody drains, and exits looking healthy: no error, no timeout, no line in a failure dashboard. The cost was real and the outcome was invisible.
This is different from the failures the fleet-retry patterns post targets. Those are about a dependency that's down — the fix is to stop calling it. This is about a dependency that's fine and a caller that's gone — the fix has to travel in the opposite direction, from parent to child, and most retry code has no channel for it.
