Fallback-Recovery Agent Pattern: Recover from Failures

Pattern Essence

Fallback-Recovery Agent is a pattern where an agent does not just terminate on error, but goes through a controlled recovery process: classifies the failure, applies a fallback, and attempts to resume execution.

When to use it: when it is important not to crash on the first error, but to recover execution through a controlled scenario.

In real systems, failures are inevitable:

• external API timeouts
• temporary tool unavailability
• output validation errors
• partial dependency outages

The Fallback-Recovery approach turns "error = stop" into "error = controlled recovery scenario".

Problem

Imagine an agent prepares a daily report for a client:

1. read metrics from an API
2. build a table
3. send the result

At step two, the API returns timeout.

Without recovery logic, the workflow simply stops.

One local error should not break the entire process if the remaining steps are still operable.

What you get:

• a missed deadline
• lost intermediate progress
• manual restart from zero
• unpredictable behavior in production

That is the core issue: without a recovery strategy, even a single failure breaks the whole scenario.

Solution

Fallback-Recovery introduces a recovery policy for controlled post-failure recovery.

Analogy: this is like autosave in an editor. If the app crashes, you do not start from scratch, you continue from the last safe state. The same logic applies here, but with explicit boundaries.

Key principle: not every error should be "hard-stopped". Some errors should be classified and recovered safely.

The agent may suggest retry, but the execution layer decides:

• whether retry is allowed
• whether fallback is required
• whether escalation/stop is needed

Controlled process:

1. Detect: record the failure
2. Classify: determine error type
3. Decide: retry/fallback/escalation
4. Recover: continue from checkpoint
5. End safely: stop with a clear stop_reason

This gives you:

• recovery of long-running processes after temporary failures
• graceful degradation (cached/partial result)
• no duplication of already successful steps
• a transparent stop reason

Works well if:

• max_retries and max_fallbacks limits exist
• checkpoint is saved after safe progress
• classification separates retriable/non-retriable
• high-risk cases are not auto-recovered

The model may "want" to retry infinitely, but the recovery-policy defines safe recovery boundaries.

How It Works

Critical: recovery must have boundaries.

• max_retries and max_fallbacks
• step_timeout and total_timeout
• stop_reason for every exit
• block “fallback -> retry -> fallback” without a counter

In Code It Looks Like This

fallbacks_used = 0

for attempt in range(max_retries + 1):
    try:
        result = run_step(goal, context, timeout_sec=step_timeout)
        checkpoint.save(task_id, context, result)
        return result

    except TimeoutError as err:
        kind = "retriable"

    except ToolUnavailableError as err:
        kind = "tool_unavailable"

    except ValidationError as err:
        kind = "invalid_output"

    except Exception as err:
        kind = classify_error(err)

    if kind == "retriable" and attempt < max_retries:
        sleep(backoff(attempt))
        continue

    if kind == "tool_unavailable" and fallbacks_used < max_fallbacks:
      fallbacks_used += 1
      context.append(f"fallback_used={fallbacks_used}")
      context.append("route=secondary_tool")  # or alt_model / cached_path
      continue

    if kind == "high_risk":
        return escalate_to_human(goal, err, stop_reason="high_risk")

    return stop_with_reason(goal, stop_reason=kind, detail=str(err))

Save checkpoints after a successful step or after safe partial progress (idempotent state). Otherwise retry can duplicate actions.

What This Looks Like During Execution

Goal: prepare a client report

Step 1: collect metrics
- timeout in primary analytics API
- classify: retriable
- retry #1 -> fail
- retry #2 -> fail

Fallback:
- switch to read-replica API
- success

Resume:
- report assembled
- step completed without full process failure

When It Fits - and When It Does Not

Good Fit

Not a Good Fit

Because a recovery pattern adds operational complexity: error logic, state handling, and maintenance overhead.

How It Differs from Supervisor

Supervisor is prevention. Fallback-Recovery is post-failure restoration.

When to Use Fallback-Recovery (vs Other Patterns)

Use Fallback-Recovery when you need to restore execution after failures instead of collapsing the whole process.

Quick test:

• if you need "retry/fallback/escalation after an error" -> Fallback-Recovery
• if you need "stop a risky action before execution" -> Guarded-Policy Agent

How to Combine with Other Patterns

• Fallback-Recovery + ReAct: if failure happens mid-loop, the agent retries only the failing step instead of restarting from zero.
• Fallback-Recovery + Orchestrator: in parallel execution, only the broken branch recovers while other subtasks continue.
• Fallback-Recovery + Supervisor: policies are checked before recovery so fallback does not violate safety rules.

In Short

Pros and Cons

FAQ

Q: Is adding retries alone enough?
A: No. The minimum safe set is max_retries + backoff + step_timeout + stop_reason. Without this, retries become a budget-burning loop.

Q: When is fallback better than retry?
A: When the failure is systemic: tool unavailable, quota exhausted, or endpoint degraded.

Q: Why do we need checkpoint if we already have fallback?
A: Fallback changes the execution path, but a checkpoint preserves progress so you do not rerun the whole scenario from the beginning.

What Next

Fallback-Recovery adds failure resilience.

But how do you make sure risky actions are never started without policy checks?