A taxonomy worth having
Tool failures are not one thing, and treating them uniformly produces bad behaviour. The distinct cases: the call was malformed; the call was well-formed but the arguments were wrong; the tool was unavailable; the tool returned an error; the tool returned success with an unexpected shape; the tool returned success with content that was wrong; and the tool succeeded but took long enough that something upstream gave up.
Each wants a different response, and the difference between a fragile agent and a robust one is usually whether these were distinguished at all.
The two that cause the most damage
Success with an unexpected shape is dangerous because it does not look like a failure. The call returned 200, the agent proceeds, and the error surfaces several steps later somewhere unrelated. Schema validation on the way back — not just on the way in — converts a confusing downstream symptom into an immediate, localised failure.
Success with wrong content is worse, because no amount of validation catches it. A search returning stale results is structurally valid and semantically useless. The only defences are cross-checking where the stakes justify it, and not treating tool output as ground truth simply because it arrived without an error.
Retries need discretion
Blind retry is a common and expensive default. A malformed call will fail identically on retry — that one needs reformulation, not repetition. An unavailable service warrants backoff. Wrong arguments warrant a different approach entirely. And any tool with side effects needs idempotency handled before retry is safe, or the retry becomes a duplicate order.
Retry budgets belong in the design. Uncapped retries are the most common route to a run that costs many multiples of its expected price while accomplishing nothing.
Let the agent see the failure
There is a real design choice about whether failures are handled below the agent or surfaced to it. Surfacing a structured, informative error is often better than hiding it, because a capable model can adapt — try a different tool, narrow the query, or report honestly that it cannot proceed.
That requires the error to be informative. 'Request failed' gives nothing to reason about. 'No results for that identifier; the identifier format appears to be X' enables an actual recovery.
Know when to stop
Every agent needs a termination condition that is not success. Step limits, cost ceilings, wall-clock timeouts, and a defined behaviour when they are reached. Failing cleanly with a clear account of what was attempted is a good outcome. Looping until a budget is exhausted is not.
A clean failure is also a much better customer experience than a confident wrong answer, which is the alternative an agent will produce if you leave it no honest exit.