Patron Fallback-Recovery Agent: recuperacion tras fallos

Esencia del patron

Fallback-Recovery Agent es un patron donde el agente, ante un error, no termina de inmediato, sino que pasa por un proceso de recuperacion controlado: clasifica el fallo, aplica fallback e intenta reanudar la ejecucion.

Cuando usarlo: cuando es importante no caer en el primer error, sino recuperar la ejecucion con un escenario controlado.

En sistemas reales, los fallos son inevitables:

• timeouts de APIs externas
• indisponibilidad temporal de herramientas
• errores de validacion de salida
• outages parciales de dependencias

El enfoque Fallback-Recovery convierte "error = stop" en "error = escenario de recuperacion controlado".

Problema

Imagina que un agente prepara un reporte diario para un cliente:

1. leer metricas desde API
2. construir una tabla
3. enviar el resultado

En el paso dos, la API devuelve timeout.

Sin logica de recovery, el workflow se detiene.

Un error local no deberia tumbar todo el proceso si el resto de pasos sigue operativo.

Resultado:

• deadline incumplido
• progreso intermedio perdido
• reinicio manual desde cero
• comportamiento impredecible en produccion

Ese es el problema central: sin estrategia de recuperacion, incluso un fallo aislado rompe todo el escenario.

Solucion

Fallback-Recovery introduce una recovery-policy para recuperacion controlada despues de fallos.

Analogia: es como el autoguardado en un editor. Si el programa se cae, no empiezas desde cero: continuas desde el ultimo estado seguro. La misma logica aplica aqui, con limites claros.

Principio clave: no todo error debe terminar en stop duro. Parte de los errores debe clasificarse y recuperarse de forma segura.

El agente puede proponer retry, pero la capa de ejecucion decide:

• si retry esta permitido
• si se necesita fallback
• si hace falta escalation/stop

Proceso controlado:

1. Detectar: registrar el fallo
2. Clasificar: determinar tipo de error
3. Decidir: retry/fallback/escalation
4. Recuperar: continuar desde checkpoint
5. Terminar seguro: detener con stop_reason transparente

Esto aporta:

• recuperacion de procesos largos tras fallos temporales
• degradacion suave (cached/partial result)
• sin duplicar pasos ya exitosos
• motivo de parada claro

Funciona bien si:

• hay limites max_retries y max_fallbacks
• se guarda checkpoint tras progreso seguro
• la clasificacion separa retriable/non-retriable
• casos de high-risk no se recuperan automaticamente

El modelo puede "querer" hacer retry infinito, pero la recovery-policy define los limites de recuperacion segura.

Como funciona

Critico: la recuperacion debe tener limites.

• max_retries y max_fallbacks
• step_timeout y total_timeout
• stop_reason para cada salida
• prohibir “fallback -> retry -> fallback” sin contador

En codigo se ve asi

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

Guarda checkpoints tras un paso exitoso o tras progreso parcial seguro (idempotent state). Si no, retry puede duplicar acciones.

Como se ve durante la ejecucion

Goal: generar reporte para cliente

Step 1: recolectar metricas
- timeout en API primaria de analitica
- classify: retriable
- retry #1 -> fail
- retry #2 -> fail

Fallback:
- cambio a API read-replica
- exito

Resume:
- reporte ensamblado
- paso completado sin caida total del proceso

Cuando encaja - y cuando no

Encaja

No encaja

Porque este patron agrega complejidad operativa: logica de errores, estado y sobrecarga de mantenimiento.

Diferencia frente a Supervisor

Supervisor es prevencion. Fallback-Recovery es restauracion tras fallo.

Cuando usar Fallback-Recovery (vs otros patrones)

Usa Fallback-Recovery cuando necesitas restaurar ejecucion despues de fallos, en vez de tumbar todo el proceso.

Test rapido:

• si necesitas "retry/fallback/escalation despues de un error" -> Fallback-Recovery
• si necesitas "detener accion riesgosa antes de ejecutar" -> Guarded-Policy Agent

Como combinar con otros patrones

• Fallback-Recovery + ReAct: si el fallo ocurre a mitad del loop, el agente repite solo el paso problematico y no reinicia desde cero.
• Fallback-Recovery + Orchestrator: en ejecucion paralela, se recupera solo la rama rota mientras otras subtareas siguen.
• Fallback-Recovery + Supervisor: antes de recuperar, se verifican policies para que fallback no viole reglas de seguridad.

Resumen

Ventajas y Desventajas

FAQ

Q: ?Alcanza con agregar retries?
A: No. El set minimo seguro es max_retries + backoff + step_timeout + stop_reason. Sin eso, retries se convierten en loop que quema presupuesto.

Q: ?Cuando es mejor fallback que retry?
A: Cuando el error es sistemico: herramienta no disponible, quota agotada o endpoint degradado.

Q: ?Para que checkpoint si ya tenemos fallback?
A: Fallback cambia la ruta de ejecucion, pero checkpoint conserva el progreso para no repetir todo el escenario desde el inicio.

Que sigue

Fallback-Recovery agrega resiliencia ante fallos.

Pero ?como hacer que acciones peligrosas ni siquiera se inicien sin controles de policy?