Patrón de agente orquestador: flujos multiagente fiables

Esencia del patron

Orchestrator Agent es un patron donde un agente coordina el trabajo de varios ejecutores: divide la tarea, delega subtareas, sigue estados y combina resultados.

Cuando usarlo: cuando una tarea grande debe repartirse entre ejecutores y unirse en un unico resultado.

En lugar de que un agente haga todo solo, Orchestrator:

• analiza el objetivo general
• lo divide en subtareas
• envia subtareas a los agentes adecuados
• combina sus respuestas en un resultado unico

Problema

Imagina que hay que preparar un lanzamiento go-to-market.

No es una sola accion, sino varios flujos paralelos:

• contenido y posicionamiento
• analitica y pronostico
• revision legal
• plan final de release

Cuando un solo agente lo hace todo en serie, el sistema se vuelve "estrecho en un solo punto".

Sin orquestacion, una tarea de muchos pasos pierde velocidad y se vuelve fragil ante fallos locales.

Como resultado:

• el proceso se hace mas lento por ejecucion serial
• el costo sube por carga extra sobre el runtime de ejecucion
• el fallo de un paso bloquea toda la tarea
• es dificil mantener timeouts, retries y deadlines

Ahi esta el problema: sin coordinacion de varios ejecutores, una tarea compleja se vuelve lenta, cara y poco controlable.

Solucion

Orchestrator agrega una capa de coordinacion (coordination layer) para gestionar varios ejecutores.

Analogia: es como un project manager. No hace todas las tareas por si mismo, sino que coordina equipo, orden y dependencias. Asi se reducen retrasos y conflictos entre pasos.

Principio clave: primero coordinacion de subtareas y dependencias, despues ejecucion.

Los agentes separados ejecutan subtareas, y orchestrator-policy define reglas:

• que ejecutar en paralelo
• que esperar en secuencia
• como manejar timeout/retry/fallback
• cuando considerar el resultado como listo

Proceso controlado:

1. Planificacion (Plan): dividir goal en subtareas y dependencias
2. Asignacion (Dispatch): asignar ejecutores y limites
3. Ejecucion paralela (Parallel Execute): lanzar pasos independientes al mismo tiempo
4. Agregacion (Aggregate): reunir resultados de ejecutores
5. Validacion y cierre (Validate/Done): validar output final y terminar

El monitoreo (retries, timeouts, estados) corre durante toda la ejecucion.

Esto da:

• menor tiempo total de ejecucion
• control de fallos parciales (partial failures)
• limites y reglas centralizados
• resultado final consistente

Funciona bien si:

• el plan tiene dependencias explicitas
• hay limites de timeout/budget para ejecutores
• existe policy para retry/fallback/partial result
• la agregacion valida completitud y consistencia

El modelo puede "querer" lanzar todo de golpe o todo en serie, pero orchestrator-policy fija el orden y los limites correctos.

Como funciona

Orchestrator no ejecuta subtareas por si mismo.

Controla el proceso:

• a quien pasar cada subtarea
• que limites de tiempo o presupuesto aplicar
• cuando reiniciar un paso fallido
• cuando terminar el proceso completo

En codigo se ve asi

plan = plan_tasks(goal)

jobs = [dispatch_async(worker, task) for worker, task in plan]  # iniciar subtareas paralelas
results = await gather_with_limits(jobs, timeout_sec=30)  # recolectar con politicas de timeout/limit
results = retry_timeouts_once(results)  # ejemplo simple: un retry para timeout

final = aggregate(results)
return final

Orchestrator inicia subtareas en paralelo y espera resultados con timeouts y limites.

Como se ve durante la ejecucion

Goal: preparar plan de salida al mercado

Plan:
- Agent A: mercado y competidores
- Agent B: modelo financiero
- Agent C: riesgos y compliance

Dispatch: las tres subtareas arrancan en paralelo

Observe:
- Agent A: listo en 6 s
- Agent B: listo en 9 s
- Agent C: timeout, reinicio
- Agent C: listo en 5 s despues de retry
- Entre etapas: resultados despues de retry vuelven al conjunto comun para aggregate

Aggregate:
- se reunen A + B + C (C despues de retry)
- se aplica policy de errores
- se genera un documento unico

Cuando encaja - y cuando no

Encaja

No encaja

Porque Orchestrator agrega coordinacion extra: colas de tareas, espera de resultados y union de respuestas.

Diferencia frente a Routing

Routing responde: "a quien dar la tarea".

Orchestrator responde: "como sincronizar varias tareas y juntar el resultado".

Cuando usar Orchestrator (vs otros patrones)

Usa Orchestrator cuando hay varios pasos dependientes y el orden correcto de ejecucion importa.

Prueba rapida:

• si necesitas "pasar la tarea por una cadena clara de pasos" -> Orchestrator
• si necesitas "solo elegir el ejecutor de una solicitud" -> Routing Agent

Como combinar con otros patrones

• Orchestrator + Routing — Routing elige ejecutor para la subtarea y Orchestrator vigila el flujo total de trabajo.
• Orchestrator + ReAct — cada agente ejecuta su parte paso a paso y Orchestrator lo integra en un solo plan.
• Orchestrator + Supervisor — antes de acciones criticas se validan politicas, riesgos y presupuesto de ejecucion.

Resumen

Ventajas y desventajas

FAQ

Q: Orchestrator siempre ejecuta subtareas en paralelo?
A: No. Algunos pasos pueden ir en secuencia si existen dependencias entre ellos.

Q: Que hacer si un agente no devolvio resultado?
A: Se define una policy de errores: retry, timeout, fallback o partial result. Orchestrator aplica esa policy antes de la agregacion final.

Q: Hace falta Orchestrator si ya existe Routing?
A: Routing elige un ejecutor. Orchestrator coordina muchos ejecutores y muchas veces usa Routing dentro de cada subtarea.

Que sigue

Orchestrator coordina trabajo de varios agentes al mismo tiempo.

Pero quien garantiza que no rompan politicas, presupuesto y reglas de seguridad?