title: Retry Budgets: Teaching Agents When to Give Up
date: 2026-08-14
slug: 2026-08-14-retry-budgets-teaching-agents-when-to-give-up
summary: Agents either quit on the first blip or hammer a failing call forever. The fix: classify errors, set retry counts upfront, and make exhaustion loud.
tags: guardrails, failure-modes, autonomy-design

# Retry Budgets: Teaching Agents When to Give Up

Humans have a natural feel for when to stop retrying something. You hit refresh twice, maybe three times, then you conclude the site is down and go do something else. Agents don't have that instinct. Give an agent a task and a failure, and it will do one of two bad things by default: give up on the first transient error, or hammer the same failing call forever like a woodpecker on a steel pole.

Both failure modes are expensive. The quitter turns a 30-second network blip into a failed nightly job and a red alert nobody needed. The woodpecker turns a rate-limit warning into an actual outage — I've watched an automation retry an API call in a tight loop until the vendor's edge started returning bans for the whole account. An agent without a retry policy isn't autonomous; it's a coin flip between fragile and dangerous.

The fix is boring and wonderful: give every automated task an explicit **retry budget** before it runs, not during the panic.

A retry budget has three parts.

**First: classify the error before deciding anything.** Not all failures deserve a retry. A timeout, a 503, a propagation delay — those are retryable; the world will probably be different in two minutes. A validation failure, a permission denial, a lint gate rejecting your output — those are *deterministic*. The world will not be different in two minutes; your input will still be wrong. Retrying a deterministic failure is the purest form of wasted compute, and worse, it delays the moment a human finds out. The single most valuable line in any of my task prompts is some variant of: "if the error is retryable, wait and retry up to N times; if it's a correctness failure, stop immediately and announce it."

**Second: fix the numbers in advance.** How many attempts, how long between them, and what the total wall-clock ceiling is. Two retries with a 120-second pause is a policy. "Keep trying until it works" is a prayer. The point of deciding upfront is that the decision gets made by a calm mind reading a spec, not by an agent mid-failure with a goal it really wants to achieve. Agents are persistent by nature — that's the feature — so the leash has to be attached before the chase starts.

**Third: make exhaustion loud.** When the budget runs out, the task doesn't just end — it *reports*. The worst outcome in agentic operations isn't a failed job; it's a failed job that looks like a quiet success because the agent shrugged and moved on. A run that exhausts its retries should end in a visible message: what failed, how many attempts, what the last error was. Silence is a privilege reserved for success.

There's a nice side effect to all this. Once retry budgets are explicit, your logs start telling you the truth about your infrastructure. A task that regularly needs its second retry is a signal — some dependency is slower or flakier than you assumed — and you can fix the cause instead of admiring the symptom.

Autonomy isn't an agent that never fails. It's an agent whose failures are bounded, classified, and loud. Persistence is cheap. Judgment about when to stop is the thing you actually have to design.