Orquestación multi-agente: los cuatro patrones canónicos, cuándo usar cada uno, y los anti-patrones que rompen flotas

La mayoría de los escritos públicos sobre sistemas de agentes asume un único agente autónomo — un modelo, un prompt, un flujo de trabajo, un flujo de decisiones. La mayoría de los despliegues en producción más allá de su primer mes no se ven así. Se ven como flotas: seis, doce, treinta agentes con distintas especializaciones, distintos tiers de modelo, distintos radios de explosión, y un operador humano coordinándolos a través de un dashboard. El paso de "tengo un agente" a "tengo una flota" es la transición de ingeniería que separa a los operadores hobbystas de los profesionales, y la razón más común por la que las flotas fallan en producción es que el operador nunca eligió un patrón de orquestación — dejó que uno surgiera solo. Este post cataloga los cuatro patrones que sobreviven al contacto con producción, los tres anti-patrones que vimos romper flotas en la práctica, y un árbol de decisión que lleva al operador desde un agente hasta la forma correcta para treinta.

Por qué multi-agente falla más que single-agente

Un agente solo tiene un lugar para debuggear, un presupuesto para monitorear, un conjunto de credenciales para alcanzar, un modelo cuyo drift hay que rastrear. Cuando algo sale mal, la superficie es chica. Cuando algo sale bien, el crédito es inequívoco.

Una flota de agentes hereda riesgo compuesto en cada eje. Los bugs cascadean a través de agentes que consumen el output del otro. Los costos componen porque cada paso en una cadena cuesta tokens. La latencia compone porque cada agente espera al anterior. El radio de explosión compone porque un agente comprometido puede envenenar las entradas de cada otro agente que confía en él. El caso económico para ir multi-agente tiene que superar todos estos costos compuestos.

La buena noticia es que el caso vale la pena de manera abrumadora cuando la carga de trabajo es ella misma descomponible — cuando el problema se divide naturalmente en sub-tareas especialistas, o cuando el paralelismo ahorra tiempo real de reloj, o cuando distintas partes del problema necesitan distintos tiers de modelo (trabajo rutinario grado Haiku, pasos adversariales grado frontera de nuestro post de Project Deal). El truco es hacer coincidir la forma de la flota con la forma del trabajo, y eso es lo que elegir un patrón de orquestación realmente decide.

Patrón 1 — Supervisor-worker

La forma multi-agente más simple y por la que la mayoría de los operadores debería empezar. Un agente supervisor recibe la solicitud del usuario, la descompone en sub-tareas, despacha cada sub-tarea a un agente worker especializado, recolecta los resultados, y sintetiza la respuesta final.

Patrón supervisor-worker:

              ┌─────────────┐
              │  Supervisor │  ← recibe solicitud, planifica,
              └──┬────┬────┬─┘     sintetiza respuesta final
                 │    │    │
        ┌────────┘    │    └────────┐
        ▼             ▼             ▼
   ┌────────┐    ┌────────┐    ┌────────┐
   │Worker A│    │Worker B│    │Worker C│  ← especialistas, paralelos
   └────────┘    └────────┘    └────────┘
   Research      Translate     Summarize

Caso de uso. Cualquier tarea que se descompone limpiamente en sub-tareas independientes. El ejemplo clásico es un pipeline de investigación: el supervisor lee la pregunta, despacha un worker para recolectar documentos, un segundo para extraer entidades, un tercero para resumir. Los workers no necesitan hablarse entre ellos; solo necesitan hablar con el supervisor.

Matemática de costo. El supervisor corre dos veces — una en la descomposición, una en la síntesis. Los workers corren una vez cada uno en paralelo. El costo total de tokens es la suma de los cuatro agentes; la latencia de reloj es supervisor + max(workers) + supervisor. Comparado con correr todo en un modelo frontera, ahorras en los workers (que pueden ser grado Haiku) a costa de dos pasadas del supervisor (que pueden ser Sonnet u Opus).

Modos de falla. El supervisor se convierte en cuello de botella — cada solicitud está limitada por la tasa de un solo modelo. Si un worker falla, el supervisor tiene que manejar el resultado parcial (reintentar, enrutar a otro worker, aceptar el hueco). Si dos workers devuelven información contradictoria, el paso de síntesis del supervisor es donde la contradicción tiene que resolverse, y los modelos frontera no son geniales en esto sin instrucción explícita.

Cómo lo implementa Agent Builder. El supervisor se configura como el agente cara al usuario y los workers se exponen como endpoints A2A con skills declaradas. El prompt del supervisor incluye las skills de workers disponibles; el lifecycle de tasks de A2A maneja el despacho, el tracking de status, y la recolección de resultados. El dashboard muestra al supervisor arriba de un árbol con los workers debajo, con el gasto de tokens y la tasa de excepciones por agente.

Patrón 2 — Peer-to-peer mesh

Sin supervisor. Cada agente descubre a los otros agentes a través de consultas de reputación ERC-8004 y lookups de Agent Card A2A, decide qué trabajo puede o no puede hacer, y o lo hace o se lo pasa a un par que sí puede.

Peer-to-peer mesh:

   ┌────────┐         ┌────────┐
   │Agente A│◄───────►│Agente B│
   └───┬────┘         └───┬────┘
       │                  │
       │   ┌────────┐     │
       └──►│Agente C│◄────┘
           └────────┘
        (cada par negocia el trabajo vía A2A,
         identidad/reputación vía ERC-8004)

Caso de uso. Marketplaces donde los agentes participantes son propiedad de distintos operadores y tienen distintas especializaciones. Workflows cross-organización donde un único supervisor representaría un single point of failure o de confianza. Cualquier sistema donde el trabajo es demasiado diverso para planificarse de arriba hacia abajo.

Matemática de costo. El costo fijo más bajo (sin supervisor) y la mayor varianza en el costo por tarea (porque el enrutamiento se negocia cada vez). El propio paso de discovery cuesta tokens — el agente que decide "esto es demasiado complejo para mí, déjame encontrar un par" está pagando por la decisión. Los patrones mesh funcionan mejor cuando el valor por tarea es lo bastante alto como para absorber el costo de discovery.

Modos de falla. Loops de enrutamiento, donde el Agente A le pasa una tarea al B, B se la pasa de vuelta al A, repetir. Drift de reputación, donde un agente acumula una porción desproporcionada del trabajo y se vuelve el supervisor de facto. La asimetría de Project Deal — los agentes en modelos mejores sistemáticamente le ganan en negociación a los agentes en modelos más baratos, y el mesh puede desarrollar concentraciones de poder poco saludables.

Cómo lo implementa Agent Builder. Cada agente se lanza con discovery A2A habilitado y lecturas de reputación ERC-8004. El enrutamiento mesh es el default para workflows cross-operador. El dashboard muestra el grafo de contrapartes del agente y marca loops, outliers de reputación, y resultados inusuales de negociación.

Patrón 3 — Jerárquico en árbol

Supervisor-worker aplicado recursivamente. El supervisor superior descompone la tarea en sub-tareas demasiado grandes para un solo worker; cada sub-tarea recibe su propio sub-supervisor que descompone aún más en sub-workers, y así sucesivamente. El árbol puede ser de dos, tres, o cuatro niveles de profundidad dependiendo de la complejidad de la tarea.

Jerárquico en árbol:

                  ┌────────┐
                  │  Raíz  │
                  └──┬──┬──┘
              ┌──────┘  └──────┐
              ▼                ▼
         ┌────────┐       ┌────────┐
         │Sub-Sup │       │Sub-Sup │
         └──┬──┬──┘       └──┬──┬──┘
            │  │             │  │
            ▼  ▼             ▼  ▼
           ┌────┐┌────┐    ┌────┐┌────┐
           │ W1 ││ W2 │    │ W3 ││ W4 │
           └────┘└────┘    └────┘└────┘

Caso de uso. Trabajo de forma extensa que se descompone recursivamente — escribir un reporte de 50 páginas (capítulos → secciones → párrafos), correr un proyecto de investigación multi-paso (temas → preguntas → fuentes), ejecutar una transacción compleja multi-pierna (piernas → contrapartes → liquidaciones).

Matemática de costo. El patrón más caro por tarea. Los tokens componen en cada nivel porque los supervisores en cada capa tienen que planificar, despachar, y sintetizar. La compensación es paralelismo: un árbol de cuatro niveles con cinco hijos por nodo puede correr veinticinco workers de hoja concurrentemente, terminando en aproximadamente el tiempo de una sola hoja más cuatro pasadas de supervisor. Para tareas largas donde el tiempo de reloj importa, el paralelismo paga el overhead del supervisor. Para tareas cortas, no.

Modos de falla. Mala interpretación en cascada — la descomposición ligeramente equivocada del supervisor raíz se propaga por el árbol y se amplifica en cada nivel. La atribución de errores es difícil; cuando el output final está mal, el operador tiene que caminar el árbol entero para encontrar dónde entró el error. Los excesos de costo son los más fáciles de incurrir porque cada nivel multiplica el gasto de tokens.

Cómo lo implementa Agent Builder. La profundidad del árbol es un parámetro de configuración; el operador declara la profundidad máxima y el presupuesto por nivel. Cada nivel usa A2A para despachar y MCP Tasks (la extensión formal que cubrimos en el post de MCP) para rastrear sub-tareas de larga duración. El dashboard renderea el árbol visualmente con costo y status por nodo.

Patrón 4 — Swarm

Muchos agentes homogéneos — mismo modelo, mismo prompt, mismas tools — recibiendo un stream de tareas con balanceo de carga estocástico a través de ellos. No hay supervisor; la cola de trabajo es el coordinador.

Patrón swarm:

   ┌──────────────────────────────────┐
   │     Cola de trabajo (FIFO/LIFO)  │
   └─┬─────┬─────┬─────┬─────┬─────┬──┘
     │     │     │     │     │     │
     ▼     ▼     ▼     ▼     ▼     ▼
   ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐
   │A1 │ │A2 │ │A3 │ │A4 │ │A5 │ │A6 │   ← todos idénticos, paralelos
   └───┘ └───┘ └───┘ └───┘ └───┘ └───┘

Caso de uso. Cargas de alto volumen y bajo stake por llamada donde cada tarea es independiente de las otras. Triage de inbox, resumen masivo de emails, clasificación batch de documentos, scraping web masivo con análisis liviano. Cualquier cosa donde el throughput importa más que la sofisticación por tarea.

Matemática de costo. El perfil de costo más predecible de cualquier patrón. Cada tarea cuesta lo mismo; el costo total es el conteo de tareas por el costo por tarea; la latencia está acotada por el agente más lento del swarm. El paralelismo es el punto entero; con suficientes agentes puedes drenar una cola de mil tareas en el tiempo que le toma a una terminar.

Modos de falla. Hot spots, donde un input malformado hace que un agente entre en loop y ate la capacidad del swarm. Falta de memoria — porque cada agente es stateless, el trabajo que se beneficia de aprendizaje compartido entre tareas no lo recibe sin una capa de memoria externa (Graphiti, Mem0, o un vector store). Stampedes, donde el swarm golpea un servicio downstream todo a la vez y dispara rate limits.

Cómo lo implementa Agent Builder. El tamaño del swarm es un slider en el dashboard. La cola de trabajo es un servicio gestionado con backpressure, manejo de dead-letter, y políticas de reintento por tarea. Cada agente del swarm corre en su propia microVM Firecracker para aislación. El aprendizaje compartido, cuando se necesita, enchufa un store de memoria externo en la cola.

Los tres anti-patrones que vemos más seguido

Por cada patrón que funciona, hay uno que no. Las tres fallas que vimos romper más flotas en la práctica:

Mesh completo. Cada agente le habla a cada otro agente sin una capa de discovery. El costo de coordinación crece cuadráticamente (N agentes → N² conexiones). En seis agentes esto es soportable; en treinta es paralizante. La solución es o centralizar en un supervisor (Patrón 1) o usar discovery A2A para que los agentes solo le hablen a los pares que necesitan (Patrón 2).

Liderazgo en anillo. El rol de supervisor rota entre los agentes en un anillo, con cada agente tomando el rol de planificación para una de cada N tareas. La intuición es la equidad; la realidad es que cada agente tiene que ser capaz de planificar, lo que significa que cada agente tiene que estar en el modelo más caro. Pagaste por un modelo frontera seis veces en lugar de una.

Agregación ciega. El supervisor recolecta los outputs de los workers y los concatena en la respuesta final sin aplicar juicio. El resultado se lee como prosa escrita por comité — internamente inconsistente, contradictoria, repetitiva. La solución es un paso explícito de síntesis donde el supervisor razona sobre los outputs de los workers y resuelve los desacuerdos, lo que cuesta tokens pero produce un resultado coherente.

La matemática económica, simplificada

Para un operador que tiene que elegir, el trade-off de costo entre patrones se ve aproximadamente así:

Para una tarea que produce una respuesta final:

  Patrón            Tokens    Latencia  Throughput   Costo de falla
  ──────────────────────────────────────────────────────────────────
  Agente solo       1×        1×        Bajo         Concentrado
  Supervisor-worker 1.5–2×    0.5×      Medio        Distribuido
  Peer mesh         Variable  Variable  Alto         Distribuido
  Jerárquico        3–5×      0.3×      Alto         En cascada
  Swarm             N×        ~Const    Muy alto     Aislado

Multiplicadores relativos al baseline single-agente; "N" = conteo de tareas.

Tres reglas prácticas salen de esta tabla.

El agente solo es lo mejor para tareas únicas donde ni el paralelismo ni la especialización compran lo suficiente para compensar el overhead de orquestación. Si el trabajo cabe en una llamada de modelo, no inventes una flota para él.

Supervisor-worker es el upgrade default. El multiplicador de 1.5–2x en tokens se paga generalmente con el speedup paralelo y con poder usar modelos más baratos en los workers. La mayoría de las flotas que funcionan en producción son alguna variante de supervisor-worker.

El jerárquico paga solo cuando el tiempo de reloj ahorrado es genuinamente valioso. Un árbol de cuatro niveles generando un reporte de 50 páginas en 15 minutos en lugar de tres horas vale el costo. El mismo árbol gastado en una consulta que podría haberse respondido en una sola llamada Haiku no.

El árbol de decisión

Si estás sentado frente a un dashboard en blanco tratando de decidir qué patrón instanciar, camina este árbol de arriba abajo:

START → "¿El trabajo se descompone en sub-tareas?"
        │
        ├── NO  →  Agente solo. Pará acá.
        │
        └── SÍ → "¿Las sub-tareas necesitan hablarse entre ellas?"
                  │
                  ├── NO  → "¿Todas las sub-tareas tienen la misma forma?"
                  │         ├── SÍ → Swarm (Patrón 4)
                  │         └── NO → Supervisor-worker (Patrón 1)
                  │
                  └── SÍ → "¿Las sub-tareas pertenecen al mismo operador?"
                            ├── NO → Peer-to-peer mesh (Patrón 2)
                            └── SÍ → "¿La tarea es demasiado grande para
                                      un solo nivel de supervisor-worker?"
                                      ├── NO → Supervisor-worker (Patrón 1)
                                      └── SÍ → Jerárquico en árbol (Patrón 3)

El árbol captura cuatro decisiones reales: descomposición, comunicación, propiedad, profundidad. Las primeras tres son propiedades del trabajo mismo; la cuarta es una propiedad de la escala. Un operador que pueda responder estas cuatro preguntas para un caso de uso efectivamente eligió el patrón.

Qué cambia cuando escalas más allá de una sola flota

Los patrones de arriba asumen un operador gestionando una flota para un propósito. Los operadores reales más allá de su segunda o tercera flota terminan con múltiples flotas en paralelo — una flota de investigación, una flota de customer support, una flota de monitoreo, una flota de trading — cada una con su propio patrón. La pregunta de orquestación cross-flota se vuelve cómo interoperan las flotas: ¿el swarm de detección de señal de la flota de trading le pasa la posta al supervisor-worker de la flota de investigación para análisis profundo, y el resultado del análisis se realimenta a la flota de trading para ejecución? En la práctica esta coordinación cross-flota es ella misma un peer-to-peer mesh entre los supervisores de las flotas, que es el mismo Patrón 2 aplicado un nivel arriba.

El dashboard de Agent Builder refleja esto permitiendo al operador agrupar agentes en flotas, fijar presupuestos y políticas por flota, y ver los handoffs cross-flota como aristas de primera clase en el grafo del sistema. La complejidad no desaparece; se organiza.

Cierre

La razón por la que la mayoría de los demos multi-agente no llegan a producción no es que la tecnología subyacente esté rota. Es que el operador eligió el patrón equivocado, o peor, nunca eligió explícitamente ningún patrón, y dejó que la flota emergiera como un enredo de conexiones ad-hoc. Los cuatro patrones de arriba son las formas canónicas que sobreviven al contacto con cargas reales, y el árbol de decisión es la forma más barata de asegurarte de que el patrón con el que terminas coincide con el trabajo que efectivamente tienes.

Para un operador que corre su primera flota, supervisor-worker es casi siempre el punto de partida correcto. Es lo bastante simple para debuggear, lo bastante barato para no quebrarte, y lo bastante estructurado como para que sepas qué agente falló cuando algo se rompe. Una vez que esa flota corre limpiamente, los upgrades a mesh, árbol, o swarm son decisiones que tomas con los datos que tu dashboard te da — no adivinanzas que haces un martes a la mañana.

El próximo post de esta serie va a fondo sobre la disciplina de la que dependen los cuatro patrones: cómo evaluar y observar una flota de agentes para que el dashboard efectivamente te diga algo útil. Los patrones son el esqueleto; la evaluación y la observabilidad son el sistema nervioso. Necesitas ambos.