Manejo de errores en sistemas multiagente: reintentos, fallbacks, circuit breakers

El manejo de errores en sistemas multiagente engloba todos los mecanismos que impiden que el fallo de un solo agente haga caer todo el sistema: timeouts, reintentos con backoff, agentes de fallback, circuit breakers y observabilidad de extremo a extremo. El objetivo es la tolerancia a fallos: un subagente puede fallar sin que los errores se encadenen en cascada ni se propaguen. En un sistema de un solo agente, el manejo de errores es en gran medida un problema resuelto; en cuanto colaboran varios agentes con sus propias ventanas de contexto, herramientas y roles, surgen clases de fallos que en un único bucle de tool use sencillamente no existen.

• Separa la ruta de lectura y la de escritura: muchos agentes pueden leer y proponer en paralelo, pero solo uno (o una etapa del pipeline) hace el commit. Es el medio más eficaz contra la propagación de errores.
• Limita cada tarea: un timeout, un límite de tokens y un estado failed explícito por subagente evitan deadlocks y explosiones de costes.
• Verifica antes de sintetizar: un agente Verifier-Judge intercepta los hechos alucinados antes de que el agente principal los escriba como verdad en la respuesta.

Por qué el manejo de errores en sistemas multiagente es diferente

Un sistema multiagente consta de varios agentes basados en LLM (cada uno con su propio prompt, su propio rol, su propio conjunto de herramientas y, en el caso más estricto, su propia ventana de contexto) que resuelven juntos una tarea. Precisamente esta distribución crea nuevas superficies de fallo. Ya no hay una única traza, sino N trayectorias de subagentes más una síntesis. Las ejecuciones no son deterministas: la misma entrada genera subagentes distintos en un orden distinto. Y el sistema puede mostrar comportamientos emergentes que ningún agente individual ha planificado así.

El peligro central es la propagación de errores. Si un subagente alucina un hecho, el agente principal lo sintetiza en la respuesta final y los agentes posteriores actúan sobre la base de ese hecho falso. Un error local se convierte en una decisión errónea a escala de todo el sistema. Por eso, el manejo de errores en sistemas multiagente significa dos cosas: hacer que cada agente resista las caídas transitorias y evitar que los errores se extiendan a lo largo de la cadena de agentes.

Las ocho clases de fallos que no tienen los sistemas de un solo agente

La siguiente relación es un resumen propio de las clases de fallos que Anthropic, Cognition, Sierra, Salesforce y Microsoft han descrito a partir de sus sistemas en producción. Quien lleve un sistema multiagente a producción tiene que conocerlas.

Tres de estas clases (cascadas, deadlock y fragmentación del contexto) son los verdaderos motores de la propagación de errores. Las otras cinco la amplifican o la vuelven invisible.

Evitar la propagación de errores: separar las rutas de lectura y escritura

La decisión de arquitectura más importante contra la propagación de errores no es una herramienta, sino un principio. Cognition lo resumió en «Don't Build Multi-Agents» (junio de 2025) y en la actualización «Multi-Agents: What's Actually Working» (abril de 2026): el fan-out multiagente para leer es robusto, el fan-out multiagente para escribir es frágil. La consecuencia es la regla de las single-threaded writes:

• Single-threaded writes: muchos agentes leen, investigan y proponen, pero solo un agente o una etapa del pipeline hace el commit. Un agente lector defectuoso solo aporta un fragmento que el agente principal puede descartar o volver a solicitar.
• Escrituras independientes con reconciliación: cada subagente entrega un fragmento y el agente principal los reconcilia en la salida final (el patrón del agente de investigación de Anthropic).
• Escrituras concurrentes sobre un estado compartido: la espiral de la muerte. Evítalas a toda costa.

La observación de Cognition detrás de esto: los «apparent disagreements» entre agentes suelen ser síntomas de fragmentación del contexto, no de un desacuerdo real. Donde el acoplamiento es alto, hay que compartir las trazas completas de los agentes en lugar de solo mensajes sueltos. Para la memoria externa compartida (vector store, Postgres, SAP HANA), en la mayoría de los sistemas en producción rige la misma regla: un escritor, muchos lectores.

Reintentos con backoff, timeouts y circuit breakers

En el nivel de cada llamada a un agente o a una herramienta se aplican los patrones clásicos de resiliencia, trasladados del mundo de los microservicios:

• Reintentos con backoff exponencial: ante errores transitorios (rate limit, caída breve de una herramienta, timeout), la llamada se repite con tiempos de espera crecientes, idealmente con jitter para evitar efectos de thundering herd. Importante: los reintentos solo sirven contra errores transitorios, no contra los semánticos. Volver a llamar a un agente que alucina produce la misma alucinación.
• Timeouts en cada tarea: el protocolo A2A define un ciclo de vida de tarea submitted → working → input-required → completed | failed | canceled. Un timeout en cada tarea más el estado explícito input-required son la contramedida documentada contra los resource deadlocks. Sin timeout, un agente en espera puede bloquear todo el sistema.
• Circuit breaker: si los errores de un subagente o una herramienta superan un umbral, el breaker se abre y bloquea nuevas llamadas durante una ventana de tiempo. Eso frena la explosión de costes y deja margen para un fallback.
• Agentes de fallback y respuestas degradadas: si falla un agente especializado, toma el relevo un agente de fallback más sencillo, otro nivel de modelo o una respuesta deliberadamente reducida. Mejor una salida honestamente limitada que una decisión errónea en cascada.

La disciplina práctica de tokens de la referencia del agente de investigación de Anthropic lo complementa: limitar explícitamente el gasto de tokens de los subagentes (algo que admiten Bedrock AgentCore, LangGraph y Claude Agent SDK), forzar las salidas de los subagentes a un esquema tipado (Pydantic, JSON Schema, A2A Artifact) y comprimirlas antes de devolverlas, y no pasar nunca al agente principal la transcripción completa de un subagente. Un esquema tipado es a la vez una frontera de errores: lo que no encaja en el esquema se rechaza en lugar de transmitirse.

Monitorización y observabilidad: requisito previo, no un complemento

El debuggability collapse es la clase de fallo más traicionera: cuando algo sale mal, no hay una única traza que explique la ejecución. Por eso la observabilidad no es opcional para ningún sistema multiagente en producción. Los componentes:

• Tracing distribuido en toda la malla A2A, con un ID de correlación/traza continuo en cada tarea A2A y cada llamada MCP. En 2026, OpenTelemetry es el estándar transversal.
• Herramientas (estado en 2026): LangSmith para trazas internas de LangGraph; Galileo o Arize Phoenix para trazas multiagente entre distintos proveedores; Pydantic Logfire en equipos con mucho Python; Datadog/Splunk/Grafana para la correlación con el SIEM.
• Patrón Verifier-Judge: un agente juez independiente, a menudo un modelo más potente que los workers, evalúa cada trayectoria con una pequeña rúbrica: ¿tarea completada? ¿Respuesta fundamentada? ¿Los agentes se han mantenido en su tarea? ¿Presupuesto respetado? Es la respuesta más ligera y apta para producción contra los fallos en cascada.

Para la región DACH (Alemania, Austria y Suiza), la observabilidad es además una cuestión de cumplimiento normativo. En su guía orientativa sobre riesgos TIC en el uso de la IA de diciembre de 2025, la BaFin recomienda a las entidades financieras registrar todos los eventos y actividades relevantes de los sistemas de IA para hacerlos trazables. La base es DORA, cuyo cumplimiento en Austria supervisa la FMA. La FINMA constata en su Comunicación de supervisión 08/2024 que los resultados de la IA a menudo no pueden rastrearse, explicarse ni reproducirse. Para un sistema de agentes, esto significa: trazas de extremo a extremo de cada llamada a agentes, reproducibilidad (fijar las versiones de modelo en producción, registrar todos los prompts de subagentes, tool calls y AgentCards) y almacenamiento de auditoría append-only. Los plazos de conservación dependen del sector y del país, y deben acordarse con compliance antes de montar el almacenamiento de auditoría.

Ejemplo: Allianz Project Nemo

Project Nemo de Allianz Australia, filial de la aseguradora muniquesa Allianz, es uno de los despliegues multiagente mejor documentados de un grupo de la región DACH y una lección práctica de manejo de errores. Siete agentes especializados (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) tramitan siniestros por deterioro de alimentos tras catástrofes naturales. El flujo de trabajo completo de los siete agentes se ejecuta en menos de cinco minutos.

Aquí hay dos principios de manejo de errores anclados en la propia arquitectura:

• Agente de auditoría como elemento de la topología: un agente dedicado genera un resumen completo de todas las decisiones de los agentes y sus justificaciones, es decir, un audit trail completo para compliance, control de calidad y revisión humana. La auditabilidad está integrada en la topología de agentes, no añadida después en el pipeline de logging.
• Human-in-the-loop en la etapa crítica: un tramitador humano revisa el resumen de auditoría y toma la decisión final de pago. Una decisión errónea en cascada se intercepta en el punto más caro e irreversible, como política explícita.

El resultado: una reducción del 80 % del tiempo de tramitación y liquidación de los siniestros admisibles de menos de 500 AUD, en producción en menos de 100 días (Australia, julio de 2025). La lección para el manejo de errores: agentes modulares con roles claros, una ruta de auditoría dedicada y un punto de control humano dan como resultado un sistema rápido y controlable.

Checklist práctica de manejo de errores

• ¿Ruta de escritura single-threaded? Exactamente un agente/una etapa hace el commit; los lectores hacen fan-out, los escritores no.
  
• ¿Timeout en cada tarea? Más un estado input-required explícito contra los deadlocks.
  
• Reintentos con backoff + jitter solo para errores transitorios, no para los semánticos.
  
• Circuit breaker por subagente/herramienta con umbral y ventana de reinicio.
  
• Agente de fallback o respuesta degradada definidos para cada agente crítico.
  
• Límites de tokens por subagente establecidos; salidas forzadas a un esquema tipado y comprimidas.
  
• Agente Verifier-Judge que revisa las trayectorias antes de la síntesis final.
  
• Grounded retrieval + fuentes obligatorias contra las cascadas de alucinaciones.
  
• Trazas completas compartidas cuando el acoplamiento es alto; contratos de decisión explícitos.
  
• ID de correlación en cada tarea A2A y cada llamada MCP; exportación a OTel.
  
• Human-in-the-loop en los pasos irreversibles o caros.
  
• Versiones de modelo fijadas, audit trail append-only, conservación conforme al sector.
  

Para agencias y responsables de decisiones B2B

Para las agencias de marketing y los proveedores nativos de IA, el manejo de errores es un rasgo de calidad del producto, no un detalle de fondo: un pipeline de newsletter o de auditoría SEO con agentes de investigación, esquema, borrador y revisión se sostiene o se cae con el Verifier-Judge y la etapa de escritura single-threaded. Para los responsables de decisiones B2B en Europa: exige a cada propuesta multiagente, interna o de un proveedor, respuestas concretas sobre su estrategia de timeouts, fallback, verificación y trazas. Un sistema sin una observabilidad del nivel de Galileo o LangSmith no se puede examinar ante un requerimiento del regulador. Quien integra el manejo de errores en la topología de agentes desde el principio, siguiendo el patrón Allianz Nemo con agente de auditoría y human-in-the-loop, entrega sistemas rápidos que a la vez siguen siendo auditables.