Exception Handling & Recovery

Key points

• Tools, networks and even the LLM WILL fail sometimes.
• Catch the error, don't let one failed step kill the whole run.
• Recovery options: retry (with backoff) → fallback → ask a human.

What 'Exception Handling & Recovery' means

Exception handling is wrapping risky actions (tool calls, API requests, parsing the LLM's answer) so that when they fail, your code catches the error instead of crashing. Recovery is what you do next: retry the step (often after a short wait), use a fallback plan, or escalate to a person. The goal is graceful failure, not a stack trace in the user's face.

Note: Catch the error → decide: retry, fall back, or ask for help. Never just crash.

Fragile agent vs resilient agent

FRAGILE (crashes) RESILIENT (recovers) ───────────────── ────────────────────

call tool call tool │ │ ▼ ▼ ❌ timeout ❌ timeout │ │ caught! ▼ ▼ 💥 WHOLE AGENT ┌──────────────┐ CRASHES │ retry (wait) │──┐ user sees a └──────────────┘ │ stack trace 😱 │ still fails? │ ▼ │ ┌──────────────┐ │ │ fallback plan│◄─────┘ └──────┬───────┘ │ also fails? ▼ 🙋 ask a human (escalate)

Your recovery toolbox

• Retry with backoff — Try again, waiting a bit longer each time, for flaky/temporary errors. Example: Wait 1s, then 2s, then 4s (exponential backoff) before giving up.
• Fallback — A simpler plan B when the main path keeps failing. Example: Search API down? Use a cached answer or a cheaper search.
• Escalate to human — When the agent truly can't proceed safely, hand off to a person. Example: "I couldn't book this; here's what I tried — please confirm."
• Validate LLM output — Treat the model's answer as untrusted; check shape before using it. Example: Expecting JSON? Parse it; if it fails, ask the LLM to fix it.

Retry with exponential backoff (why we wait longer each time)

Attempt 1 ✗ fail ──► wait 1s Attempt 2 ✗ fail ──► wait 2s Attempt 3 ✗ fail ──► wait 4s Attempt 4 ✓ success! (server had recovered)

time ─────────────────────────────────────────────► |‐| |‐‐| |‐‐‐‐| 1s 2s 4s gaps grow so we don't hammer a struggling server

A tiny code example (try/except + retry + fallback)

This wraps a flaky tool. It retries with growing waits, and if all retries fail it uses a fallback instead of crashing.

import time

def call_with_recovery(tool, args, max_retries=3):
    delay = 1.0
    for attempt in range(1, max_retries + 1):
        try:
            return tool(args)                       # try the risky action
        except TimeoutError as e:                   # catch only what we expect
            print(f"attempt {attempt} failed: {e}")
            if attempt == max_retries:
                break
            time.sleep(delay)                       # wait...
            delay *= 2                              # ...longer each time (backoff)
    return fallback(args)                          # plan B, never crash

def fallback(args):
    cached = cache_lookup(args)
    if cached is not None:
        return cached
    return escalate_to_human(args)                 # last resort

When recovery matters most

Recovery mistakes

Recovery rules of thumb

• Catch specific errors, log them, never use a silent bare except.
• Retry order: backoff → fallback → escalate to a human.
• Never blindly retry actions that change money or delete data.

Key takeaways

• Tools, networks and LLMs all fail; the agent must catch errors, not crash.
• Recovery options in order: retry with backoff, then fallback, then escalate to a human.
• Use exponential backoff and a retry cap so you don't hammer struggling services.
• Never auto-retry irreversible actions; validate LLM output before using it.

Frequently Asked Questions

Related topics

• Goal Setting & Monitoring
• Learning & Adaptation
• Memory Management Pattern
• Multi-Agent Collaboration
• Prompt Chaining Pattern

Browse all Agentic AI Patterns topics →