Retries are useful when an agent hits a temporary network error, a flaky test, or a slow deployment edge. They are dangerous when they become a way to keep doing the same thing after the evidence says the plan is wrong.

A retry budget is a small rule that says how many times an agent may repeat an action, what must change between attempts, and when the run must stop. It turns "try again" from an open-ended habit into an explicit operating boundary.

Budget the retry before the failure

The safest time to define retries is before the agent starts. A runbook can keep the rule short:

Retry transient operations at most two times. Before each retry, record what changed: backoff elapsed, dependency became ready, cache was regenerated, or command arguments were corrected. If the same failure repeats with no new evidence, stop and report a blocker.

That rule gives the agent enough room to handle normal friction without rewarding blind repetition. It also creates a useful receipt for the next operator: the failure was not ignored, and the loop ended for a named reason.

Separate transient failures from assumption failures

Not every failure deserves a retry. A timeout, rate limit, unavailable preview, or dependency still starting up may be transient. A missing source file, invalid configuration, failed privacy check, or mismatch between the requested scope and the repository convention is usually an assumption failure.

Assumption failures need investigation, not repetition. The agent should switch to read-only diagnostics, compare the result against the source of truth, and either make a bounded correction or stop with a blocker. Re-running the same destructive or publishing action is rarely the right next step.

Make each retry earn its place

A retry is easier to trust when it has a reason attached:

  • Backoff retry: wait for a dependency that was still initializing.
  • Regeneration retry: rebuild a derived artifact from source instead of editing output by hand.
  • Input correction retry: fix a validated typo, missing flag, or stale local assumption.
  • Verification retry: recheck a public route after deployment propagation, while keeping the original check result in the receipt.

If the agent cannot name which category applies, it should not spend the budget. "Maybe it will work this time" is not evidence.

Pair budgets with stop conditions

Retry budgets work best with a hard stop condition: once the budget is exhausted, the agent must stop changing state and report the safest concise evidence. The report should include the operation attempted, the number of attempts, the invariant that did not change, and the smallest safe next step.

This keeps unattended automation from becoming noisy or risky. The agent can recover from ordinary transient failures, but repeated failures become visible blockers instead of hidden loops.