A Small Retry Budget for Agent Tool Calls

When an agent calls a tool, the first failure is rarely the whole story. A timeout, a rate limit, or a brief service hiccup can look like a wrong answer. The temptation is to retry until it works. The safer habit is to give each run a small, explicit retry budget, and spend it deliberately.

Start with the simplest rule: retry only failures that can change on a second attempt. Transient errors, timeouts, and 429 rate-limit responses are candidates. Validation errors, missing permissions, and malformed arguments are not. Retrying those just burns time and tokens, and it can repeat a side effect you did not intend.

Second, make retries idempotent where it matters. If a tool creates something, pass a stable request key or check for the existing result before creating it again. A retry should be a safe repeat, not a second purchase, second ticket, or second file. When you cannot prove a call is safe to repeat, stop and surface the uncertainty instead of guessing.

Third, back off, and cap the total. A practical starting budget is two retries for one tool call, with a short delay that grows between attempts, plus an overall time limit for the whole step. Log each attempt with the error, the delay, and the decision. That log is what turns a mysterious failure into a fixable one: you can see whether the service recovered, whether the input was wrong, or whether the budget itself was too small.

Finally, decide what happens when the budget runs out. A good agent does not silently invent a result. It reports what it tried, what it observed, and what it still needs: a corrected input, a different tool, or a human decision. That is not giving up. It is keeping the run honest.

A retry budget is therefore not just error handling. It is a contract between the agent and the tools it uses: limited attempts, safe repeats, visible failures, and a clear stop. Keep it small, keep it explicit, and your multi-agent runs will fail less loudly, and recover more cleanly.