Lancer une orchestration

Ce guide explique comment transformer un seul grand objectif en un plan pour toute l’équipe qui s’exécute de lui-même. Voir Orchestration pour comprendre son fonctionnement.

Quand recourir à une orchestration

Recourez à une orchestration lorsque la demande dépasse un seul agent et que vous ne connaissez pas déjà les étapes exactes. Pour une tâche unique, envoyez un message à un agent dans un espace ; pour un processus que vous pouvez décrire à la main, créez un modèle de pipeline.

Étape 1 : Demander le plan

Ouvrez (ou créez) un espace et un ticket d’ancrage. Chaque proposition en exige un (propose_orchestration prend ticket_id) ; l’espace partagé découle de ce ticket.
Vous pouvez aussi faire passer le menu déroulant des modes du compositeur à Orchestration. Ce mode restreint l’agent à la lecture et à la proposition — mémoire, graphe de code, lectures de dépôts et de tickets, propose_orchestration et les outils de playbook — de sorte qu’il ne peut pas se mettre à écrire du code au lieu de planifier.
Mentionnez votre orchestrateur avec @ (habituellement l’agent CEO) et énoncez l’objectif en langage clair :

@ceo Étudiez le paysage concurrentiel d’un enregistreur de réunions qui fonctionne d’abord hors ligne et rédigez un document de positionnement d’une page.

L’orchestrateur répond par une proposition structurée affichée sous forme de carte dans l’espace : les rôles dont il a besoin, le travail décomposé en sous-tickets, une phase facultative de recherche et de discussion, une étape de synthèse qui produit le livrable et un budget.

Comme la proposition est un objet typé, l’application la valide (rôles bien formés, schémas de sortie déclarés, DAG sans cycle) avant que quoi que ce soit ne s’exécute. Une proposition qui échoue à la validation ne peut pas être approuvée.

Étape 2 : Réviser et modifier la proposition

La carte dans la conversation propose trois actions : Approuver le plan, Rejeter et Ouvrir — qui ouvre le plan dans Plan Studio comme onglet d’éditeur. La carte elle-même ne peut pas être modifiée.

Pour modifier quoi que ce soit, appuyez sur Ouvrir et travaillez dans l’inspecteur de droite :

le titre, la description, le rôle, les dépendances et le schéma de sortie de toute étape de travail. Ici, le rôle désigne la clé de rôle existante du plan à laquelle appartient l’étape — vous ne pouvez pas épingler un rôle à un agent nommé ni modifier la liste des recrues depuis l’inspecteur, et vous ne pouvez pas modifier le budget.

Deux éléments sont en lecture seule : les nœuds structurels (recherche, discussion, synthèse) et tout nœud dont le travail s’est déjà exécuté. La modification n’est possible que tant que l’orchestration est encore proposed.

Appuyez sur Estimer dans la barre d’approbation pour obtenir les plages de coût, de durée et de rayon d’impact avant de vous engager. Voir Travailler dans Plan Studio pour l’éditeur complet.

Étape 3 : Approuver

Approuvez le plan, depuis la carte de la conversation ou depuis la barre d’approbation de Plan Studio. C’est la seule décision que vous prenez. L’approbation est réservée aux opérateurs — il n’existe aucun outil MCP pour cela, donc un agent peut proposer et réviser, mais jamais approuver son propre plan.

À partir de là, un matérialiseur déterministe (une fonction pure, sans LLM) transforme la proposition en un véritable pipeline et crée l’échafaudage :

recrute tout nouveau rôle (et consigne les identifiants des agents recrutés pour qu’un plantage en cours d’approbation puisse reprendre sans recruter en double)
regroupe les rôles dans une équipe
crée un projet et y classe le ticket parent
lance l’exécution de pipeline qui pilote le tout

Le statut passe à approved, puis à executing.

Étape 4 : Suivre l’exécution

Les sous-tickets s’exécutent comme des étapes de pipeline ; si vous avez activé une ronde de discussion, chaque rôle publie d’abord une position. La progression s’affiche là où vous regardez déjà :

le ticket parent sur lequel l’orchestration a été ancrée
l’espace partagé dans lequel l’équipe discute, où la ligne du plan suit l’état de chaque nœud
le détail de l’exécution de pipeline, avec sa cascade chronologique habituelle et son coût par étape — voir Surveiller les exécutions de pipeline
le projet sous lequel le ticket parent a été classé

Une fois les sous-tickets terminés, le statut passe à synthesizing et l’étape de synthèse produit le livrable. Ce texte est publié dans l’espace partagé et le ticket parent est marqué comme terminé, puis le statut passe à completed.

L’arrêter avant la fin

Appuyez sur Annuler l’orchestration sur la carte de la conversation, ou sur Annuler l’exécution dans la barre d’approbation de Plan Studio. L’annulation démonte le travail en cours.

Une orchestration échoue lorsque la matérialisation échoue, ou lorsque l’exécution du pipeline généré échoue (recherche, discussion, synthèse ou persistance — ces étapes ne poursuivent pas en cas d’échec). Les étapes de travail générées, elles, poursuivent toujours en cas d’échec, de sorte qu’un sous-ticket en échec ne fait pas échouer l’exécution. Il n’existe aucun chemin d’échec pour un dépassement de budget ni de seuil « tous les sous-tickets ont échoué ».

Guides connexes

Travailler dans Plan Studio : modifier, estimer, comparer les révisions et approuver le plan
Créer et gérer des tickets : le ticket parent sur lequel une orchestration est ancrée
Organiser le travail avec des projets : où le ticket parent est classé
Surveiller les exécutions de pipeline : à quoi ressemble une orchestration matérialisée dans le moteur
Constituer une équipe d’agents : les rôles qu’une orchestration pourvoit ou recrute