What should an AI agent do when a tool call fails?

Tool failures divide into two classes and the appropriate response differs completely. Transient failures — a timeout, a rate limit, a temporary outage, a lock — are caused by conditions that pass, and retrying with a delay is correct. Structural failures — a permission denial, a path that does not exist, a malformed argument, an unsupported operation — are caused by conditions that persist, and retrying is pure cost. An agent that does not distinguish them will do the same thing repeatedly and describe it as persistence.

The distinguishing information is in the error message, which is why the message must reach the agent rather than being collapsed into a generic failure. A runtime that reports only that a call did not succeed has removed the one input needed to choose a response, and the agent then guesses, which usually means retrying. Where a tool returns useful error detail, passing it through unchanged is the single highest-value thing the integration can do.

Retry policy needs a limit and a delay, and both should live outside the agent's judgement. Two or three attempts with increasing gaps covers nearly all genuinely transient conditions; beyond that the failure is telling you something and the correct action is to stop and report. Leaving the retry decision to the agent produces either premature abandonment or a loop, depending on how the situation reads, and neither is a property you want varying by run.

The worst response is not a bad retry. It is proceeding as though the call had succeeded, which produces work built on an assumption about state that is false, and a completion report that describes actions which never took effect. This is why reading back the result of consequential operations matters so much: it converts an unnoticed failure into a noticed one at the moment it happens rather than at the moment someone finds the consequence.

There is a third class worth separating because it is deceptive: the call that succeeded and returned something unusable. An empty result, a truncated response, a partially written file, a rate-limited response body that is actually an error page. These do not appear as failures at any layer and are handled as data. Validating the shape of what came back — not just whether the call returned — is the control, and it is the difference between a system that fails loudly and one that fails quietly into the output.

Finally, a structural failure is usually a message about configuration rather than about the run. A permission denial means the account is wrong. A missing path means the assumption about layout is wrong. Reporting these as agent failures rather than as setup failures sends the investigation in the wrong direction, and a report that names the class of failure saves whoever reads it a considerable amount of time.