Sistemas multiagente: orquestación, contratos de datos y fallos en cascada

Por qué un solo agente deja de bastar

Un agente de inteligencia artificial con cinco herramientas y una tarea clara funciona bien. Dale cuarenta herramientas y una tarea con diez subtareas, y empieza a fallar de formas previsibles:

• Elige mal la herramienta. Cuantas más opciones, más probable que confunda dos parecidas. Y todas sus definiciones ocupan contexto en cada vuelta.
• Pierde el hilo. El contexto se llena de resultados intermedios, y la instrucción original queda enterrada bajo miles de tokens de lo que hizo en el paso 7.
• No se puede probar por partes. Un prompt que tiene que ser a la vez investigador, analista, redactor y revisor no se puede ajustar para una tarea sin romper otra.

La respuesta de la industria es la misma que la de la ingeniería de software desde hace cincuenta años: dividir por responsabilidades. Un agente investiga, otro analiza, otro redacta, y alguien coordina. Eso es un sistema multiagente.

Y como en la ingeniería de software, al dividir el problema no desaparece la complejidad: se muda a las interfaces.

Cuatro formas de organizar agentes

La topología secuencial es un workflow; la del supervisor es el patrón orquestador-trabajadores de los siete patrones de control, con agentes completos en lugar de llamadas sueltas. La red es el agente autónomo multiplicado, y hereda todos sus problemas al cuadrado.

Cómo lo resuelven LangGraph y CrewAI

Los dos marcos más usados parten de ideas distintas sobre qué comparten los agentes, y esa diferencia es la que importa.

LangGraph modela el sistema como un grafo de estados. Hay un estado compartido con un esquema declarado (un TypedDict o un modelo de Pydantic), cada nodo es un agente o una función que lee ese estado y devuelve una actualización parcial, y unas funciones reductoras deciden cómo se combina cada actualización con lo que ya había. El estado se guarda en cada paso, así que se puede inspeccionar, reanudar o rebobinar. Lo que viaja entre agentes no es la conversación: es un objeto con forma conocida.

CrewAI parte de la metáfora de un equipo. Cada agente tiene un rol, un objetivo y un trasfondo; cada tarea declara el resultado que espera, y puede exigir que salga como un modelo de Pydantic en lugar de como texto libre. El proceso puede ser secuencial o jerárquico, con un agente gestor que reparte.

La lección común está en el detalle que los dos acabaron añadiendo: la salida estructurada. Los dos empezaron permitiendo que los agentes se pasaran texto, y los dos ofrecen hoy formas de obligar a que se pasen objetos con esquema. No es casualidad.

La fuga de contexto

Cada agente trabaja con su propio contexto: lo que leyó, lo que dudó, lo que descartó. Al pasar el trabajo al siguiente, solo viaja lo que escribió. La fuga de contexto es lo que se pierde, o lo que se cuela, en ese paso. Ocurre en las dos direcciones.

Lo que no debería llegar. El caso contrario es pasar al siguiente agente la conversación entera del anterior "para que tenga contexto". Entonces le llega todo: las hipótesis descartadas, que puede retomar como si fueran conclusiones; los miles de tokens que diluyen su propia instrucción; y cualquier texto malicioso que el primer agente leyó en una web o un documento, ahora dentro del contexto de un agente que quizá tiene permiso para escribir en tu base de datos.

La prosa libre falla en las dos direcciones a la vez: pierde las dudas y conserva el ruido.

El fallo en cascada, con números

Si cada agente de una cadena acierta con una probabilidad por paso, y cada uno depende del anterior, la probabilidad de que la cadena entera acierte es el producto:

La tabla es optimista en un sentido y pesimista en otro. Pesimista, porque un sistema bien hecho detecta y corrige parte de los errores por el camino. Optimista, porque supone errores independientes, y en un sistema multiagente no lo son: el agente B confía en el agente A. No tiene forma de saber que la cifra que recibe salió de una inferencia dudosa; la trata como una premisa, construye encima y la devuelve con más aplomo del que tenía. El error no solo se propaga: se amplifica, porque cada salto lo reviste de más elaboración.

Es la misma degradación que formaliza ΛD: en una cadena de inferencias, la certeza del resultado nunca puede superar la de la premisa más débil. Un sistema multiagente que se comunica en prosa no tiene dónde apuntar esa certeza, así que la pierde en el primer salto.

Solución 1: contratos de datos entre agentes

La primera defensa es que los agentes no se hablen en prosa. Cada mensaje entre agentes es un objeto con un esquema estricto, validado en la frontera, igual que validarías la entrada de una API pública.

Pero no cualquier esquema. El error habitual es tipar solo el dato:

// Tipa la sombra, no el objeto: la duda sigue sin sitio.
const Hallazgo = z.object({
  licencias: z.number(),
  plan: z.enum(["basico", "pro", "enterprise"]),
});

Un contrato útil entre agentes tipa también cuánto se sabe y de dónde sale, y da un lugar explícito a lo que no se sabe:

const Hallazgo = z.object({
  licencias: z.object({
    valor: z.number().int().nonnegative().nullable(),
    estado: z.enum(["verificado", "inferido", "desconocido"]),
    evidencia: z.array(z.object({ fuente: z.string(), cita: z.string() })),
  }),
  plan: z.object({
    valor: z.enum(["basico", "pro", "enterprise"]).nullable(),
    estado: z.enum(["verificado", "inferido", "desconocido"]),
    evidencia: z.array(z.object({ fuente: z.string(), cita: z.string() })),
  }),
  contradicciones: z.array(z.string()),
  pendiente: z.array(z.string()),
});

Con este contrato, el agente de facturación puede tener una regla que no depende de su buen juicio: no se factura sobre un campo inferido. Un desconocido con valor: null es un resultado legítimo, no un fallo; el esquema viejo obligaba a inventar un número.

Las salidas estructuradas de los proveedores de modelos, que restringen la generación para que el JSON cumpla el esquema, garantizan la parte sintáctica. Si el objeto no valida, se rechaza en la frontera y se le devuelve al agente el error concreto para que lo corrija, con un número máximo de reintentos. Nunca se "arregla" a mano el JSON a medio camino.

Solución 2: agentes con verificador

Un contrato garantiza que el mensaje tiene la forma correcta. No garantiza que sea verdad. Para eso se pone un verificador en la frontera: un paso independiente que tiene que aprobar el mensaje antes de que pase al siguiente agente.

agente A → mensaje → [esquema] → [verificador] → ¿aprobado? → agente B
                         │              │
                         └── rechazo con motivo concreto → agente A (máx. 2)
                                        └── tras 2 rechazos → persona

El verificador trabaja por capas, de la más barata a la más cara:

1. Comprobaciones deterministas. Que cada campo verificado tenga al menos una evidencia, que las cifras cuadren entre sí, que las fechas estén en su rango. Código, sin modelo.
2. Contraste con la fuente. Que la cita de cada evidencia aparezca de verdad en la fuente que dice. También código, casi siempre.
3. Un modelo juez. Solo para lo que no se puede comprobar con código: si la evidencia de verdad sostiene la afirmación.

La palabra que importa es independiente. Un verificador que recibe el mismo contexto que el agente al que revisa hereda sus mismos sesgos: leerá lo mismo y concluirá lo mismo. El verificador recibe el mensaje, las fuentes y los criterios. No recibe el razonamiento del agente.

Solución 3: límites que detienen la cascada

• Estado explícito, no conversación. Lo que comparten los agentes es un objeto versionado, como el estado de LangGraph, no un historial de chat que crece.
• Trazabilidad. Cada mensaje lleva quién lo produjo y a partir de qué mensajes. Cuando algo sale mal, se puede seguir el error hasta su origen.
• Cortafuegos. Un máximo de saltos entre agentes, de reintentos por frontera y de gasto por tarea. Al alcanzarlo, el sistema se detiene y escala a una persona, en lugar de seguir produciendo con aplomo.

Lo que el contrato no arregla

Hay que decirlo, porque es el argumento que yo mismo me hago en En defensa de JSON: un campo estado: "verificado" que el modelo rellena porque suena bien sigue siendo una invención, ahora con un tipo encima. Un esquema dibuja la sombra con más detalle; sigue siendo una sombra. Es la tesis de JSON es la caverna de Platón, aplicada a agentes.

Por eso las dos soluciones van juntas y en este orden. El contrato hace que la duda tenga un sitio donde escribirse y que nadie pueda ignorarla sin romper la validación. El verificador comprueba que lo escrito ahí se sostiene. Un contrato sin verificador produce mentiras bien tipadas. Un verificador sin contrato tiene que adivinar qué está verificando.

Los agentes que se hablan en prosa libre funcionan en la demo. Los que funcionan en producción se hablan en estructuras que dicen qué saben, qué suponen y qué ignoran, y tienen a alguien independiente comprobándolo en cada frontera.

Para llevarte

• Dividir un agente en varios reduce la complejidad de cada uno y la traslada a las interfaces entre ellos.
• La prosa entre agentes pierde las dudas y conserva el ruido: es la fuga de contexto.
• Los errores en una cadena de agentes no se suman: se multiplican, y además se amplifican, porque cada agente confía en el anterior.
• La defensa es doble: contratos tipados que den sitio a la incertidumbre, y verificadores independientes en cada frontera. Uno sin el otro no alcanza.