Sistemas multi-agente: 4 evaluaciones que evitan fallos

El 62% de las organizaciones ya experimenta con agentes de IA, pero solo el 23% logró escalar un sistema agéntico en alguna parte de su operación, según la investigación de McKinsey recogida por Analytics Insight. La brecha no se explica por la calidad del modelo: se explica por lo que ocurre entre los agentes.

Shuhua Xu, lead data engineer, plantea el problema con precisión en VentureBeat: en un sistema multi-agente cada agente puede ser correcto por separado y el conjunto producir un resultado equivocado. La salida de un agente se convierte en el contexto del siguiente. Si la información se pierde, se malinterpreta o se arrastra, el error viaja por todo el flujo.

Por qué un multi-agente falla aunque cada agente acierte

La incertidumbre de los LLM no desaparece al repartir el trabajo. Un agente genera información, otro la consume e interpreta, y su salida se convierte en el contexto del siguiente. Cualquier contenido falso o mal interpretado se propaga y se amplifica. Mirar a cada agente por separado, o revisar solo la respuesta final, no dice nada sobre si la colaboración funcionó.

El enfoque que propone Xu es tratar al multi-agente como un sistema RAG, donde se evalúa el trayecto y no únicamente el resultado:

Consulta del usuario → agente A → handoff → agente B → estado compartido → agente C → verificación → salida final

La ganancia potencial está documentada. Un análisis publicado en Forbes por Dhruv Roongta, CTO de la startup Slashy, señala que el sistema de investigación multi-agente de Anthropic superó al enfoque de un solo agente en un 90,2%, pero que esos sistemas consumen 15 veces más tokens que una interacción de chat. Más capacidad y más superficie de fallo, al mismo tiempo.

¿Cómo se detecta un deadlock o un loop infinito?

Un multi-agente es un flujo distribuido donde cada agente espera información, aprobación o acción de otro. Como esas dependencias suelen expresarse a través de decisiones del LLM y no de lógica fija, el sistema puede entrar en estados donde nadie avanza:

• Deadlock: dependencias circulares. El orquestador espera el resultado del worker y el worker espera instrucciones del orquestador.
• Livelock: los agentes siguen interactuando sin progresar. Un agente de conocimiento pide aclaración al agente de transacciones y el de transacciones devuelve la consulta porque falta la misma aclaración.

Estos fallos son propiedades del grafo de ejecución, no de un agente aislado. Xu propone medir el trace completo con tres familias de métricas: progresión (tasa de finalización, tiempo de ejecución, iteraciones promedio), coordinación (tasa de deadlocks, tasa de loops infinitos, handoffs promedio) y terminación (tasa de terminación válida, iteraciones máximas alcanzadas, workflows abandonados).

¿Cómo se evalúa el handoff entre agentes?

Cada traspaso de información es un pequeño pipeline. Cuando el agente A entrega un resultado al agente B hay tres capas que revisar: calidad del contexto transferido, interpretación downstream e integridad de la interfaz.

• Calidad de contexto: context precision, context recall y context relevance, las mismas métricas que se usan en RAG, aplicadas al límite entre agentes.
• Interpretación downstream: faithfulness, output relevancy y response correctness. Aquí el patrón habitual es un LLM como juez que compara la salida upstream, el contexto recibido y el resultado final.
• Integridad de interfaz: schema validity rate, completitud de campos obligatorios, type validation rate y handoff success rate.

La recomendación operativa es que los agentes intercambien salidas estructuradas (JSON Schema, modelos Pydantic u otro contrato tipado) en lugar de texto libre. Así parte del handoff se valida de forma determinista antes de que el agente siguiente ejecute nada.

Los proveedores de modelos coinciden en el diagnóstico. OpenAI advierte en su guía de evaluación, citada por InfoWorld, que el triaje y los handoffs introducen una nueva fuente de no determinismo. Es el mismo punto: el handoff no es un detalle de implementación, es una interfaz que hay que validar.

¿Qué es la monocultura de modelo y por qué te deja ciego?

Cuando todos los agentes corren sobre el mismo modelo fundacional comparten patrones de razonamiento y los mismos puntos ciegos. Un agente planificador llega a una conclusión plausible pero errónea, y un revisor construido sobre el mismo modelo la refuerza en lugar de detectarla. Todos los agentes rinden bien y el sistema está sistemáticamente equivocado.

La forma de medir esta correlación de razonamiento es observar la diversidad real: diversidad de salida (similitud coseno de embeddings, BERTScore), de razonamiento, de herramientas usadas, de evidencia recuperada y de decisiones. La más importante es la correlación de fallos: si varios agentes fallan una y otra vez en los mismos casos, su diversidad aparente no protege de nada. Un sistema sano muestra patrones de fallo complementarios, donde un agente detecta o compensa el error de otro.

La traducción a arquitectura es concreta: asigna modelos distintos según la responsabilidad. Un agente router o de triaje rápido y barato, un agente de conocimiento fuerte en comprensión de contexto, un agente de transacción con mayor capacidad de razonamiento y un revisor de otra familia de modelos. La selección debería ser empírica, con un dataset de evaluación por tarea y métricas comparables de precisión, fidelidad, éxito en tool calling, latencia y costo.

¿Qué pasa con el estado compartido?

El estado compartido es la memoria de trabajo del flujo: datos del cliente, historial de conversación, resultados intermedios, decisiones y restricciones. A medida que el workflow avanza, ese estado se vuelve obsoleto, contradictorio, incompleto o ruidoso.

Xu propone tratarlo como un checkpoint de un pipeline de datos, con un state manager en el medio: estado previo, ejecución del agente, estado actualizado, evaluación y recién entonces el agente siguiente. Los chequeos son de dos tipos: deterministas (validación de schema, campos inmutables que no deben cambiar, consistencia con reglas de negocio, frescura de los valores, tamaño de contexto) y semánticos, con un LLM evaluador que detecta pérdida de hechos, cambios de significado por resumen o información no respaldada.

Los indicadores que se desprenden son state validation rate, state consistency rate, constraint preservation rate, summary fidelity, stale state rate y crecimiento del contexto.

El radio de impacto semántico: la mirada que falta

HackerNoon aporta el marco que completa el cuadro con el concepto de semantic blast radius: la porción del sistema cuyo razonamiento o decisiones quedan materialmente influidas por una sola pieza de información incorrecta. Ese medio describe el caso de cinco agentes evaluando una migración de base de datos: el agente de compatibilidad se equivoca, los demás heredan el error y el sistema aprueba la migración. Cuatro agentes parecen coincidir.

La lección es que la repetición no es corroboración. Conviene medir profundidad de propagación (cuántos saltos viaja la información), ancho de propagación (cuántos agentes la consumen), diversidad de fuentes, influencia downstream y distancia hasta la verificación independiente. La meta no es cero propagación, sino propagación controlada.

¿Qué significa esto para tu startup?

Si estás llevando agentes de un piloto a producción, el trabajo no está en agregar más agentes sino en hacer observables los límites entre ellos. Cuatro acciones concretas:

• Instrumenta el trace antes de escalar. Registra qué agentes se invocaron y en qué orden, los payloads de cada handoff, las decisiones de routing, las lecturas y escrituras de estado compartido, los reintentos y la latencia, tokens y costo por paso. Sin ese historial sabrás que el resultado falló, pero no dónde se rompió la colaboración.
• Convierte los handoffs en contratos validables. Define esquemas, valida campos obligatorios, tipos y reglas de negocio antes de que el agente siguiente consuma el resultado. Si la validación falla, rechaza el payload, reintenta el agente aguas arriba o desvía el flujo por una ruta alternativa.
• Pon controles deterministas en el orquestador. Máximo de iteraciones, timeouts y condiciones explícitas de terminación, en lugar de dejar que un LLM decida cuándo parar. Representar el workflow como un grafo con estado, con nodos, aristas, ramas y checkpoints, permite además capturar la ejecución para diagnóstico.
• No sumes un agente por reflejo. InfoWorld recuerda que la guía de Anthropic de 2024 sobre cómo construir agentes eficaces recomienda la solución más simple posible, que OpenAI sugiere maximizar primero un solo agente con herramientas y que Microsoft advierte que los roles de planner, reviewer y executor no justifican por sí solos varios agentes. Google suma su propia advertencia sobre el costo de empaquetar un agente como herramienta. Si no puedes nombrar qué problema resuelve el agente adicional, probablemente no lo necesitas.

El contexto de mercado empuja en la dirección opuesta y conviene tenerlo presente. Analytics Insight proyecta que el mercado de IA agéntica pase de US$12.130 millones en 2026 a US$290.620 millones en 2035, con un crecimiento anual compuesto del 42,88%, y que el segmento multi-agente crezca más rápido que el de un solo agente. El mismo informe cita un reporte de Gartner de abril de 2026 según el cual una empresa promedio del Fortune 500 podría estar corriendo más de 150.000 agentes en 2028, frente a menos de 15 en 2025, mientras que solo el 13% de las organizaciones encuestadas consideraba tener un gobierno adecuado sobre ellos.

Conclusión

La meta no es volver determinista a un LLM, sino hacer que su comportamiento impredecible sea visible, medible, acotado y recuperable. Eso se logra con ingeniería en los bordes: interfaces estructuradas que controlan el flujo de información, orquestación que controla la ejecución, un state manager que controla el contexto compartido y una selección de modelos que sostiene la diversidad donde hace falta verificación independiente.

Un founder que despliega agentes sin evaluar la colaboración está confiando en que el sistema se comporte. La alternativa es más barata: medir el trayecto, definir límites explícitos y asumir que algún agente va a equivocarse, con la arquitectura preparada para contenerlo.

Fuentes

• AI agents can be unpredictable. Your control layer shouldn’t be.
• Agentic AI Market Outlook 2026-2035
• Multi-Agent AI Systems: The Architectural Shift Reshaping Enterprise Computing
• Multi-agent AI is the new microservices
• Semantic Blast Radius: How Errors Propagate Through Multi-Agent Systems

Artículos relacionados:

Agentes IA en la empresa: ¿uno por persona o uno por equipo? Sub-Agentes IA: Cómo 3 Especialistas Transforman tu Op IA single-agent vs multi-agent: estudio Stanford revela costo 2-10x Desempleo, agentes 24/7 y la carta de Dario Amodei Anthropic: IA agents en guerra territorial revelan riesgos de sistemas multi-agente