Orquestación de IA multiagente y controles de supervisor

Un agente de IA individual que da la respuesta correcta el 85 % de las veces suena bien, hasta que encadenas cinco y tu tasa de éxito de extremo a extremo cae al 44 %, o encadenas diez y aterrizas en el 20 %. Esta matemática del fallo acumulativo es lo que mata los proyectos multiagente después de que superan la fase de demostración, y la causa casi nunca son los modelos deficientes. Es la orquestación no gobernada. Nuestro enfoque consiste en construir sistemas multiagente donde la capa de orquestación es el producto, gobernada por un supervisor determinista en lugar de otro LLM que puede ser confundido o vulnerado.

El problema de fiabilidad multiagente del que nadie te advierte

La matemática acumulativa anterior es el modo de fallo que solo aflora después de que un sistema abandona la demostración. Un estudio que analizó 1642 trazas de ejecución en siete marcos de agentes de código abierto encontró tasas de fallo de entre el 41 % y el 86,7 %, con desgloses de coordinación que representan el 36,9 % de todos los fallos. Gartner prevé que más del 40 % de los proyectos de IA agéntica se cancelarán para 2027, y la causa principal no son los modelos deficientes: es la orquestación no gobernada.

En los sistemas que diseñamos, el supervisor es un motor de políticas determinista, no otro LLM que pueda ser confundido o vulnerado. Cada agente opera dentro de una envolvente especificada formalmente: esquemas de entrada/salida definidos, acceso permitido a herramientas, presupuestos de tokens, cuotas de llamadas a la API y límites de tiempo de ejecución. El supervisor valida cada acción del agente contra estas restricciones antes de que surta efecto. Esto no es «añadir guardrails»: es hacer que el comportamiento inseguro sea arquitectónicamente imposible en la capa de coordinación, el enfoque que detallamos en nuestra investigación sobre cómo arquitecturar la verdad más allá del envoltorio del LLM.

Por qué los marcos por sí solos no te llevan hasta allí

El panorama de los marcos multiagente en 2026 es un campo minado de promesas incumplidas, y las diferencias no son cosméticas: son la diferencia entre un sistema que funciona y uno que falla silenciosamente o gasta de más.

Incluso LangGraph, la opción más viable para producción, presenta aristas afiladas: su ToolNode por defecto no puede manejar herramientas que necesiten leer o escribir en el estado del grafo, requiere contadores de bucle manuales para evitar ciclos de autocorrección descontrolados, y sus implementaciones de checkpointer tienen dificultades con la resolución concurrente de ramas a escala. Estos son problemas resolubles, pero requieren el tipo de ingeniería que el README de un marco no cubre.

Evaluamos los marcos frente a tus requisitos reales —presupuesto de latencia, número de agentes, complejidad de las herramientas, necesidades de cumplimiento— y luego construimos la capa de orquestación que se sitúa por encima del marco, proporcionando los controles del supervisor, la gobernanza de costes y la observabilidad que ningún marco ofrece de fábrica: la capa de orquestación resiliente descrita en nuestro whitepaper sobre cómo arquitecturar una IA empresarial resiliente.

Lo que hace realmente el supervisor

El patrón al que recurrimos es la orquestación determinista con razonamiento LLM en los bordes. Los LLM se encargan del juicio: interpretar la intención, extraer parámetros estructurados, decidir qué agente especialista invocar. Una máquina de estados gestiona el flujo: enrutamiento, secuenciación, distribución paralela, agregación por consenso y recuperación ante errores. La validación de Pydantic captura cada transferencia entre agentes en cargas útiles tipadas y con esquema forzado, de modo que no pasa ningún texto de forma libre entre agentes, lo que elimina los vectores de inyección de prompts y la deriva semántica que aquejan a las arquitecturas de agentes basadas en chat.

El supervisor está diseñado para aplicar cuatro clases de control:

• Presupuestos de recursos por agente — límites de tokens, cuotas de llamadas a la API, tiempos de espera de reloj de pared.
• Restricciones de acceso a herramientas por agente — directorios del sistema de archivos, endpoints de red, ámbitos de base de datos.
• Puertas de aprobación de acciones para operaciones de escritura que afectan a sistemas externos.
• Disyuntores de coste que detienen la ejecución cuando se cruzan los umbrales de gasto.

SLO recomendados para un sistema gobernado: tasa de éxito superior al 95 %, latencia de transferencia inferior a 30 segundos y fidelidad de llamadas a herramientas superior al 80 %.

Desastres documentados, hechos prevenibles

Estos controles están diseñados para convertir catástrofes bien conocidas en incidentes detectados en minutos, el mismo enfoque de seguridad determinista en acción en una demostración funcional de nuestros controles de seguridad deterministas:

• La factura de la API de 47 000 $ de un bucle de agente recursivo de 11 días, detectada por un techo de gasto de tokens más la detección semántica de bucles (un umbral de similitud del 95 % entre salidas consecutivas) en minutos, no en días.
• El incidente de autoescalado de 60 000 $/mes donde los agentes provocaron un salto de 12 a 500 nodos, detenido por puertas de acción de infraestructura que exigen la aprobación del supervisor antes de que se ejecuten los comandos de escalado.
• Los 6,3 millones de pedidos perdidos de Amazon por un agente que seguía una guía desactualizada del wiki, evitados mediante la validación de la frescura de la fuente y la aplicación del corte de conocimiento en las comprobaciones previas a la acción del supervisor.

Observabilidad que rastrea los fallos a través de las fronteras entre agentes

El problema de depuración más difícil en los sistemas multiagente es que los fallos tienen forma de grafo: una alucinación en la llamada a herramienta del Agente A se convierte en el contexto de entrada del Agente B, que se convierte en la salida segura pero errónea del Agente C. La monitorización tradicional ve fallar al Agente C y no tiene ni idea de que la causa raíz está dos saltos aguas arriba. Diseñamos una observabilidad que visualiza las interacciones entre agentes como grafos acíclicos dirigidos con procedencia completa en cada nodo. Cada mensaje entre agentes, invocación de herramienta, transición de estado y decisión del supervisor se registra con vínculos causales, de modo que cuando algo se rompe rastreas hacia atrás desde el síntoma hasta la acción del agente que lo originó en segundos, no en horas.

Nos integramos con Langfuse, LangSmith o Arize según tu stack, y añadimos instrumentación personalizada para las métricas que estas plataformas no capturan de forma nativa:

• Atribución de tokens entre agentes — qué agente está consumiendo tu presupuesto.
• Ratio de sobrecarga de coordinación — qué parte de tu gasto son agentes hablando entre sí frente a hacer trabajo real.
• Frecuencia de intervención del supervisor — con qué frecuencia la capa determinista anula el comportamiento de los agentes.

La pila de protocolos: MCP, A2A y lo que hay entre ellos

El Model Context Protocol de Anthropic (97 millones de instalaciones para marzo de 2026, ahora bajo la Linux Foundation) estandariza cómo se conectan los agentes a herramientas externas. El protocolo Agent2Agent de Google gestiona la colaboración entre agentes de distintos proveedores con más de 50 socios del sector. AWS Bedrock ofrece alojamiento multiagente gestionado con enrutamiento jerárquico de supervisor. Estas son capacidades reales, no vaporware.

Pero ninguno de ellos proporciona la capa de gobernanza. MCP define el acceso a las herramientas, no la autorización de herramientas por agente. A2A define la mensajería entre proveedores, no la presupuestación de costes ni la aprobación de acciones. El supervisor de Bedrock enruta tareas pero no aplica restricciones deterministas sobre el comportamiento de los agentes. La brecha entre «los agentes pueden hablar con las herramientas y entre sí» y «los agentes operan bajo una orquestación gobernada, auditable y con costes controlados» es donde vive nuestra ingeniería personalizada, el trabajo de sistemas profundos que exponemos en nuestra investigación sobre cómo cruzar la brecha de la IA generativa desde los envoltorios hasta los sistemas de IA profundos.

Cuándo el multiagente es la arquitectura equivocada

Te diremos que no construyas un sistema multiagente si un único agente gestiona tu carga de trabajo. La propia guía de Microsoft es directa: «Opta por defecto por un único agente. Introduce una arquitectura multiagente solo cuando tengas pruebas de que la complejidad adicional aporta un valor proporcional». Los agentes individuales responden entre un 30 % y un 50 % más rápido sin la sobrecarga entre agentes, y los sistemas multiagente alcanzan el punto de equilibrio del ROI entre 8 y 14 meses más tarde que las soluciones de un solo agente.

Un único agente bien construido es la mejor inversión cuando:

• Tu tarea se resuelve en una única pasada lógica.
• Tu volumen es inferior a 10 000 operaciones diarias con un crecimiento predecible.
• Necesitas registros de auditoría sencillos con un aislamiento claro de los errores.

El multiagente justifica su complejidad cuando tienes capacidades genuinamente distintas que requieren diferente acceso a herramientas, diferentes elecciones de modelo o diferentes presupuestos de latencia; cuando necesitas ejecución paralela en subtareas independientes; o cuando agentes especialistas con conjuntos de habilidades reducidos y bien probados superan a un único agente con un prompt sobrecargado. El marco de decisión importa más que la elección tecnológica, y lo aplicamos antes de escribir cualquier código de orquestación.

Lo que entregamos

Un compromiso se define para producir:

• Una evaluación de marcos frente a tus requisitos específicos, no un cuadro comparativo genérico.
• Una arquitectura de supervisor con especificaciones de políticas deterministas que tu equipo de cumplimiento puede revisar.
• Aislamiento (sandboxing) por agente con controles de acceso a herramientas y presupuestos de recursos.
• Gobernanza de costes con techos de gasto de tokens y disyuntores.
• Instrumentación de observabilidad con trazado causal entre agentes.
• Un entorno de simulación para probar flujos de trabajo multiagente con inyección de fallos.
• Runbooks operativos para los escenarios de fallo documentados en producción: cascadas de tiempos de espera de agentes, salidas en conflicto, agotamiento de recursos, violaciones de políticas del supervisor y los bloqueos de coordinación que los marcos no documentan.

Construir un sistema multiagente internamente lleva de 6 a 18 meses y alrededor de 500 000 $ en salarios de ingeniería sénior antes de tener una capa de orquestación de nivel productivo. Nuestro enfoque comprime eso a semanas de arquitectura y construcción, aprovechando los modos de fallo de los marcos catalogados anteriormente en lugar de redescubrirlos a tu costa.