Orchestration

Un seul agent est bon pour une chose. Certaines demandes dépassent cela : “é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 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érialisateur déterministe le transforme en un pipeline qui fait le travail.

Elle se situe entre les deux façons existantes d’accomplir du 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 embauche que l’orchestration crée à l’approbation.
Sous-tickets : le travail, décomposé en un DAG de tickets.
Recherche (facultatif) : une phase de recherche qui s’exécute d’abord et alimente le reste.
Discussion (facultatif) : une ronde délimitée 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 affichent 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 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évision et de diff et la barre d’approbation qui porte l’estimation. Il s’ouvre comme un onglet d’éditeur directement à partir de 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. Il n’existe aucun outil MCP pour cela : 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 soumises à un délai de refroidissement 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 carrément. Les nœuds structurels (recherche, discussion, synthèse) et les nœuds qui se sont déjà exécutés sont en lecture seule. Depuis l’éditeur, vous ne pouvez pas épingler un rôle à un agent nommé précis, ni modifier le budget.

La présence de deux éditeurs sur un même plan se règle 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 périmée est refusée avec “le plan a évolué” 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 comme nouvelle révision, de sorte que la chronologie des révisions ne fait que croître.

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 d’intervalle 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 indique sampleSize: 0 et des plages nulles. Cela s’affiche exactement comme tel — inconnu — et jamais comme une valeur ponctuelle fabriquée, parce qu’une estimation à laquelle vous ne pouvez pas vous fier est pire que pas d’estimation du tout. Lorsque certains nœuds ont un historique et d’autres non, le total est marqué 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 à partir 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, le 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 parce que 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ûts 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 :

embauche les rôles marqués comme nouveaux (et consigne les identifiants des agents embauchés pour qu’un plantage en cours d’approbation puisse reprendre sans embauches 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 (embauches, é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 est traçable jusqu’à un seul élément de travail et que l’équipe discute dans un même endroit.

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 embauche
Lancer une orchestration
Travailler dans Plan Studio