Error Recovery en AI Agents 2026: El Try-Catch es la Herramienta Equivocada para un Sistema Estocástico

El 95% de los AI Agents que Construyes Hoy se Van a Romper en Producción

No es culpa del modelo. Es culpa de tu try-catch.

La mayoría de los desarrolladores tratan los AI agents como software determinista. Escribís código que asume que el LLM devolverá JSON válido. Que la tool call funcionará. Que el contexto cabrá en la ventana.

Y cuando falla, ponéis un try-catch alrededor del loop y llamáis a eso "error handling".

*El problema no es que los agents fallen. Es que los tratáis como funciones puras cuando son sistemas estocásticos. *

Y un sistema estocástico no lanza excepciones. Produce respuestas plausibles pero incorrectas. Tool calls alucinadas con argumentos perfectamente formados. JSON válido que describe la cosa equivocada.

El try-catch es la herramienta equivocada no porque esté mal implementado. Es porque captura exactamente la categoría de error que no es el problema real.

---

El Problema: El Fallo de un LLM Casi Nunca Llega como Excepción

En software determinista, una excepción tiene semántica definida. Un TimeoutError significa que algo tardó demasiado. Un SchemaError significa que los datos no encajan. El handler sabe exactamente qué pasó y qué hacer.

Con un LLM, el "error" rara vez llega como excepción. Llega como:

Una respuesta sintácticamente correcta pero semánticamente errónea.
Un argumento de tool alucinado que parece plausible.
Un JSON malformado que solo descubre el parser, cuando ya es tarde.

El momento en que se dispara tu `except` es el momento en que el sistema estocástico ya te mintió.

Y ojo: el retry con backoff que te ha funcionado toda la vida también falla aquí. Los retries solo cubren errores transitorios — un 429 de rate limit, un timeout temporal. Si el fallo es silencioso (respuesta incorrecta pero válida), el retry re-ejecuta el mismo fallo y le llama "recuperación".

❌ El error del enfoque clásico:

- try-catch alrededor del loop → no captura fallos silenciosos

- retry + backoff genérico → repite el mismo fallo en bucle

- "más contexto" → no arregla una tool caída

- "un modelo mejor" → sigue siendo estocástico

✅ El enfoque que funciona:

- Classificar el error antes de decidir la recuperación

- Handlers específicos por fase (planificar, ejecutar, responder)

- Fallar hacia la seguridad: auto-recuperar solo con confianza alta

- Instrumentar cada recuperación para aprender de ella

La recuperación de verdad no es un bloque de excepciones. Es una máquina de estados con handlers específicos por fase.

---

La Evidencia: Por Qué los Retries "Funcionan" sin Funcionar

Hay una razón por la que tantos agentes pasan las demos y se rompen en producción. La demo es un camino de felicidad: el modelo devuelve lo esperado, la tool responde, el JSON parsea. En producción el espacio de fallos se multiplica — rate limits de una API de terceros, tools caídas a las 3 de la madrugada, esquemas que cambian sin avisar, inputs adversariales.

A quienes les funciona el retry con backoff, les digo una cosa: funciona porque el fallo es transitorio, no porque tu código de recuperación sea bueno. Estás cubriendo el 20% de los fallos y llamándolo solución.

Un clasificador de errores bien construido no sustituye al retry. Le dice al retry cuándo tiene sentido y cuándo está tirando el dinero.

Taxonomía de errores

El primer paso es inventariar los fallos reales de tu agente. Recorre tus logs de producción y clasifica cada incidente en una de estas categorías:

La clave: el clasificador opera también sobre outputs sintácticamente exitosos, no solo sobre excepciones.

Un JSON que parsea pero devuelve un argumento imposible (una cita fuera de horario en un sistema de reservas) entra en MODEL_OUTPUT_INVALID. Ahí no hay excepción. Ahí hay semantic validation: un validador de resultados, no un parser.

---

La Máquina de 3 Fases: Plan → Tool → Respond

Recuperarse de una fallo no es un acto. Es un proceso que depende de en qué fase del ciclo esté tu agente cuando falla.

Retryar una llamada a tool fallida es barato. Pero retryar un plan fallido re-ejecuta trabajo ya hecho y multiplica coste y latencia. Y re-ejecutar sin más cuando falla la generación de respuesta es repetir exactamente el mismo fallo.

Cada fase necesita su propio mecanismo de recuperación:

Fase 1: Planificación → re-plan con feedback

Si el plan propuesto lleva a un callejón sin salida, no repitas el plan. Re-planifica inyectando el error como feedback en el contexto del modelo.

Fase 2: Ejecución → retry + circuit breaker

Para errores transitorios en una tool: retry con exponential backoff + jitter. Para fallos repetidos: circuit breaker — corta la tool tras N fallos consecutivos y reanuda desde el último paso persistido en vez de reiniciar el workflow completo.

Fase 3: Generación → re-prompt con el error en contexto

Cuando el output del modelo es inválido, no relances la misma llamada con el mismo prompt. Eso es la definición de locura.

Usa el semantic retry: inyecta el mensaje de error en el contexto del modelo para que se autocorrija a nivel de prompt, no de excepción.

El error #1 que comete todo el mundo: mezclar las recuperaciones. Re-planificar cuando había que hacer retry, o re-prompt cuando había que cortar la tool. Cruzar esos mecanismos produce el clásico bucle infinito de "recuperación" que repite el mismo fallo cuatro veces seguidas.

---

El ErrorClassifier Híbrido: Reglas Primero, LLM Solo para lo Ambiguo

"Vale, ¿y si uso un LLM para clasificar el error?" no. Un LLM-judge añade otro punto de fallo al sistema que está fallando.

El clasificador correcto es híbrido: reglas deterministas para lo que ya conoces, LLM solo para lo ambiguo, y siempre con un umbral de confianza que escale a humano en vez de auto-recuperar a ciegas.

La regla de oro: auto-recuperar mal es peor que parar.

Un agente de pagos que "corrige" un fallo re-cobrando dos veces causa un desastre mayor que un halt con alerta. El diseño debe fallar hacia la seguridad: umbral de confianza bajo ⇒ escalado humano, no auto-recuperación temeraria.

---

El Decorator @recover: El Orquestador de la Robustez

Esta es la pieza que une todo. Un decorator que envuelve cada paso del agente, intercepta el fallo, lo pasa por el clasificador, elige el handler según la fase y registra la decisión.

Este @recover no sustituye a la lógica de negocio. Es la capa de orquestación de la robustez — y aquí está el punto que conecta con todo lo que sabemos sobre agentes en 2026: el modelo subyacente es commodity. La ventaja competitiva está en la capa que decide cómo clasificar y recuperarse de un fallo.

El ErrorClassifier es esa capa para la fiabilidad.

---

Checkpointing: Reanudar, No Reiniciar

Para workflows largos — un agente de investigación que ejecuta 20 tools, un pipeline de ETL con 15 pasos — el checkpointing no es opcional.

El patrón es simple: persiste el resultado de cada paso antes de pasar al siguiente. Si el workflow muere a mitad de camino, reanudas desde el último checkpoint, no desde el principio. Coste y latencia multiplicados por el número de pasos que NO necesitas re-ejecutar.

---

Instrumenta Cada Recuperación

Un agente que recupera sin registrar qué recuperó, cuántos intentos hizo y qué ruta tomó es un agente que nunca mejora.

Con esos datos aprendes cosas que ningún retry te enseña:

Qué tools degradan la fiabilidad a los pocos días de estar en producción.
Dónde está el límite correcto de tu circuit breaker.
Qué categorías de error estás clasificando como `AMBIGUOUS` cuando en realidad son fallos de una dependencia que va a vuelta.

Ajustas umbrales con datos, no con intuición.

---

¿Un Modelo Mejor No Arregla Esto?

No. Y es la objeción que hay que cerrar ya.

Un modelo más capaz sigue siendo estocástico. Produce outputs malformados. Alucina tool args con argumentos plausibles. Y choca con errores de infraestructura — rate limits, tools caídas, esquemas que cambian — que ningún prompt resuelve.

La arquitectura de recuperación es ortogonal a la calidad del modelo. El fallo es estructural, no de capacidad.

Y el coste de no hacerlo bien es invisible: tu agente no se cae, se queda. Responde de forma convincente con datos equivocados. Genera un ticket de soporte con el campo de cliente vacío. Confirma una cita para una hora que no existe.

Eso no aparece en tus dashboards de uptime. Aparece en tu cola de soporte, seis semanas después.

---

La Frase Final

Construir agentes que sobrevivan a producción no es construir agentes que no fallen. Es construir agentes que detecten, clasifiquen y se recuperen de forma distinta según la fase en la que están.

La máquina de recuperación — clasificador híbrido, handlers por fase, decorator, checkpointing, telemetría — no es un afterthought. Es el feature de primer orden que separa una demo impresionante de un agente que aguanta el turno de noche de un sábado.

Tu modelo es commodity. Tu capa de clasificación y recuperación es tu ventaja.

*Construye esa capa como si tu agente fuera a fallar en el peor momento posible. Porque lo hará. Y la diferencia entre un incidente y un desastre es lo que pasa en los primeros 300 milisegundos después del fallo. *