Retry & Fallback

APIs timeout, rate-limit, and change schemas. Production agents must degrade gracefully, not halt on the first 500 error.

Retry and fallback is GPS rerouting — 'road closed, taking alternate route' instead of stopping the car.

Scenario

Weather API times out → retry once → fall back to cached weather → if still failing, tell user 'Weather data temporarily unavailable' and continue the task.

Solution

In Tool Calling & Function Calling, apply Retry & Fallback to this scenario: Weather API times out → retry once → fall back to cached weather → if still failing, tell user 'Weather data temporarily unavailable' and continue the task. Identify the inputs, run the technique, validate the output, and note one thing you would monitor in production.

Do this before moving to the next module — reading alone is not enough.

Open the Code Walkthrough below and run it locally. Change one parameter related to Retry & Fallback (e.g. model, temperature, top_k, or tool name), observe the difference in output, and write 2–3 sentences explaining what changed.

Highlighted lines show where Retry & Fallback happens in the code.

1async def call_with_retry(fn, args, max_retries=3):  # key line for Retry & Fallback2    for attempt in range(max_retries):3        try:4            return await fn(**args)  # return the result5        except TransientError as e:6            if attempt == max_retries - 1:7                raise8            await asyncio.sleep(2 ** attempt)

• Treating Retry & Fallback as a black box without evaluation
• Ignoring cost and latency in production
• Skipping error handling for retry and fallback

Quick recap — the most important points from this module.