Primero fue un agente para generar código. Después otro para revisar las pull requests. Un tercero para documentar. Y antes de que te dieras cuenta, tienes cinco asistentes de IA trabajando en el mismo repositorio sin hablarse entre ellos, cada uno con su propio contexto, sus instrucciones y una opinión distinta sobre lo que significa “correcto”.

Este es el problema que nadie te cuenta cuando empiezas con agentes de IA: el cuello de botella dejó de ser la calidad de un solo modelo. Ahora es coordinar a muchos.

El problema: agentes que no se hablan

Cuando trabajas con un solo agente, el prompt lo es todo. Cuando trabajas con varios, el diseño del sistema lo es todo. Los síntomas del desorden multi-agente son fáciles de reconocer:

  • Contexto fragmentado: cada agente sabe una parte de la historia, ninguno tiene la visión completa del proyecto.
  • Trabajo duplicado: dos agentes reimplementan la misma utilidad porque ninguno sabe que el otro ya la hizo.
  • Resultados inconsistentes: el agente A refactoriza una función mientras el agente B la está reescribiendo desde cero.
  • Costo descontrolado: cada agente llama al modelo sin saber qué ya resolvieron los demás, y el presupuesto de tokens se dispara.
  • Cero trazabilidad: cuando algo sale mal, no puedes reconstruir quién llamó a quién, con qué input y por qué.

La solución no es usar un agente “más inteligente”: es diseñar un sistema donde cada agente tenga un rol claro, un contexto acotado y una forma definida de comunicarse. Eso es orquestación.

“Con un agente, el prompt lo es todo. Con varios, el diseño del sistema lo es todo.”

Los 4 patrones de orquestación

Antes de elegir herramienta, hay que elegir patrón. La mayoría de los sistemas multi-agente en producción se reducen a cuatro formas de coordinarse.

1. Orchestrator-Worker (orquestador-trabajador)

Un agente central descompone la tarea en subtareas, las delega a agentes especializados y consolida los resultados. Es el patrón más común por una razón: es simple de razonar.

La clave está en la división de responsabilidades: el orquestador no hace el trabajo pesado, solo coordina. Los workers tienen un alcance acotado y un contrato claro de entrada y salida. Ejemplo clásico: un agente “líder de producto” que convierte un feature en tickets, delega la implementación, la revisión y consolida el resultado final.

2. Pipeline (cadena)

Cada agente recibe el output del anterior. Es lineal, predecible y perfecto cuando las etapas están bien definidas: análisis → diseño → implementación → tests → documentación.

Su debilidad es obvia: si una etapa falla, todo se detiene. Por eso en producción casi nunca lo ves puro; se combina con reintentos, timeouts y saltos condicionales (si no hay tests que escribir, el pipeline salta esa etapa).

3. Jerárquico (árbol)

Un orquestador raíz delega en sub-orquestadores, que a su vez delegan en workers. Es la versión escalable del patrón 1, para problemas grandes con descomposición en varios niveles: un equipo de agentes para el backend, otro para el frontend, otro para infraestructura, todos bajo un coordinador general.

4. Event-driven (eventos)

Los agentes no se llaman entre sí: publican eventos en un bus y los demás se suscriben. Es el patrón más flexible y, honestamente, el más difícil de depurar. Brilla cuando el flujo no es predecible: un agente de monitoreo detecta una caída, publica el evento, y un agente de diagnóstico suscrito arranca la investigación sin que nadie lo invoque.

Herramientas para orquestar

Con el patrón claro, la elección de herramienta se vuelve más fácil:

  • LangGraph: grafos de estado con nodos, aristas y condiciones. El más controlable cuando necesitas ciclos y ramas.
  • CrewAI: coordinación basada en roles (role, goal, backstory). Ideal para prototipar rápido y validar el diseño.
  • AutoGen: conversaciones entre agentes que negocian y resuelven problemas colaborativamente.
  • Temporal o durable execution: la opción seria para producción. Garantiza que el flujo sobreviva a crashes, reintentos y timeouts.
  • MCP (Model Context Protocol): estandariza cómo los agentes acceden a herramientas y datos compartidos. No orquesta flujos, pero resuelve el problema de “cada agente se conecta a las herramientas a su manera”.

La regla práctica: prototipa con CrewAI o LangGraph, pero en producción piensa en durabilidad y observabilidad desde el día uno.

Ejemplo completo: triaje automático de issues

Pongamos todo junto con un caso real: un repositorio open source que recibe decenas de issues por semana, con cinco agentes:

  • Agente A (triage): lee el issue nuevo, lo clasifica (bug, feature, pregunta) y le asigna severidad.
  • Agente B (repro): reproduce el bug en un sandbox aislado y genera logs.
  • Agente C (fix): con los logs del agente B, propone un parche.
  • Agente D (review): revisa el parche contra los estándares del repo.
  • Agente E (docs): actualiza la documentación si el fix cambia el comportamiento público.

El flujo combina orquestador y pipeline con un loop:

  1. El orquestador recibe el webhook del issue y delega al agente A.
  2. Si A clasifica “bug reproducible”, el flujo pasa a B; si es una pregunta, se responde directo y se cierra.
  3. B produce logs → C propone el parche → D lo revisa.
  4. Si D rechaza, el flujo vuelve a C con el feedback del reviewer (aquí es donde un pipeline lineal se rompe y un grafo con ciclo funciona).
  5. Al final, el orquestador consolida todo: publica la respuesta en el issue, abre el PR y actualiza el tracking.

Lo que hace robusto a este sistema:

  • Contexto acotado: no le pasas el repo completo a todos. B solo ve el issue y el entorno de repro; C solo ve los logs.
  • Estado compartido persistente: los resultados intermedios viven en una base de datos, no en el prompt. Cualquier agente puede retomar el trabajo de otro.
  • Flujo reanudable: si el paso de repro falla, se reintenta con backoff. No se reinicia todo el sistema.

Errores que te van a costar caro

  • Pasarle el contexto completo a todos los agentes: costo exponencial y respuestas genéricas. Acota.
  • Confundir agentes con funciones: una llamada a la API de un LLM no es un agente. Un agente tiene estado, decisiones y un ciclo de vida.
  • Saltarse la observabilidad: sin tracing de quién llamó a quién y con qué input, depurar un sistema multi-agente es adivinar.
  • Olvidar los límites de costo: cada roundtrip entre agentes es una inferencia. Un loop sin condición de salida quema presupuesto en minutos.

Conclusión

La orquestación no es una moda: es la diferencia entre un conjunto de scripts que “usan IA” y un sistema donde la IA trabaja como un equipo. Empieza chico: un orquestador, dos workers y un flujo bien definido. Agrega observabilidad desde el primer día, mide costos, y solo entonces escala a más agentes.

Sigue explorando estos temas en el blog de DojoFullStack: guías prácticas, arquitecturas y ejemplos reales para llevar tus proyectos con IA al siguiente nivel. Y si quieres dominar estas herramientas en serio, el bootcamp de DojoFullStack te da el camino paso a paso, desde los fundamentos hasta pipelines multi-agente en producción.