Qué es un agente orquestador y cómo coordina a otros agentes
Hay una confusión que aparece casi siempre cuando alguien empieza a diseñar sistemas multi-agente: asumir que el orquestador es el agente más inteligente del sistema. El que más sabe. El que resuelve los casos difíciles. Esa intuición es incorrecta y, si la sigues, construyes mal desde la base. — Jorge Valero, Director de Tecnología e IA.
El orquestador no es el más listo. Es el que dirige el tráfico. Su trabajo no es analizar ni producir. Es decidir quién analiza y quién produce, en qué orden, y qué hacer con todos los resultados cuando vuelven.
Llevo más de dos años con sistemas multi-agente en producción. El que más tiempo lleva activo coordina 28 agentes especialistas. En este artículo explico exactamente qué hace el orquestador, qué no hace, y por qué esa distinción importa si quieres construir algo que funcione de verdad.
Qué es un agente orquestador
Un agente orquestador es el componente de un sistema multi-agente que recibe la tarea de entrada, decide qué especialistas invocar para resolverla, coordina la ejecución —secuencial o en paralelo según las dependencias— y produce la síntesis final con todas las salidas recogidas.
Formación presencial · Madrid
¿Quieres salir de aquí sabiendo hacer esto en tu empresa el próximo 14 de noviembre?
En un día presencial montas tus departamentos agénticos con IA y construyes tu propia app. Sin conocimientos técnicos. Máx. 16 plazas.
Dicho de otro modo: el orquestador gestiona el flujo. Los especialistas gestionan el conocimiento.
Esta separación no es caprichosa. Es la diferencia entre un sistema que escala y uno que se convierte en un monolito frágil donde un único agente intenta hacer demasiadas cosas y las hace todas mediocres.
La responsabilidad concreta del orquestador
Cuando diseñamos el orquestador del sistema que lleva más tiempo en producción, le definimos tres responsabilidades exactas. Ni una más.
Primera: clasificar la tarea entrante. Leer lo que llega, entender qué tipo de problema es, y determinar qué especialistas son relevantes para ese problema concreto.
Segunda: gestionar la ejecución. Decidir si los especialistas se invocan en secuencia (cuando la salida de uno es entrada del siguiente) o en paralelo con fork de contexto (cuando son independientes entre sí). Coordinar los tiempos, gestionar errores si algún especialista falla, reintentar si procede.
Tercera: sintetizar el resultado. Recibir todas las salidas de los especialistas, combinarlas en un paquete de decisión coherente: opciones, tradeoffs, recomendación, próximos pasos.
Lo que el orquestador no hace: análisis de dominio. Si hay un contrato que revisar, el orquestador no lo lee. Si hay datos financieros que interpretar, el orquestador no los interpreta. Eso es trabajo de los especialistas. El orquestador sabe que existe ese trabajo y sabe a quién mandárselo. No sabe hacerlo él mismo, y así debe ser.
Por qué el orquestador no debe especializarse
Cuando diseñas por primera vez un sistema multi-agente, la tentación es darle al orquestador algo de conocimiento de dominio. «Si el orquestador entiende un poco de contratos, puede enrutar mejor». Esa intuición es un error de arquitectura.
Si el orquestador conoce el dominio, empieza a prejuzgar antes de enrutar. En lugar de «esto es un problema de tipo X, activo al especialista X», hace «esto parece un problema de tipo X pero yo ya sé que la respuesta es Y, así que solo voy a confirmar». Ha dejado de ser un director de tráfico neutro y se ha convertido en un agente con sesgo de confirmación.
El orquestador tiene que ser agnóstico al dominio por diseño. Su trabajo es gestión de tráfico, no análisis. En el sistema que tenemos en producción, el orquestador sabe que existen 28 especialistas y conoce las condiciones de activación de cada uno. Eso es todo. No sabe qué hace cada especialista por dentro. No tiene que saberlo.
La tabla de enrutamiento: 28 especialistas, 28 condiciones
En un sistema de producción real, el orquestador no decide con intuición. Decide con una tabla de enrutamiento explícita. En nuestro sistema, esa tabla tiene 28 filas: una por especialista.
Cada fila define tres cosas: el nombre del especialista, la condición de activación (qué características de la tarea entrante activan a ese especialista), y el modo de invocación (si puede ejecutarse en paralelo con otros o si necesita esperar la salida de alguno anterior).
| Especialista (ejemplo) | Condición de activación | Modo |
|---|---|---|
| Agente legal | Tarea contiene cláusulas contractuales o términos legales | Paralelo |
| Agente financiero | Tarea contiene cifras, métricas o proyecciones económicas | Paralelo |
| Agente de riesgo | Output de agente legal O financiero activo | Secuencial (espera) |
| Agente de síntesis | Todos los especialistas relevantes han completado | Secuencial (final) |
| … | … | … |
En el sistema real, esa tabla tiene 28 filas. No es un ejemplo pedagógico. Es la tabla que usamos. Diseñar esa tabla —decidir qué especialistas necesita tu empresa, cuáles son sus condiciones de activación exactas, cómo se relacionan entre sí— es el trabajo que requiere conocimiento de tu operación. Es lo que no puedo resolverse desde un artículo genérico. Es lo que trabajamos en el curso.
Patrones de invocación: secuencial vs paralelo con fork de contexto
Uno de los errores más comunes al implementar un orquestador es hacerlo todo secuencial por defecto. «Primero el especialista A, luego el B, luego el C». Funciona, pero es lento y no escala.
El orquestador tiene que saber distinguir dos situaciones:
Invocación secuencial: cuando la tarea B depende del output de la tarea A. El agente de riesgo no puede operar hasta que el agente legal haya identificado las cláusulas problemáticas. Aquí no hay otra opción que esperar. El orquestador lo sabe porque la tabla de enrutamiento lo especifica.
Invocación paralela con fork de contexto: cuando los especialistas son independientes entre sí. El agente legal y el agente financiero pueden analizar el mismo documento simultáneamente. El orquestador crea una copia del contexto relevante para cada uno, los lanza en paralelo, y espera a que ambos devuelvan resultado. El tiempo total es el del más lento, no la suma de los dos.
TAREA ENTRANTE
│
▼
┌─────────────────────────────┐
│ ORQUESTADOR │
│ Clasifica → Enruta │
└─────────────┬───────────────┘
│
┌─────────┴──────────┐
│ ¿Independientes? │
└─────────┬──────────┘
│
┌─────────▼──────────┐ ┌──────────────────────┐
│ SÍ → PARALELO │ │ NO → SECUENCIAL │
│ │ │ │
│ [Esp-A] [Esp-B] │ │ [Esp-A] → [Esp-B] │
│ ↓ ↓ │ │ ↓ │
│ Out-A Out-B │ │ Out-B │
└─────────┬──────────┘ └──────────┬───────────┘
│ │
└──────────────┬───────────────┘
│
┌─────────▼──────────┐
│ SÍNTESIS │
│ Opciones │
│ Tradeoffs │
│ Recomendación │
│ Próximos pasos │
└────────────────────┘
La gestión correcta del paralelismo es uno de los factores que más impacto tienen en el rendimiento de un sistema multi-agente. Un orquestador que serializa todo lo que podría paralelizar puede ser tres o cuatro veces más lento sin ninguna razón técnica.
La síntesis final: el producto real del orquestador
Cuando todos los especialistas relevantes han terminado, el orquestador tiene en su contexto un conjunto de outputs parciales. Cada especialista ha hecho su análisis desde su ángulo. El orquestador tiene que convertir eso en algo accionable.
En el sistema que tenemos en producción, la síntesis final siempre sigue la misma estructura: opciones disponibles, tradeoffs de cada opción, recomendación razonada, próximos pasos concretos. Llamamos a esto el paquete de decisión.
La síntesis no es un resumen. Resumir es juntar lo que dijeron los especialistas. Sintetizar es razonar sobre ello y producir una posición. La diferencia es la que hay entre un informe de 40 páginas y una decisión de media página que dice qué hacer y por qué.
El orquestador tiene que ser capaz de hacer esa síntesis aunque los especialistas hayan llegado a conclusiones contradictorias. Especialmente entonces. Un agente legal que dice «riesgo alto» y un agente de negocio que dice «oportunidad clara» no es un problema del sistema. Es exactamente la tensión que el orquestador tiene que gestionar en la síntesis.
Por qué el orquestador usa Claude Opus y todo lo demás usa Sonnet o Haiku
En el sistema que más tiempo lleva en producción, hay 28 agentes. De esos 28, exactamente uno corre sobre Claude Opus. El orquestador. Los otros 27 usan Sonnet o Haiku: 25 en Sonnet, 2 en Haiku.
Esto no es una decisión de presupuesto. Es una decisión arquitectónica.
Los especialistas necesitan velocidad y eficiencia de coste. Hacen tareas acotadas, con contexto limitado y output predecible. Para eso, Sonnet o Haiku son superiores: más rápidos, más baratos, igual de precisos en tareas delimitadas.
El orquestador necesita algo diferente. Necesita el contexto más largo posible para recibir los outputs de 28 especialistas sin perder información. Necesita el razonamiento más robusto para sintetizar contradicciones y producir una recomendación defendible. Necesita la capacidad de mantener coherencia sobre un volumen de información que un modelo más ligero comprimiría mal.
Opus en el orquestador no es un lujo. Es el punto donde el coste adicional está directamente justificado por la función. Si la síntesis falla, todo el sistema produce basura aunque los especialistas hayan hecho un trabajo perfecto.
| Componente | Modelo | Cantidad | Razón |
|---|---|---|---|
| Orquestador | Claude Opus | 1 | Contexto máximo + síntesis compleja |
| Especialistas principales | Claude Sonnet | 25 | Velocidad + coste en tareas acotadas |
| Especialistas ligeros | Claude Haiku | 2 | Máxima velocidad en tareas simples |
| Total | 28 |
Este reparto refleja un principio general: en un sistema multi-agente, el coste del modelo tiene que estar alineado con la complejidad de la tarea, no distribuido uniformemente. Poner Opus en todos los agentes es malgastar presupuesto y añadir latencia sin beneficio. Poner Haiku en el orquestador es arriesgarte a que la síntesis sea superficial.
Permisos de escritura: por qué solo el orquestador los tiene
Hay una regla de diseño que puede parecer restrictiva al principio pero que evita una clase entera de errores en producción: los especialistas son de solo lectura. Solo el orquestador tiene permisos de escritura.
Los especialistas pueden leer documentos, acceder a bases de datos, consultar APIs. No pueden escribir en bases de datos, no pueden modificar archivos, no pueden enviar correos. Toda acción que modifica el estado del sistema pasa por el orquestador.
Esto no es una cuestión de confianza en los especialistas. Es una cuestión de control. Si un especialista puede escribir directamente, tienes 28 puntos de escritura distribuidos en el sistema. Cualquier bug, cualquier alucinación, cualquier activación incorrecta puede causar un efecto secundario difícil de trazar. Si solo el orquestador escribe, tienes un único punto de control. El audit trail es limpio. El rollback es posible. Los errores son contenibles.
Cuando diseñamos el sistema con esta restricción, el equipo técnico preguntó si no sería más eficiente que algunos especialistas escribieran directamente sus outputs intermedios. La respuesta fue no. La eficiencia marginal no compensa la pérdida de control sobre efectos secundarios.
Lo que el orquestador no resuelve
Un artículo honesto sobre orquestadores tiene que decir también lo que no hacen.
El orquestador no decide qué especialistas necesita tu empresa. Eso depende de tu operación, de tus procesos críticos, de qué decisiones se toman con más frecuencia y cuáles tienen más impacto. Un sistema diseñado para una gestora de activos tiene especialistas completamente distintos a uno diseñado para una cadena de distribución.
El orquestador no define las condiciones de activación de tu tabla de enrutamiento. Esa tabla requiere que alguien conozca bien cómo funciona tu negocio y pueda traducir eso a condiciones precisas y no ambiguas. Es trabajo de diseño, no de configuración.
El orquestador no garantiza que los especialistas sean buenos. Si el especialista legal produce análisis superficiales, el orquestador va a sintetizar análisis superficiales. Garbage in, garbage out. La arquitectura orquestador-especialistas distribuye la responsabilidad, pero no la crea.
Estos tres puntos —qué especialistas necesitas, cómo diseñar la tabla de enrutamiento para tu empresa, cómo calibrar cada especialista— son exactamente lo que trabajamos en el curso. No porque sean secretos, sino porque no tienen respuesta genérica. Dependen de tu empresa específica.
Si quieres entender cómo funcionan los especialistas por dentro, el artículo sobre agentes especialistas en inteligencia artificial entra en el detalle de cómo se diseñan y qué los distingue de un agente genérico. Y si quieres ver cómo se instrumenta todo esto en una herramienta de trabajo real, el artículo sobre skills en Claude Code para agentes explica la capa de implementación práctica.
Preguntas frecuentes
¿Qué diferencia hay entre un agente orquestador y un agente especialista?
El orquestador gestiona el flujo: recibe la tarea, decide qué especialistas invocar, coordina la ejecución y sintetiza los resultados. Los especialistas gestionan el conocimiento: tienen expertise en un dominio concreto y producen análisis acotados a ese dominio. El orquestador no analiza. Los especialistas no orquestan. La separación es estructural y deliberada.
¿Por qué el orquestador no debería tener conocimiento de dominio?
Porque si tiene conocimiento de dominio, empieza a prejuzgar antes de enrutar. Su función es ser un director de tráfico neutro: clasificar la tarea y activar los especialistas correctos. Si el orquestador ya «sabe» cuál es la respuesta correcta, deja de enrutar correctamente y empieza a confirmar sus propias suposiciones. Eso degrada la calidad del sistema completo.
¿Cuándo se invocan los agentes en paralelo y cuándo en secuencia?
En paralelo cuando los especialistas son independientes entre sí: el orquestador crea una copia del contexto para cada uno y los lanza simultáneamente. En secuencia cuando la tarea B necesita el output de la tarea A: el orquestador espera a que el primer especialista termine antes de activar el siguiente. La tabla de enrutamiento especifica qué modo aplica a cada especialista. Un sistema bien diseñado maximiza el paralelismo para reducir latencia.
¿Por qué solo el orquestador tiene permisos de escritura?
Para mantener un único punto de control sobre los efectos secundarios del sistema. Si 28 especialistas pudieran escribir directamente, tendrías 28 puntos de escritura distribuidos. Cualquier error —un bug, una alucinación, una activación incorrecta— puede modificar datos de forma difícil de trazar y revertir. Con el orquestador como único punto de escritura, el audit trail es limpio y los errores son contenibles.
¿Qué modelo de IA debería usar el orquestador?
En el sistema con más tiempo en producción que describimos en este artículo, el orquestador usa Claude Opus y los 27 especialistas usan Sonnet o Haiku. El orquestador necesita el contexto más largo posible —para recibir outputs de 28 especialistas— y el razonamiento más robusto para sintetizarlos de forma coherente. Los especialistas necesitan velocidad y eficiencia de coste en tareas acotadas. El modelo del orquestador debe estar justificado por su función, no por el presupuesto disponible.
¿Cuántos agentes especialistas necesita un sistema multi-agente?
Depende completamente de la operación de la empresa. No hay un número correcto genérico. El sistema que describimos tiene 28 porque cubre 28 dominios distintos de análisis que son relevantes para esa operación concreta. Otra empresa podría necesitar 8 o 45. Lo importante no es el número sino que cada especialista tenga un dominio bien delimitado, condiciones de activación claras, y que no haya solapamiento de responsabilidades entre ellos.
Sobre Jorge Valero
Director de Tecnología e IA con más de 15 años de experiencia implantando sistemas de datos e inteligencia artificial en empresas medianas y grandes. Instructor y consultor especializado en ayudar a directivos a usar la IA como herramienta de decisión. Conoce mi trayectoria →
