Los sistemas multiagente no fallan solo porque un modelo se equivoque. El estudio MAST encontró problemas recurrentes en la arquitectura, la coordinación entre agentes y la comprobación del resultado. Su versión final analiza 1.642 trazas, define 14 modos de fallo y ofrece una base pública para diagnosticar qué ocurre dentro de un flujo.
Why Do Multi-Agent LLM Systems Fail? fue aceptado en el track de Datasets and Benchmarks de NeurIPS 2025. Sus autores construyeron MAST (Multi-Agent System Failure Taxonomy) y publicaron el código y los datos en GitHub.
Qué estudió MAST exactamente
MAST-Data reúne 1.642 trazas anotadas de siete sistemas multiagente de código abierto, con tareas de programación, matemáticas y uso general de agentes. La taxonomía se construyó primero mediante análisis cualitativo de 150 trazas realizado por seis expertos. Después, el equipo escaló la anotación con un evaluador basado en un LLM y validó su acuerdo frente a anotaciones humanas.
Esto importa para interpretar bien las cifras: MAST describe los fallos observados en esos sistemas, modelos y dominios. Los autores no afirman que la taxonomía sea exhaustiva ni que los porcentajes sean una tasa universal para cualquier empresa.
Los fallos se reparten en tres capas
La versión final del artículo distribuye la prevalencia de los modos de fallo observados en las 1.642 trazas de esta forma:
- 44,2% — Problemas de diseño del sistema. La tarea, los roles, el historial o las condiciones de terminación están mal definidos o se incumplen.
- 32,3% — Desalineación entre agentes. La información no fluye, un agente ignora a otro, la conversación se reinicia o las acciones no coinciden con el razonamiento.
- 23,5% — Verificación de la tarea. El sistema termina antes de tiempo, comprueba de forma incompleta o valida como correcto un resultado que no lo es.
El 55,8% de la prevalencia observada queda fuera del diseño inicial: aparece durante la coordinación o al verificar el resultado. Definir roles es necesario, pero no basta.
Los 14 modos de fallo de MAST
1. Diseño del sistema — cinco modos.
- Incumplir la especificación de la tarea.
- Incumplir la especificación del rol.
- Repetir pasos ya realizados.
- Perder el historial de la conversación.
- No reconocer las condiciones de terminación.
2. Desalineación entre agentes — seis modos.
- Reiniciar la conversación sin necesidad.
- No pedir aclaraciones ante información ambigua o incompleta.
- Desviarse de la tarea.
- Retener información relevante para otros agentes.
- Ignorar la aportación de otro agente.
- Actuar de forma incoherente con el razonamiento expresado.
3. Verificación de la tarea — tres modos.
- Terminar antes de completar los objetivos.
- No verificar o verificar solo una parte del resultado.
- Verificar de manera incorrecta.
El caso ChatDev: una mejora medida de 9,4 puntos
Uno de los experimentos del artículo estudió ChatDev, un sistema que simula roles de una empresa de software. El equipo reforzó las especificaciones de rol, la jerarquía y la regla de que solo los agentes superiores podían cerrar conversaciones; en el flujo, el CEO debía tener la última palabra.
Con el mismo encargo del usuario y GPT-4o, la tasa de éxito en ProgramDev-v0 pasó del 25,0% al 34,4%: una mejora de 9,4 puntos porcentuales. Un cambio posterior de topología, de un grafo acíclico a un flujo cíclico con revisión, llegó al 40,6% en ese conjunto.
El propio artículo presenta estas mejoras con cautela. Ni el prompt reforzado ni el cambio estructural resolvieron todos los fallos. La conclusión útil no es «añade un CEO», sino que una intervención debe medirse en el flujo completo y examinar qué modos de fallo reduce, conserva o desplaza.
Qué puede aplicar una empresa sin copiar el experimento
- Define la autoridad de cierre. Debe existir una regla inequívoca sobre quién puede declarar terminada una tarea.
- Registra el estado. Cada agente tiene que saber qué se ha completado, qué falta y qué evidencia respalda el avance.
- Diseña el traspaso. La entrega debe incluir contexto, resultado, incertidumbres y siguiente criterio de aceptación.
- Verifica con el mecanismo adecuado. Código, documentos, operaciones y decisiones de negocio no se comprueban de la misma forma.
- Mide por trazas, no por impresiones. Un resultado correcto puede ocultar fallos sistémicos, y un fallo final puede originarse varios pasos antes.
MAST es un instrumento de diagnóstico, no una receta
La taxonomía permite nombrar síntomas que suelen mezclarse bajo la etiqueta «el agente se equivocó». Esa precisión ayuda a elegir una intervención: aclarar una tarea, separar herramientas, rediseñar un traspaso, conservar el estado o cambiar la verificación. Para convertirlo en una arquitectura operativa necesitas conectarlo con los procesos, permisos y responsables humanos de tu empresa. Si todavía estás ordenando esa base, consulta el método de organizar, agentizar y escalar antes de añadir más agentes.
La guía central de DÍA UNO sobre orquestación de agentes, personas y procesos explica cómo hacer ese mapa. Si todavía estás decidiendo la arquitectura, consulta también cuándo usar un agente único y cuándo varios.