Orquestación de agentes de IA en producción: 5 patrones y cuándo (no) usar cada uno
Si estás diseñando un sistema con varios agentes de IA, la primera decisión no es qué framework usar, sino qué topología de orquestación conecta a esos agentes. Es la decisión que determina tu factura de tokens, tu latencia y —sobre todo— cómo falla el sistema cuando algo se tuerce. Y falla de formas poco intuitivas: bucles infinitos que disparan el coste en silencio, contexto que se trunca sin avisar y alucinaciones que se propagan de un agente al siguiente.
La respuesta corta para la mayoría de equipos: empieza con un solo agente bien construido; pasa a multiagente solo cuando el problema cruza dominios de verdad, y cuando lo hagas, el patrón supervisor es el punto de partida sensato en 2026. Este artículo desglosa los cinco patrones que sobreviven en producción, cuándo aplica cada uno, sus modos de fallo concretos y cómo elegir sin sobre-ingeniería.
Qué es la orquestación multiagente (y qué no es)
Orquestación multiagente es el conjunto de reglas que define cómo varios agentes de IA se coordinan para resolver una tarea: quién decide, quién ejecuta, cómo se pasan el trabajo y cómo se agregan los resultados. No es lo mismo que un protocolo. Un protocolo como MCP o A2A es el cableado —cómo se comunican—; la orquestación es la topología —quién habla con quién y en qué orden—. Lo cubrimos en detalle en A2A vs MCP: protocolos para agentes; aquí nos ocupamos de la capa de arquitectura que va por encima.
Un matiz que ahorra dinero y dolores de cabeza: multiagente no es un objetivo, es un coste. Investigación de Princeton NLP reportó que un único agente igualaba o superaba a sistemas multiagente en el 64 % de las tareas evaluadas, y a aproximadamente la mitad de coste. La coordinación se paga en tokens, latencia y superficie de fallo. Solo compensa cuando la tarea es genuinamente multidominio o requiere paralelismo real.
Los 5 patrones de orquestación en producción
1. Supervisor (orquestador–trabajadores)
Un agente coordinador clasifica la tarea, la reparte entre agentes especializados y agrega el resultado. Es el patrón por defecto en 2026 porque concentra la lógica de control en un único punto auditable.
- Cuándo usarlo: flujos con descomposición predecible —enrutado de atención al cliente, pipelines de análisis con especialistas claros.
- Modo de fallo: el supervisor es un punto único de fallo. Si clasifica mal, el trabajador equivocado recibe la tarea, y la tasa de error se compone a escala. Peor aún: el supervisor acumula el contexto de cada trabajador; a partir de 4 trabajadores es habitual desbordar la ventana de contexto.
2. Pipeline secuencial
El trabajo fluye por etapas en orden (investigar → esquematizar → redactar → revisar), cada una produciendo un artefacto intermedio tangible.
- Cuándo usarlo: tareas con dependencias lineales claras —procesamiento de documentos, generación de contratos, moderación de contenido.
- Modo de fallo: los errores se propagan aguas abajo (un mal esquema arruina la redacción). El overhead de coordinación crece rápido: en pruebas reportadas, un pipeline de 4 agentes consume más tiempo en coordinación que en procesamiento real, y triplica el consumo de tokens frente a un enfoque de agente único.
3. Fan-out / fan-in (paralelo)
Varios agentes analizan el mismo input en paralelo desde ángulos distintos (revisión financiera, de seguridad, de código) y un agregador reconcilia.
- Cuándo usarlo: análisis multiperspectiva donde el paralelismo recorta el tiempo de pared drásticamente.
- Modo de fallo: picos de peticiones concurrentes que revientan los rate limits del proveedor, y agregación que "alucina consenso" —el agente que reconcilia inventa un acuerdo que los subagentes no alcanzaron.
4. Debate
Varios agentes con roles contrapuestos argumentan hasta converger; útil para calidad y cumplimiento.
- Cuándo usarlo: revisión de compliance o QA donde varias perspectivas expertas mejoran la decisión.
- Modo de fallo: bucles de debate sin fin y cascada de sicofancia —los agentes se dan la razón entre sí y producen un falso consenso, tras haber gastado, por ejemplo, 15 llamadas al LLM por tarea. Sin criterio de parada explícito, arde presupuesto sin mejorar la respuesta.
5. Handoff dinámico (swarm)
No hay orquestador central: cada agente decide a quién pasar el control según lo que emerge en la conversación.
- Cuándo usarlo: soporte donde la especialidad necesaria se descubre a mitad de interacción y el enrutado es impredecible.
- Modo de fallo: es el fallo número uno en producción. Bucles de handoff infinitos (A→B→C→A), donde cada agente replanifica porque nadie es dueño de la tarea y el contexto se pierde en cada traspaso. El enrutado no determinista, además, hace el sistema muy difícil de depurar.
Tabla de decisión rápida
| Patrón | Úsalo cuando… | Riesgo principal | Coste relativo |
|---|---|---|---|
| Supervisor | Descomposición predecible, necesitas auditoría | Cuello de botella y desbordamiento de contexto (>4 trabajadores) | Medio |
| Pipeline | Etapas lineales con artefactos intermedios | Propagación de errores; overhead de coordinación | Medio-alto |
| Fan-out/fan-in | Paralelismo real, multiperspectiva | Rate limits; agregación que alucina consenso | Alto (ráfaga) |
| Debate | Calidad/compliance con criterio de parada | Bucles y falso consenso | Muy alto |
| Handoff (swarm) | Enrutado emergente e impredecible | Bucles infinitos; pérdida de contexto | Impredecible |
El modo de fallo que nadie presupuesta: el coste
Un flujo que cuesta 0,50 $ en pruebas puede convertirse en 50.000 $/mes a 100.000 ejecuciones, porque el orquestador hace varias llamadas al LLM (descomposición + agregación) encima de cada llamada de los trabajadores. Antes de escalar, tres medidas no negociables:
- Hard quotas y límites de iteración. Todo bucle (debate, handoff, replanificación) necesita un tope duro de iteraciones y de gasto. Sin él, un bucle infinito no rompe el sistema: solo te llega en la factura.
- Presupuesto de contexto explícito. Mide cuánto contexto acumula el orquestador por trabajador y define qué se resume o se descarta. Aquí ayuda tratar el contexto como un recurso gestionado, no infinito (context engineering en producción) y ejecutar herramientas por código para mover menos tokens (code execution con MCP).
- Observabilidad de tokens por agente y por traza. Necesitas ver el gasto desglosado por agente, no solo el total, para detectar al trabajador que se desboca.
Cuándo NO montar un sistema multiagente
Sé honesto con el caso de uso. No lo necesitas si:
- Un solo agente con buenas herramientas resuelve la tarea (el 64 % de las veces, según los benchmarks citados). Empieza aquí siempre.
- La tarea es de un solo dominio. Añadir agentes solo añade traspasos y coste.
- No tienes aún evaluación automatizada. Sin evals en producción no puedes saber si el multiagente mejora algo o solo lo encarece.
- No has probado los modos de fallo en staging. Antes de producción, dispara deliberadamente cada fallo: deja correr los bucles hasta que salte el límite, mete 200k tokens de estado para ver cómo se trunca, e inyecta una alucinación temprana en una cadena para ver hasta dónde se propaga.
Cómo lo abordamos en Dribba
La lógica de orquestación —clasificación, agregación, límites, colas, reintentos con backoff— vive mejor en un backend robusto que en el propio prompt. Nosotros solemos poner esa capa de control en Go sobre Cloud Run: concurrencia barata para el fan-out, timeouts y cancelación de contexto nativos para cortar bucles, y despliegue serverless que escala a cero. Y toda la comunicación agente-herramienta pasa por una capa endurecida (seguridad de MCP).
Somos equipo 100 % senior in-house, Flutter Partner oficial de Google desde 2017 y con +300 proyectos a la espalda entre Barcelona y Andorra. Si estás decidiendo la arquitectura de un sistema con agentes y quieres evitar el sobre-diseño —y la factura sorpresa que lo acompaña—, hablemos.
Conclusión
La orquestación multiagente no es una feature que activas, es una arquitectura que eliges. Empieza con un agente. Si el problema realmente cruza dominios, sube a un supervisor y pon límites duros antes de escalar. Trata cada bucle como un riesgo de coste, cada traspaso como una pérdida de contexto y cada agregación como una posible alucinación. Los sistemas que no se prueban contra sus modos de fallo, los encuentran en producción.
