Orquestación multi-agente: cuándo sí y cuándo es un error

La pregunta no es “¿cómo orquesto varios agentes?”. Es ¿necesito más de uno?. La mayoría de sistemas multi-agente que fallan en producción nunca necesitaron el segundo agente: necesitaban un prompt mejor, una tool más o una cola. Anthropic lo dice sin rodeos en Building effective agents: busca la solución más simple posible y solo añade complejidad cuando la necesidad lo justifique, porque los sistemas agénticos cambian latencia y costo por rendimiento. Esta guía te da las señales para decidir y los patrones que sí se repiten cuando la respuesta es “sí”. Las fuentes oficiales fueron consultadas el 3 de septiembre de 2026.

Si todavía no tienes claro qué es un agente frente a un workflow, empieza por qué es un agente de IA. Aquí el foco es la decisión de arquitectura.

Definición citable

Orquestación multi-agente es la coordinación de dos o más agentes —o de un orquestador con agentes especializados— para completar una tarea que un solo agente no resuelve bien, ya sea por contexto, por herramientas incompatibles o por necesidad de aislar fallos. Anthropic distingue dos extremos: los workflows, donde el código predefine el camino entre llamadas al modelo, y los agentes, donde el modelo decide dinámicamente qué hacer a continuación. La orquestación multi-agente vive en algún punto intermedio: hay más de un proceso con autonomía, y alguien —código o modelo— decide quién trabaja cuándo.

Cuándo NO: las señales de que un solo agente basta

Antes de dibujar el diagrama con cinco cajas, revisa estas señales. Si tu caso cae aquí, un solo agente con buenas tools gana:

• La tarea cabe en un prompt. Si puedes describir el trabajo completo en instrucciones + ejemplos, no hay nada que orquestar.
• Las tools no se pisan. Si todas las herramientas operan sobre el mismo contexto sin conflictos, separarlas en agentes solo añade saltos.
• El contexto no se contamina. Si el historial de la conversación sigue siendo útil de principio a fin, no necesitas aislar memoria.
• No hay paralelismo real. Si el paso B siempre depende del resultado del A, eso es un pipeline en código, no una orquestación.
• No tienes observabilidad básica. Si no sabes qué hace tu agente actual, dos agentes te dan el doble de caja negra. Resuelve primero la observabilidad.

La regla práctica: cada agente extra multiplica tokens (cada uno re-lee contexto), latencia (saltos secuenciales) y superficie de fallo. Si no hay una ganancia medible, es costo puro.

Cuándo SÍ: las cuatro señales reales

1. Contextos que se destruyen entre sí. Un agente que investiga durante 40 turnos y luego redacta funciona peor que un investigador que entrega un resumen y un redactor que parte de ahí. El contexto largo deja de ser gratis mucho antes de llenar la ventana.
2. Dominios con tools incompatibles. El agente que opera el CRM no debería tener acceso a la terminal de deploy. Separar por dominio es también una decisión de seguridad, no solo de calidad.
3. Paralelismo que sí acorta el reloj. Tres subtareas independientes corriendo a la vez terminan antes que en secuencia. Si el tiempo de respuesta importa y los pasos son independientes, paralelizar agentes es la palanca.
4. Fallos que hay que aislar. Si una tarea puede explotar (un scraper, un ejecutor de código), quieres que muera en su propio proceso con su propio presupuesto, no arrastrando al agente principal.

Si reconoces dos o más, sigue leyendo. Si no, vuelve al agente único y métele mejores tools.

Los cinco patrones que se repiten en producción

La taxonomía de Anthropic para workflows cubre casi todo lo que verás en la práctica. Traducida a decisiones:

Patrón	Qué es	Úsalo cuando	Evítalo cuando
Pipeline (prompt chaining)	La salida de un paso alimenta al siguiente, con validaciones en medio	La tarea se descompone en subtareas fijas y conocidas	Cada paso depende del anterior y no hay paralelismo que ganar
Routing	Un clasificador decide qué agente o flujo atiende la entrada	Hay tipos de solicitud claramente distintos (soporte vs ventas vs técnico)	Las categorías se solapan y el router falla más que un agente generalista
Supervisor (orchestrator-workers)	Un agente central descompone la tarea, delega y sintetiza	Las subtareas no se conocen de antemano y hay que decidir sobre la marcha	La tarea es predecible: un pipeline en código es más barato y auditable
Paralelo + agregador	Varios agentes corren la misma tarea o subtareas independientes y otro consolida	Votación por mayoría, análisis por secciones, comparación de opciones	Los resultados no son comparables o agregar cuesta más que rehacer
Evaluador-optimizador	Un agente genera, otro critica, en bucle hasta cumplir criterio	Hay criterios de calidad claros (traducción, copy, código con tests)	No sabes definir “bueno”: el evaluador aplaude cualquier cosa

OpenAI documenta el mismo mapa en su Agents SDK con dos mecanismos concretos: handoffs (un agente transfiere el control a otro) y agents as tools (un agente llama a otro como si fuera una función). Handoff cuando el especialista se queda con la conversación; tool cuando el especialista devuelve un resultado y el orquestador sigue al mando.

Reglas de diseño que evitan el desastre

• Contexto explícito entre agentes. Nada de “que lea el historial completo”: el supervisor entrega un brief. Cada agente recibe lo que necesita, no todo lo que existe. Es la misma disciplina de memoria y RAG para agentes aplicada entre procesos.
• Presupuesto por agente. Tokens máximos, pasos máximos, timeout. Un agente en loop dentro de una orquestación no quema su cupo: quema el de todos.
• Trazas por agente y por corrida. Necesitas reconstruir quién decidió qué. Sin trazas, un sistema multi-agente es imposible de depurar; revisa qué medir en observabilidad antes de subir agentes.
• Salidas estructuradas en los bordes. Entre agentes, JSON con schema. El texto libre entre procesos es donde nacen los bugs que nadie reproduce.
• El orquestador tonto gana. Si el reparto lo puede hacer un switch en código, hazlo en código. Deja al modelo las decisiones que de verdad requieren juicio.

Checklist antes de añadir el segundo agente

[ ] ¿Un solo agente con más tools ya lo intentaste y falló de forma medible?
[ ] ¿La falla es de contexto, de dominio, de paralelismo o de aislamiento?
[ ] ¿Sabes qué patrón vas a usar (pipeline, routing, supervisor, paralelo, evaluador)?
[ ] ¿Cada agente tiene presupuesto de tokens y pasos?
[ ] ¿El intercambio entre agentes es estructurado (schema), no texto libre?
[ ] ¿Tienes trazas por agente y por corrida completa?
[ ] ¿El costo por tarea con N agentes está medido contra el de 1 agente?
[ ] ¿Hay un camino de degradación: si un agente muere, qué responde el sistema?

Si no puedes marcar las primeras tres, estás añadiendo arquitectura por estética.

Decisión en una frase

• Tarea predecible y secuencial: pipeline en código, cero orquestación.
• Tipos de entrada distintos: routing hacia especialistas.
• Subtareas desconocidas de antemano: supervisor con workers, presupuestado.
• Calidad con criterio medible: evaluador-optimizador en bucle.
• Todo lo demás: un agente, buenas tools, mejor prompt.

El hub de construcción de agentes junta esta decisión con tools, memoria y despliegue. Cuando ya tengas la arquitectura, dónde desplegar el agente cubre el runtime, y el curso gratuito te lleva de cero a un primer agente funcionando sobre el que aplicar todo esto.