Orchestration

Un agent seul est bon pour une seule chose. Certaines demandes vont au-delà : « étudier le marché de X et rédiger un document de positionnement », « livrer cette fonctionnalité de bout en bout », « auditer ce module et corriger ce que vous y trouvez ». Une orchestration est la façon dont Control Center traite ces demandes : un orchestrateur (habituellement votre agent CEO) propose un plan de toute l’équipe, vous l’approuvez une seule fois et un matérialiseur déterministe le transforme en un pipeline qui fait le travail.

Elle se situe entre les deux façons existantes d’accomplir le travail :

Quand vous voulez…	Utilisez
Confier une tâche à un seul agent	Un message dans un espace
Encoder à la main un processus que vous connaissez déjà	Un modèle de pipeline
Énoncer l’objectif et laisser l’équipe établir le plan	Une orchestration

La forme d’une proposition

Lorsque vous donnez un objectif à l’orchestrateur, il renvoie une OrchestrationProposal structurée : un plan typé que l’application peut valider et exécuter, plutôt que de la prose libre. Une proposition comporte :

Objectif : votre demande globale, reformulée.
Rôles : qui fait le travail. Chaque rôle est soit un agent existant que vous choisissez, soit une nouvelle recrue que l’orchestration crée au moment de l’approbation.
Sous-tickets : le travail, décomposé en un DAG de tickets.
Recherche (facultatif) : une phase de recherche qui s’exécute en premier et alimente le reste.
Discussion (facultatif) : un tour délimité où chaque rôle publie une position structurée avant le début du travail.
Synthèse : l’étape finale qui produit le livrable.
Budget : un plafond de coût déclaré.

Où l’examiner

Deux surfaces montrent la même orchestration.

La carte de proposition vit dans la conversation qui a produit le plan. C’est un seul message qui se réaffiche tout au long du cycle de vie — proposé, en cours d’exécution, terminé — et qui porte les actions d’approbation et d’annulation.

Plan Studio est l’éditeur : un canevas DAG, un inspecteur de nœuds, un tiroir de révisions et de diffs et la barre d’approbation qui porte l’estimation. Il s’ouvre comme un onglet d’éditeur directement depuis cette carte. Il n’y a délibérément aucun élément « Plans » dans la barre latérale ; /plans et /plans/:kind/:id existent comme liens profonds pour le partage.

L’approbation est réservée aux opérateurs. Aucun outil MCP ne permet de le faire : un agent peut proposer (propose_orchestration), soumettre un plan (submit_plan) ou instancier un playbook (run_playbook), mais seul un humain approuve. Les révisions amorcées par un agent sont en outre limitées par un délai d’attente de deux minutes, de sorte qu’une boucle de replanification se regroupe au lieu d’inonder votre fil.

Ce que vous pouvez modifier avant d’approuver correspond à ce qu’expose l’inspecteur de nœuds : renommer ou réécrire un sous-ticket, changer le rôle qui en est responsable, recâbler ses dépendances, modifier son schéma de sortie ou supprimer le nœud purement et simplement. Les nœuds structurels (recherche, discussion, synthèse) et les nœuds déjà exécutés sont en lecture seule. Depuis l’éditeur, vous ne pouvez pas épingler un rôle à un agent nommé en particulier, ni modifier le budget.

Deux éditeurs sur un même plan sont départagés par concurrence optimiste, et non par fusion. Chaque modification porte la base_revision sur laquelle elle a été faite ; une modification fondée sur une révision obsolète est refusée par le message « the plan moved on » plutôt que d’écraser silencieusement celle d’une autre personne. Le retour en arrière n’est pas non plus une suppression : il ajoute la proposition plus ancienne en tant que nouvelle révision, de sorte que la chronologie des révisions ne fait que s’allonger.

Des estimations honnêtes, ou aucune

L’estimation de la barre d’approbation est construite à partir de l’historique réel des exécutions terminées pour chaque rôle, sous forme de fourchette interquartile (p25–p75). Le coût total additionne les nœuds estimables ; la durée correspond au chemin critique à travers le DAG plutôt qu’à la somme (les branches parallèles se chevauchent).

Un nœud dont le rôle n’a aucun historique d’exécutions terminées renvoie sampleSize: 0 et des plages nulles. Cela s’affiche exactement comme tel — inconnu — et jamais comme une valeur ponctuelle fabriquée, car une estimation à laquelle vous ne pouvez pas vous fier est pire qu’aucune estimation. Lorsque certains nœuds ont un historique et d’autres pas, le total est marqué comme partiel. Le rayon d’impact n’apparaît que lorsqu’un nœud a déclaré des références de provenance symbol ou file ; un nœud qui n’en a pas reste « inconnu » plutôt que d’être déduit de la prose.

Une seule approbation, puis une exécution déterministe

C’est l’idée centrale : l’agent planifie ; une fonction déterministe exécute. Lorsque vous approuvez, l’OrchestrationMaterializer, une fonction pure sans LLM ni E/S, convertit la proposition en un véritable pipeline. Pour une même proposition et des rôles résolus identiques, il produit toujours le même DAG. C’est important, car le pipeline généré hérite gratuitement de tout ce que le moteur fait déjà : la suspension et la reprise après redémarrage, la récupération après plantage, les cumuls de coût et de jetons par exécution et l’interface de détail d’exécution.

L’approbation crée aussi l’échafaudage dont le travail a besoin :

recrute les rôles marqués comme nouveaux (et consigne les identifiants des agents recrutés pour qu’un plantage en cours d’approbation puisse reprendre sans recruter en double)
une équipe qui regroupe les rôles
un projet qui classe le ticket parent
le modèle de pipeline + l’exécution qui pilotent l’ensemble

Le cycle de vie

proposed → approved → executing → synthesizing → completed
                  ↘                 ↘              failed
                   ↘                 ↘            cancelled

Statut	Signification
`proposed`	Le plan est prêt et attend votre unique approbation préalable
`approved`	Vous l’avez approuvé ; la matérialisation est en cours (recrutements, équipe, projet, pipeline)
`executing`	Le pipeline généré s’exécute : sous-tickets, discussion, travail
`synthesizing`	Les sous-tickets sont terminés ; l’étape de synthèse produit le livrable
`completed`	Terminé : le ticket parent est marqué comme terminé et le livrable est publié dans l’espace partagé
`failed`	La matérialisation a échoué, ou l’exécution du pipeline généré a échoué
`cancelled`	Vous l’avez annulé

Un numéro de révision monotone suit la proposition à mesure que l’orchestrateur la révise tant qu’elle est encore proposed ; l’application consigne la révision que vous avez approuvée. propose_orchestration refuse une révision dès que le statut n’est plus proposed.

Une orchestration s’ouvre toujours sur un ticket parent et partage un même espace de discussion, de sorte que tout l’effort reste traçable jusqu’à un seul élément de travail et que l’équipe discute dans un même lieu.

Ce qui se passe lorsqu’elle se termine

Un écouteur maintenu actif surveille le pipeline généré et reporte son état terminal sur l’orchestration et le ticket parent, de sorte que la réussite et l’échec apparaissent aux endroits que vous surveillez déjà. La fonctionnalité d’orchestration n’a pas besoin de son propre moteur d’exécution.

Vous pouvez annuler une orchestration à tout moment ; l’annulation démonte le travail en cours.

Voir aussi

Pipelines et automatisation : le moteur sur lequel s’exécute une orchestration matérialisée
Tickets et délégation : le ticket parent sur lequel une orchestration est ancrée
Le modèle d’agent : les rôles qu’une orchestration pourvoit ou recrute
Lancer une orchestration
Travailler dans Plan Studio