Retry & Fallback
Demos assume every API is up. Production is 429s and 500s.
A backup route when the bridge is closed — not driving into the river twice.
Visual Workflows
Start here — scroll inside each diagram frame to explore, then use + / − to zoom up to 200% if needed.
Overview
Scroll inside the frame to explore · use + / − to zoom up to 200%
Scroll inside the frame to explore · use + / − to zoom up to 200%
Failure path
Scroll inside the frame to explore · use + / − to zoom up to 200%
Retry once with backoff, then fallback, then HITL.
Key Takeaways
- 1.Tools fail: timeouts, 429s, empty data, downstream bugs. Retry only what is safe — GET yes, refund maybe not.
- 2.Fallback: another tool, a cached answer, or a human. Cap retries. Infinite loops burn money and anger users.
- 3.Classify errors. Idempotent reads can retry with jitter.
- 4.Writes need idempotency keys. After N failures, switch tool or escalate.
- 5.Tell the model the error was transient vs permanent.
Learn elsewhere
- →Tool Permissions
- →Production agents — Phase 21
Real Example
Scenario
search_web 429s. Retry once after 400ms. Still failing → cached results from an hour ago, labeled stale, plus a note to the user.
What you would do
In Tool Calling & Function Calling, apply Retry & Fallback to this scenario: search_web 429s. Identify the inputs, run the technique, validate the output, and note one thing you would monitor in production.
Commands
Commands to Remember
Retry idempotent readsIdempotency keys on writesCap NFallback then HITL
Cheat Sheet
Quick recap
quick ref- •Tools will fail
- •Safe vs unsafe retry
- •Backoff + cap
- •Human last
Common Mistakes
- ✕Retrying a refund three times
- ✕No cap on the agent loop
- ✕Swallowing errors so the model invents success