Essence du pattern
Orchestrator Agent est un pattern dans lequel un agent coordonne le travail de plusieurs executants : il decoupe la tache, delegue les sous-taches, suit les statuts et assemble le resultat.
Quand l'utiliser : quand une grande tache doit etre repartie entre executants puis reunie en un resultat unique.
Au lieu qu'un seul agent fasse tout, Orchestrator :
- analyse l'objectif global
- le decoupe en sous-taches
- envoie les sous-taches aux bons agents
- assemble leurs reponses en un resultat unique
Probleme
Imagine qu'il faille preparer un lancement go-to-market.
Ce n'est pas une seule action, mais plusieurs flux paralleles :
- contenu et positionnement
- analytique et prevision
- verification juridique
- plan final de release
Quand un seul agent fait tout en sequence, le systeme devient "etroit en un point".
Sans orchestration, une tache multi-etapes perd en vitesse et devient fragile face aux pannes locales.
Resultat :
- le processus ralentit a cause de l'execution en serie
- le cout augmente a cause de charge supplementaire sur la runtime d'execution
- la panne d'une etape bloque toute la tache
- il devient difficile de tenir timeouts, retries et deadlines
Voila le probleme : sans coordination de plusieurs executants, une tache complexe devient lente, couteuse et peu maitrisable.
Solution
Orchestrator ajoute une couche de coordination (coordination layer) pour piloter plusieurs executants.
Analogie : c'est comme un chef de projet. Il ne fait pas toutes les taches lui-meme, il coordonne l'equipe, l'ordre et les dependances. Cela reduit les retards et les conflits entre etapes.
Principe cle : d'abord coordonner sous-taches et dependances, puis executer.
Les agents separes executent les sous-taches, et orchestrator-policy definit les regles :
- ce qui doit etre lance en parallele
- ce qui doit etre attendu en sequence
- comment gerer
timeout/retry/fallback - quand considerer le resultat comme termine
Processus pilote :
- Planification (Plan) : decouper le goal en sous-taches et dependances
- Attribution (Dispatch) : assigner executants et limites
- Execution parallele (Parallel Execute) : lancer en meme temps les etapes independantes
- Agregation (Aggregate) : collecter les resultats des executants
- Verification et final (Validate/Done) : verifier l'output final et terminer
Le monitoring (retries, timeouts, statuts) tourne pendant toute l'execution.
Cela apporte :
- moins de temps total d'execution
- controle des pannes partielles (partial failures)
- limites et regles centralisees
- resultat final coherent
Cela fonctionne bien si :
- le plan contient des dependances explicites
- des limites timeout/budget sont fixees pour les executants
- une policy existe pour
retry/fallback/partial result - l'agregation valide completude et coherence
Le modele peut "vouloir" tout lancer d'un coup ou tout faire en serie, mais orchestrator-policy fixe l'ordre correct et les limites.
Comment ca fonctionne
Orchestrator n'execute pas les sous-taches lui-meme.
Il pilote le processus :
- a qui transmettre chaque sous-tache
- quelles limites de temps ou budget appliquer
- quand relancer une etape en echec
- quand terminer tout le processus
Description du flow complet : Plan → Dispatch → Parallel Execute → Aggregate
Planification (Plan)
L'agent construit le plan : quelles sous-taches sont necessaires, quelles dependances existent, et ce qui peut tourner en parallele.
Attribution (Dispatch)
Le systeme transmet les sous-taches aux agents ou services necessaires.
Execution parallele (Parallel Execute)
Chaque executant traite sa partie via son cycle Think → Act → Observe.
Agregation (Aggregate)
Orchestrator rassemble les resultats, valide la completude, puis forme la reponse finale.
En code, cela ressemble a ceci
plan = plan_tasks(goal)
jobs = [dispatch_async(worker, task) for worker, task in plan] # demarrer les sous-taches en parallele
results = await gather_with_limits(jobs, timeout_sec=30) # collecte avec policies timeout/limit
results = retry_timeouts_once(results) # exemple simple : un retry sur timeout
final = aggregate(results)
return final
Orchestrator lance des sous-taches en parallele et attend les resultats avec timeouts et limites.
A quoi cela ressemble pendant l'execution
Goal: preparer un plan de mise sur le marche
Plan:
- Agent A: marche et concurrents
- Agent B: modele financier
- Agent C: risques et compliance
Dispatch: les trois sous-taches demarrent en parallele
Observe:
- Agent A: termine en 6 s
- Agent B: termine en 9 s
- Agent C: timeout, relance
- Agent C: termine en 5 s apres retry
- Entre etapes: les resultats apres retry reviennent dans l'ensemble commun pour aggregate
Aggregate:
- A + B + C collectes (C apres retry)
- policy d'erreur appliquee
- un document unique est produit
Exemple complet d'agent Orchestrator
Quand c'est adapte - et quand ca ne l'est pas
Adapte
| Situation | Pourquoi Orchestrator est adapte | |
|---|---|---|
| ✅ | La tache peut etre decomposee en plusieurs parties independantes | Orchestrator distribue les sous-taches entre executants et les coordonne en parallele. |
| ✅ | Il est important de reduire le temps par execution parallele | Le lancement simultane des sous-taches reduit le temps total d'attente du resultat. |
| ✅ | Des agents specialises differents sont necessaires | Chaque agent recoit son role, et Orchestrator synchronise leur travail. |
| ✅ | Controle de timeouts, retries et agregation necessaire | Le pattern ajoute un pilotage d'execution et un point unique de collecte du resultat final. |
Non adapte
| Situation | Pourquoi Orchestrator n'est pas adapte | |
|---|---|---|
| ❌ | La tache est petite et mono-etape | La couche de coordination ajoute du surcout la ou un seul executant suffit. |
| ❌ | Toutes les etapes sont strictement sequentielles | Si le parallelisme est impossible, l'orchestration apporte presque rien. |
| ❌ | L'infrastructure ne supporte pas un parallelisme fiable | Sans execution stable, retries et controle d'etat, l'orchestration devient fragile. |
Parce que Orchestrator ajoute de la coordination supplementaire : files de taches, attente des resultats et assemblage des reponses.
Difference avec Routing
| Routing | Orchestrator | |
|---|---|---|
| Ce qu'il decide | A qui confier la tache | Comment piloter plusieurs executants |
| Agents actifs | Souvent un seul | Plusieurs en meme temps |
| Focus | Classification et delegation | Coordination, timing et assemblage des resultats |
| Sortie | Tache deleguee a l'executant | Resultat final combine |
Routing repond : "a qui donner la tache".
Orchestrator repond : "comment synchroniser plusieurs taches et assembler le resultat".
Quand utiliser Orchestrator (vs autres patterns)
Utilisez Orchestrator quand il existe plusieurs etapes dependantes et que le bon ordre d'execution est important.
Test rapide :
- si vous devez "faire passer la tache par une chaine claire d'etapes" -> Orchestrator
- si vous devez "seulement choisir l'executant d'une demande" -> Routing Agent
Comparaison avec d'autres patterns et exemples
Aide-memoire rapide :
| Si la tache ressemble a ca... | Utilisez |
|---|---|
| Il faut choisir un unique meilleur executant | Routing Agent |
| Il y a une sequence d'etapes et l'ordre est important | Orchestrator Agent |
| Un policy-check est necessaire avant le resultat final | Supervisor Agent |
| Plusieurs agents doivent converger vers une seule conclusion | Multi-Agent Collaboration |
Exemples :
Routing : "Le client demande un remboursement - envoyer a Billing, pas a Sales".
Orchestrator : "Prepare un release : d'abord changelog, puis QA, puis deploy".
Supervisor : "Avant d'envoyer un email, verifier policies, compliance et promesses interdites".
Multi-Agent Collaboration : "Marketing, Legal et Product doivent valider un texte final unique pour une promo".
Comment combiner avec d'autres patterns
- Orchestrator + Routing — Routing choisit l'executant pour la sous-tache, et Orchestrator suit le flux global.
- Orchestrator + ReAct — chaque agent execute sa partie etape par etape, puis Orchestrator assemble le tout dans un plan unique.
- Orchestrator + Supervisor — avant les actions critiques, policies, risques et budget d'execution sont verifies.
En bref
Orchestrator Agent:
- planifie les sous-taches
- les delegue aux executants
- pilote l'execution parallele
- assemble le resultat final
Avantages et Inconvenients
Avantages
pilote tout le processus de facon centralisee
repartit clairement les taches entre executants
controle mieux ordre et priorites
progression facile a monitorer
Inconvenients
devient un point critique du systeme
configuration des routes peut etre complexe
une erreur d'orchestrateur impacte tout le flux
FAQ
Q : Orchestrator lance-t-il toujours les sous-taches en parallele ?
A: Non. Certaines etapes peuvent etre executees en sequence s'il existe des dependances entre elles.
Q : Que faire si un agent ne renvoie pas de resultat ?
A: Definir une policy d'erreur : retry, timeout, fallback ou partial result. Orchestrator applique cette policy avant l'agregation finale.
Q : Faut-il Orchestrator s'il y a deja Routing ?
A: Routing choisit un executant. Orchestrator coordonne plusieurs executants, souvent en utilisant Routing dans chaque sous-tache.
Et ensuite
Orchestrator coordonne le travail de plusieurs agents en meme temps.
Mais qui garantit qu'ils ne violent pas les policies, le budget et les regles de securite ?