How to stop an AI agent retrying a failing tool forever

When a tool fails, a model’s instinct is to adjust the arguments and try again. That is often right once. It is rarely right five times, and left alone it does not stop. One production agent logged a single turn that called the same tool 23 times.

Every one of those calls cost money, and the user spent the whole time looking at a spinner. The fix sounds obvious, a retry cap, and the obvious version does not work.

Start with a failure budget per turn

Give each turn a small number of tool failures it may spend, and three is enough. Past that the model is no longer converging on the right call, it is sampling guesses. When the budget runs out, stop calling tools and tell the user what failed, in words they can act on.

One rule underneath it: a failure is a result, not an exception. A tool that throws should become an error the model reads and routes around, never something that ends the turn. The user asked for something, and one broken tool should not throw away the rest of the answer.

Why a cap per tool name is not enough

The natural implementation counts failures per tool. The model walks straight around it, because when something underneath is broken, several tools fail for the same reason. Three real cases:

• Interchangeable tools. Four tools that all drew on the same canvas. When drawing was broken they all failed, and three attempts each meant twelve failures before any guard tripped. They now share one budget.
• A dead dependency. When the thing every client tool talked to was unreachable, the model tried four different tools in a row, which was one problem retried four times. All tools behind that dependency now share a single budget, so the first failure stops the whole class.
• A precondition, not a failure. A compute tool that needs data loaded is not broken, it is waiting. The model kept retrying it, sometimes right after an action that invalidated the data again. One 311 second turn contained seven attempts to change a setting and six compute failures.

The rule that follows: budget by failure cause, not by tool name. Tools that fail for the same underlying reason draw from one budget. Otherwise the model tries each in turn and you pay for every step.

Treat preconditions separately

A missing precondition should not spend the failure budget at all, and it should not read like a failure either. Its message should state the step that satisfies it. That turns a retry loop into one correct call followed by the one that was waiting.

Cap the expensive things by count, not by failure

Some calls should never be repeated inside a turn, successful or not: a long generation, a sub-agent, anything slow and metered. Give those a hard count, often one, and no recursion.

Timeouts deserve special suspicion. A timeout on an expensive call looks exactly like a transient failure worth retrying, but the first attempt may still be running and may still complete. Retrying pays twice, and on a write, it can do the thing twice.

Then make the error text do the work

Most retry spirals start with an error that said nothing useful, so the model tried the only move available, which was changing the arguments. An error that says what to do instead prevents the loop before any budget is needed. That is covered in how to write tool error messages for an AI agent.