Ahora la orquestación es la arquitectura

La vez pasada argumenté que deberías dividir el god-agent (agente-dios) en agentes pequeños y enfocados que hagan una sola cosa bien, y terminé con una trampa: hacer eso no elimina tu problema, lo cambia por uno nuevo. Ahora tienes diez agentes que tienen que trabajar juntos, y lograr que lo hagan resulta ser más difícil que cualquier cosa con la que un solo agente estaba batallando.

Esa coordinación es el tema de este post, porque la forma en que la mayoría de los equipos la manejan es la razón silenciosa por la que sus sistemas multiagente se vienen abajo.

La coordinación no es la plomería. Es el sistema.

Cuando la gente construye un montaje multiagente, piensa en los agentes como el sistema y en el cableado entre ellos como plomería: conectas las salidas a las entradas y listo. Eso está al revés. Una vez que el trabajo se reparte entre especialistas, los agentes son la parte fácil. Ahora la coordinación es la arquitectura, y es la parte que casi nadie diseña a propósito.

Esa capa tiene un nombre: orquestación. Y no es un cable, es un conjunto de responsabilidades reales: descomposición de tareas, enrutamiento, gestión de estado, agregación de resultados, y manejo de errores y escalamiento. La forma dominante en producción es el patrón orchestrator-worker (orquestador-trabajador), alrededor del 70% de los despliegues, donde un modelo capaz recibe la tarea, la desglosa, despacha cada pieza a un worker / trabajador especialista barato, y arma los resultados. (Esa división, un planificador inteligente sobre ejecutores baratos, es también de donde proviene buena parte del ahorro de costos: 40–60% en los casos reportados.) Ese orquestador no es pegamento. Es el componente más importante que vas a escribir.

Es un sistema distribuido, y falla como uno

Aquí está el cambio mental que vuelve tratable todo el asunto: un sistema multiagente es un sistema distribuido. Componentes independientes, que pasan mensajes, que mantienen estado, que fallan parcialmente. Y en el momento en que lo ves así, sus aterradores modos de falla dejan de ser misteriosos "problemas de IA" y se convierten en los clásicos problemas de sistemas distribuidos que ya conoces:

• Cascadas. Un agente alucina, le entrega su respuesta equivocada al siguiente como si fuera un hecho, y el error se compone a lo largo de la cadena: un mensaje corrupto propagándose por una tubería.
• Bucles descontrolados. Dos agentes se pasan una tarea de ida y vuelta, o uno reintenta para siempre, inflando silenciosamente tu factura de API: un reintento sin límite con el taxímetro corriendo.
• Pérdida silenciosa de mensajes. Un traspaso (handoff) desborda una ventana de contexto, información crítica se trunca sin que nadie lo note, y un agente río abajo actúa sobre medio mensaje: paquetes perdidos, sin que se levante ningún error.
• Escalamiento muerto. La ruta de "escalar a un humano" que todos diseñaron y nadie probó nunca se dispara de verdad: el manejador de errores que nunca estuvo en el happy path (camino feliz).

Esto no es fragilidad hipotética. Se ha medido que los sistemas multiagente fallan en producción a tasas entre el 41% y casi el 87%, con las rupturas de coordinación por sí solas representando el 36.9% de todas las fallas: no es que los modelos sean tontos, es que la coordinación está sin gestionar. La solución es traer la disciplina que los modos de falla están pidiendo a gritos: contratos explícitos entre agentes, bucles y reintentos acotados, estado que puedas observar, y rutas de error y escalamiento que de verdad ejercites. Los problemas de sistemas distribuidos quieren respuestas de sistemas distribuidos.

No recurras a ella hasta que puedas nombrar el cuello de botella

Hay una segunda trampa, lo opuesto a tratar la coordinación como plomería: recurrir a lo multiagente porque suena poderoso. Es poderoso, y es caro. La coordinación tiene un costo real: los sistemas multiagente pueden quemar 15× los tokens de una interacción de un solo agente, más un gran sobrecosto solo por andar moviendo el estado de un lado a otro. El sueño de 2024 de que "más agentes = más inteligencia" murió en su mayoría en producción.

El consenso que lo reemplazó, en el que cinco grandes proveedores — Anthropic, OpenAI, Cognition, LangChain, AutoGen — convergieron, es una regla útil: la carga de la prueba recae sobre lo multiagente, no sobre el agente único. Empieza con un agente. Agrega otro solo cuando puedas nombrar el cuello de botella específico que lo obliga: aislamiento de dominio, trabajo genuinamente paralelo, una frontera de cumplimiento. "Se siente más sofisticado" no es un cuello de botella. Cada agente que agregas compra capacidad y la paga en coordinación, y ese intercambio solo vale la pena cuando algo concreto lo exige.

La verdadera falla es hacerlo por accidente

Junta las dos trampas y el problema real entra en foco. La mayoría de los equipos no deciden construir un sistema multiagente; lo hacen crecer. Le pegan un agente a otro agente para tapar un hueco, luego otro, y la orquestación emerge de forma implícita: ningún patrón elegido, ningún contrato, ningún manejo de fallas, solo cableado acumulado que nadie diseñó. Así es exactamente como terminas en la columna del 86%. Las consultas sobre sistemas multiagente se han disparado, pero la coordinación está en su mayoría improvisada, y los sistemas distribuidos improvisados fallan.

La solución no es un framework. Es una postura: trata la orquestación como un artefacto de diseño de primera clase. Decide el patrón a propósito. Escribe el contrato que cada agente honra. Decide qué pasa cuando un paso entra en bucle, se trunca o falla, antes de que ocurra. El orquestador merece el mismo diseño deliberado que le darías a cualquier sistema crítico, porque eso es lo que es.

Cuando construir se volvió barato y dividiste el trabajo en especialistas, no eliminaste la arquitectura: la reubicaste. Antes vivía dentro del prompt de un solo agente; ahora vive en la coordinación entre muchos. Diseña esa coordinación como el sistema distribuido que es, a propósito, o mírala fallar como uno que fingiste que era solo plomería.