How do you handle tool failures and errors in a product...

Tools fail constantly in production — rate limits, timeouts, bad inputs, unexpected response shapes — and the handling needs layers rather than one blanket “retry”:

• Structured errors, not exceptions — a tool that throws crashes the run; a tool that returns {"error": "...", "type": "rate_limit"} gives the agent something to reason about and act on.
• Retry with backoff — for transient failures specifically. A rate limit or timeout often clears on its own within seconds; a couple of retries with exponential backoff resolves most of these without any further logic.
• Fallback tools — if the primary genuinely isn’t coming back (a paid search API down, say), a lower-quality alternative like a scraper still beats stopping entirely.
• Graceful degradation — when every option is exhausted, the agent should say so and answer with a caveat rather than fail silently or hang.
• Circuit breaker — if a tool fails some fixed number of times in a row, stop calling it and alert, rather than letting the agent spend the rest of its budget hammering something that’s clearly broken.

The unifying idea is that failure handling shouldn’t be one mechanism doing everything — retries handle blips, fallbacks handle outages, and the circuit breaker is what stops a broken dependency from quietly consuming the whole run’s step and cost budget.