IBM Research y UC Berkeley aplican una lupa práctica sobre por qué los agentes conversacionales y de automatización fallan en entornos reales de IT. En lugar de quedarnos con un porcentaje de éxito, convierten miles de trazas en señales accionables para que tú, como ingeniero o responsable de producto, sepas exactamente qué ajustar.
Qué hicieron: ITBench + MAST para diagnosticar fallas
Colaboraron para analizar cómo los agentes LLM rompen en tareas de SRE, seguridad y FinOps: triage de incidentes, consultas de logs y métricas, y acciones en Kubernetes dentro de bucles largos con herramientas.
- Anotaron 310 trazas de ITBench SRE producidas por agentes con tres modelos: Gemini-3-Flash, Kimi-K2 y GPT-OSS-120B.
- Usaron MAST (Multi-Agent System Failure Taxonomy) para transformar trazas crudas en vectores de falla estructurados.
- Métrica principal de evaluación usada: recall, porque en runs de SRE los modelos entregan pocas salidas y SREs priorizan recuperar el resultado correcto.
Resultados clave (recall por modelo):
- Gemini-3-Flash: 100 trazas, 75.5% mean recall
- Kimi-K2: 105 trazas, 28.6% mean recall
- GPT-OSS-120B: 105 trazas, 12.4% mean recall
Qué es MAST y por qué importa
MAST no es solo otra métrica. Es una taxonomía que clasifica fallas en 14 patrones agrupados en 3 categorías principales:
- FC1: System Design Issues - 'el esqueleto' (ej.
FM-1.3Step Repetition,FM-1.4Loss of Conversation History,FM-1.5Unaware of Termination) - FC2: Inter-Agent Misalignment - 'la comunicación' (ej.
FM-2.2Fail to Ask for Clarification,FM-2.6Action-Reasoning Mismatch) - FC3: Task Verification - 'control de calidad' (ej.
FM-3.1Premature Termination,FM-3.3Incorrect Verification)
La ventaja: MAST no te dice solo que un agente falló; te dice qué falló, dónde, y qué intervención tiene más palanca.
Hallazgos técnicos por modelo y sus firmas de falla
- Perfil de Gemini-3-Flash: fallas "quirúrgicas"
- Densidad: ~2.6 modos de falla por traza fallida.
- Patrón: coherencia interna alta; falla por cuellos aislados, especialmente
FM-3.3Incorrect Verification. - Diagnóstico: el modelo tiende a "declarar victoria" sin evidencia externa.
- Ingeniería recomendada: externalizar la verificación. No dejes que el LLM se califique a sí mismo; exige evidencia de herramientas (por ejemplo, clearance de AlertManager o cambios observables en el estado de K8s) antes de terminar.
- Nota práctica: las mejoras por prompt engineering son limitadas. En el análisis citado, ajustes de prompt dieron ~15.6% de mejora, mientras que introducir agentes auxiliares o control de estado (summarizer + state machine) llegó hasta ~53%.
- Perfil de Kimi-K2: el problema es terminar y ejecutar correctamente
- Densidad: ~4.7 modos de falla por traza fallida.
- Patrones dominantes:
FM-1.5Unaware of Termination Conditions yFM-2.6Action-Reasoning Mismatch (92% de fallas con este modo). - Sintomatología: el modelo sobre-razona pero falla al ejecutar, o termina prematuramente o entra en bucles meta de depuración.
- Ingeniería recomendada: sacar la decisión de terminación del modelo. Implementa una máquina de estados determinista, detectores de bucle para llamadas repetidas a herramientas, y reglas claras de stop.
- Perfil de GPT-OSS-120B: colapso en cascada por pérdida de contexto
- Densidad: ~5.3 modos de falla por traza fallida.
- Patrones críticos:
FM-1.4Loss of Conversation History (24% de trazas), yFM-2.6Reasoning-Action Mismatch (94%). - Diagnóstico: pequeñas discrepancias tempranas en el razonamiento envenenan la historia de la tarea y causan deriva total.
- Ingeniería recomendada: higiene agresiva de contexto, detección temprana de errores y mecanismos que reconstruyan o refuercen el estado antes de que el agente siga.
Lecciones generales y acciones concretas
- No dejes que el LLM sea árbitro de su propio éxito: externaliza verificación con pruebas de herramienta.
- Controla la terminación fuera del modelo: añade condiciones explícitas de stop, detectores de loops o máquinas de estados.
- Maneja la ambigüedad como rama explícita de la política: fuerza 'clarify-or-read-only' cuando la entrada sea ambigua. Evita que el agente haga suposiciones.
- Agentes auxiliares ayudan: un Summarizer Agent o un State Manager que actualice el contexto puede subsanar
FM-1.4y mejorar sustancialmente el rendimiento. - Distingue fallas benignas de fatales: no todas las repeticiones o verificaciones pobres matan la tarea. En cambio, pérdida de memoria, prematura terminación o falta de aclaración suelen ser fatales.
Cómo esto cambia tu evaluación de agentes
Si construyes agentes para flujos de trabajo empresariales, quieres más que un número de éxito. Necesitas un mapa de fallas que te indique dónde meter ingeniería para obtener el mayor retorno. MAST aplicado a ITBench hace justo eso: transforma trazas en prioridades de corrección.
Recomendaciones rápidas para equipos de producto e ingeniería
- Para modelos tipo Frontier (ej. Gemini): implementa gates de verificación externos antes de marcar éxito.
- Para modelos intermedios (ej. Kimi-K2): aplica una máquina de estados y detectores de bucle; reduce cadenas de razonamiento redundantes.
- Para modelos abiertos grandes (ej. GPT-OSS-120B): invierte en gestión de contexto y checkpoints periódicos que prevengan el olvido progresivo.
Recursos y lectura técnica
- ITBench paper: https://arxiv.org/pdf/2502.05352
- ITBench code: https://github.com/itbench-hub/ITBench
- MAST paper: https://arxiv.org/abs/2503.13657
- MAST code: https://github.com/multi-agent-systems-failure-taxonomy/MAST
- MAST-Data (1600+ trazas): disponible en Hugging Face y repositorios asociados
La conclusión práctica es simple: medir es útil, diagnosticar es indispensable. Si quieres agentes que funcionen en producción, no optimices solo por tasa de éxito; prioriza herramientas que te digan por qué y cómo arreglar las fallas.