A tool call fails constantly in production for reasons that have nothing to do with the model being wrong: an upstream API times out, a resource genuinely doesn't exist, a user lacks permission for the action requested, or the model itself supplied a malformed argument. The design decision that determines whether an agent survives these failures or collapses on the first one is where the failure is allowed to surface.
The Claude API defines the mechanism precisely: a tool's outcome is reported back as a tool_result content block — {"type": "tool_result", "tool_use_id": ..., "content": ...} — inside a user-role message, with "is_error": true set when the tool itself failed. That result is not a side channel or a log line; it is part of the conversation the model reads on its next turn, exactly like a successful result would be.
The failure of that design discipline looks different: an exception raised inside your dispatcher and left uncaught doesn't produce a tool_result at all. It unwinds the stack, the request that was supposed to continue the conversation never gets sent, and the agent loop simply stops, mid-task, with no message the model can react to. Most tool errors should never reach that point — they should become tool_result blocks with is_error true, because a failed tool call is a normal outcome the model can reason about, not a transport failure that ends the session.
Analogy🏏Cricket
🏏 Think of it like cricket: When Bumrah oversteps and bowls a no-ball at the death, the umpire doesn't stop the match — he calls it, the scoreboard shows an extra run, the batting side gets a free hit next ball, and play continues immediately. The no-ball is a fact reported back into the game that the batting team can act on: swing hard, because the free hit removes the risk of being bowled or caught. Contrast that with what happens when the floodlights fail at the Chinnaswamy mid-over, or the umpires decide the light is too dangerous to continue: the players don't get a message they can respond to, they simply walk off, the innings is suspended, and nobody on the field can do anything about it until officials intervene from outside the game entirely. A no-ball is the model's tool_result with is_error true — the game absorbs it, the batting side adjusts strategy, and the next ball is bowled. A floodlight failure is an uncaught exception in your dispatcher — the loop halts, the agent has no next ball to react to, and recovery needs code outside the conversation, not a smarter batter. Most tool failures during a match are no-balls, not floodlight failures, and treating every no-ball like a stadium blackout is why agents die on problems a good batter would have simply adjusted to.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.