Pattern Fallback-Recovery Agent : reprise apres echec

Essence du pattern

Fallback-Recovery Agent est un pattern dans lequel l'agent ne s'arrete pas simplement sur erreur, mais suit un processus de reprise controle: classifier l'echec, appliquer un fallback et tenter de reprendre l'execution.

Quand l'utiliser : quand il est important de ne pas tomber sur la premiere erreur, mais de reprendre l'execution via un scenario controle.

Dans les systemes reels, les pannes sont inevitables :

• timeouts d'API externes
• indisponibilite temporaire d'un outil
• erreurs de validation de sortie
• outages partiels des dependances

L'approche Fallback-Recovery transforme "erreur = stop" en "erreur = scenario de reprise controle".

Probleme

Imaginez qu'un agent prepare un rapport quotidien pour un client :

1. lire les metriques depuis une API
2. construire le tableau
3. envoyer le resultat

A l'etape 2, l'API renvoie timeout.

Sans logique de recovery, le workflow s'arrete.

Une erreur locale ne devrait pas faire tomber tout le processus si le reste des etapes est encore operationnel.

Ce que vous obtenez :

• delai manque
• progression intermediaire perdue
• redemarrage manuel depuis zero
• comportement imprevisible en production

C'est le probleme central : sans strategie de reprise, meme une panne unique casse tout le scenario.

Solution

Fallback-Recovery introduit une recovery-policy pour une reprise controlee apres incident.

Analogie : c'est comme l'auto-sauvegarde dans un editeur. Si le programme plante, vous ne recommencez pas de zero, vous reprenez depuis le dernier etat sur. La logique est la meme ici, avec des limites explicites.

Principe cle : toutes les erreurs ne doivent pas finir en stop immediat. Certaines doivent etre classees puis reprises en securite.

L'agent peut proposer retry, mais la couche d'execution decide :

• si retry est autorise
• si fallback est necessaire
• si escalation/stop est requis

Processus controle :

1. Detecter : enregistrer la panne
2. Classifier : determiner le type d'erreur
3. Decider : retry/fallback/escalation
4. Reprendre : continuer depuis un checkpoint
5. Terminer en securite : s'arreter avec un stop_reason clair

Cela apporte :

• reprise des processus longs apres pannes temporaires
• degradation douce (cached/partial result)
• pas de duplication des etapes deja reussies
• raison d'arret transparente

Ca fonctionne bien si :

• des limites max_retries et max_fallbacks existent
• le checkpoint est sauvegarde apres progression sure
• la classification separe retriable/non-retriable
• les cas high-risk ne sont pas repris automatiquement

Le modele peut "vouloir" retry a l'infini, mais c'est la recovery-policy qui fixe les limites de reprise sure.

Comment ca fonctionne

Critique : la reprise doit avoir des bornes.

• max_retries et max_fallbacks
• step_timeout et total_timeout
• stop_reason pour chaque sortie
• interdire “fallback -> retry -> fallback” sans compteur

En code, ca ressemble a ceci

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")  # ou 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))

Sauvegardez des checkpoints apres une etape reussie ou une progression partielle sure (idempotent state). Sinon, retry peut dupliquer une action.

Exemple pendant l'execution

Goal: generer un rapport client

Step 1: collecter les metriques
- timeout sur l'API analytics primaire
- classify: retriable
- retry #1 -> fail
- retry #2 -> fail

Fallback:
- bascule vers l'API read-replica
- succes

Resume:
- rapport assemble
- etape terminee sans rupture totale du processus

Quand c'est adapte - et quand ca ne l'est pas

Adapte

Non adapte

Car ce pattern ajoute de la complexite operationnelle : logique d'erreur, gestion d'etat et surcout de maintenance.

Difference avec Supervisor

Supervisor = prevention. Fallback-Recovery = restauration apres echec.

Quand utiliser Fallback-Recovery (vs autres patterns)

Utilisez Fallback-Recovery quand il faut restaurer l'execution apres incident, au lieu de casser tout le processus.

Test rapide :

• si vous avez besoin de "retry/fallback/escalation apres erreur" -> Fallback-Recovery
• si vous devez "arreter une action risquee avant execution" -> Guarded-Policy Agent

Combiner avec d'autres patterns

• Fallback-Recovery + ReAct: si l'echec arrive au milieu de la boucle, l'agent relance seulement l'etape en echec au lieu de repartir de zero.
• Fallback-Recovery + Orchestrator: en execution parallele, seule la branche en panne est reprise, les autres sous-taches continuent.
• Fallback-Recovery + Supervisor: avant reprise, on verifie les policies pour que le fallback ne viole pas les regles de securite.

En bref

Avantages et Inconvenients

FAQ

Q: Ajouter des retries suffit-il ?
A: Non. Le minimum sur est : max_retries + backoff + step_timeout + stop_reason. Sans cela, les retries deviennent une boucle qui brule le budget.

Q: Quand preferer fallback a retry ?
A: Quand l'erreur est systemique : outil indisponible, quota epuisee ou endpoint degrade.

Q: Pourquoi checkpoint si on a deja fallback ?
A: Le fallback change le chemin d'execution, mais le checkpoint preserve la progression pour eviter de relancer tout le scenario depuis le debut.

Et ensuite

Fallback-Recovery ajoute de la resilience aux pannes.

Mais comment faire pour que des actions dangereuses ne demarrent jamais sans controles de policy ?