Orkestratie

Eén agent is goed in één ding. Sommige vragen zijn groter dan dat: “onderzoek de markt voor X en schrijf een positioneringsdocument”, “lever deze feature end to end op”, “audit deze module en los op wat je vindt”. Een orkestratie is hoe Control Center daarmee omgaat: een orchestrator (meestal je CEO-agent) stelt een plan voor het hele team voor, jij keurt het één keer goed en een deterministische materializer zet het om in een pipeline die het werk doet.

Het staat tussen de twee bestaande manieren om werk gedaan te krijgen:

Als je wilt…	Gebruik
Eén taak aan één agent geven	Een bericht in een ruimte
Een proces dat je al kent, handmatig vastleggen	Een pipeline-sjabloon
Het doel noemen en het team het plan laten bepalen	Een orkestratie

De vorm van een voorstel

Wanneer je de orchestrator een doel geeft, levert die een gestructureerd OrchestrationProposal op: een getypeerd plan dat de app kan valideren en uitvoeren, in plaats van vrije tekst. Een voorstel heeft:

Doel: je vraag op hoofdlijnen, opnieuw geformuleerd.
Rollen: wie het werk doet. Elke rol is ofwel een bestaande agent die je kiest, ofwel een nieuwe aanstelling die de orkestratie bij goedkeuring aanmaakt.
Subtickets: het werk, opgesplitst in een DAG van tickets.
Onderzoek (optioneel): een onderzoeksfase die eerst draait en de rest voedt.
Discussie (optioneel): een afgebakende ronde waarin elke rol een gestructureerd standpunt plaatst voordat het werk begint.
Synthese: de laatste stap die het eindresultaat oplevert.
Budget: een opgegeven kostengrens.

Waar je het beoordeelt

Twee oppervlakken tonen dezelfde orkestratie.

De voorstelkaart staat in het gesprek dat het plan heeft opgeleverd. Het is één bericht dat gedurende de hele levenscyclus opnieuw wordt weergegeven — voorgesteld, in uitvoering, voltooid — met daarop de acties voor goedkeuren en annuleren.

Plan Studio is de editor: een DAG-canvas, een knooppuntinspecteur, een lade met revisies en diffs en de goedkeuringsbalk met de schatting. Het opent als een editortab rechtstreeks vanuit die kaart. Er staat bewust geen “Plannen”-item in de zijbalk; /plans en /plans/:kind/:id bestaan als deeplinks om te delen.

Goedkeuren is alleen voor operators. Er is geen MCP-tool voor: een agent kan een voorstel doen (propose_orchestration), een plan indienen (submit_plan) of een playbook instantiëren (run_playbook), maar alleen een mens keurt goed. Door een agent gestarte revisies krijgen daarnaast een snelheidslimiet met een afkoelperiode van twee minuten, zodat een herplanningslus wordt gebundeld in plaats van je feed te overspoelen.

Wat je vóór het goedkeuren kunt wijzigen, is wat de knooppuntinspecteur toont: een subticket een andere titel geven of herschrijven, wijzigen welke rol eigenaar is, de afhankelijkheden opnieuw bedraden, het uitvoerschema bewerken of het knooppunt helemaal verwijderen. Structurele knooppunten (onderzoek, discussie, synthese) en knooppunten die al zijn uitgevoerd, zijn alleen-lezen. Je kunt een rol niet vastpinnen op een specifieke, met naam genoemde agent en je kunt het budget niet bewerken, vanuit de editor.

Twee editors op één plan worden opgelost met optimistische concurrency, niet door samen te voegen. Elke bewerking draagt de base_revision waartegen hij is gemaakt; een bewerking op basis van een verouderde revisie wordt geweigerd met “the plan moved on” in plaats van die van iemand anders stilzwijgend te overschrijven. Terugspoelen is ook geen verwijderen — het voegt het oudere voorstel toe als een nieuwe revisie, dus de tijdlijn met revisies groeit alleen maar.

Eerlijke schattingen, of geen

De schatting op de goedkeuringsbalk is opgebouwd uit de echte geschiedenis van voltooide runs per rol, als een interkwartielband (p25–p75). Kostentotalen tellen de schatbare knooppunten op; de duur is het kritieke pad door de DAG in plaats van de som (parallelle takken overlappen elkaar).

Een knooppunt waarvan de rol geen geschiedenis van voltooide runs heeft, rapporteert sampleSize: 0 en null-bereiken. Dat wordt precies zo weergegeven — onbekend — en nooit als een verzonnen puntwaarde, want een schatting die je niet kunt vertrouwen is erger dan geen schatting. Wanneer sommige knooppunten wel geschiedenis hebben en andere niet, wordt het totaal als gedeeltelijk gemarkeerd. De impactstraal verschijnt alleen wanneer een knooppunt symbol- of file-provenancerefs heeft opgegeven; een knooppunt zonder die refs blijft “onbekend” in plaats van iets af te leiden uit lopende tekst.

Eén goedkeuring, dan deterministische uitvoering

Dit is het kernidee: de agent plant; een deterministische functie voert uit. Wanneer je goedkeurt, zet de OrchestrationMaterializer, een pure functie zonder LLM en zonder I/O, het voorstel om in een echte pipeline. Met hetzelfde voorstel en dezelfde vastgestelde rollen levert hij altijd dezelfde DAG op. Dat is belangrijk omdat de gegenereerde pipeline alles erft wat de engine al gratis doet: opschorten en hervatten over herstarts heen, herstel na crashes, kosten- en tokentotalen per run en de interface met run-details.

Goedkeuring maakt ook de structuur aan die het werk nodig heeft:

nieuwe aanstellingen voor alle rollen die als nieuw zijn gemarkeerd (en het vastleggen van de id’s van de aangenomen agents, zodat een crash halverwege de goedkeuring kan hervatten zonder dubbele aanstellingen)
een team dat de rollen groepeert
een project waarin het bovenliggende ticket wordt ondergebracht
het pipeline-sjabloon + de run die alles aansturen

De levenscyclus

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

Status	Betekenis
`proposed`	Het plan is klaar en wacht op je enige goedkeuring vooraf
`approved`	Je hebt het goedgekeurd; de materialisatie is bezig (aanstellingen, team, project, pipeline)
`executing`	De gegenereerde pipeline draait: subtickets, discussie, werk
`synthesizing`	De subtickets zijn klaar; de synthesestap levert het eindresultaat op
`completed`	Klaar: het bovenliggende ticket is als voltooid gemarkeerd en het eindresultaat staat in de gedeelde ruimte
`failed`	De materialisatie is mislukt, of de run van de gegenereerde pipeline is mislukt
`cancelled`	Je hebt de orkestratie geannuleerd

Een monotoon revisienummer volgt het voorstel terwijl de orchestrator het herziet zolang de status nog proposed is; de app legt vast welke revisie je hebt goedgekeurd. propose_orchestration weigert een revisie zodra de status niet meer proposed is.

Een orkestratie opent altijd tegen een bovenliggend ticket en deelt één ruimte voor de discussie, zodat de hele inspanning herleidbaar is tot één werkitem en het team in één ruimte praat.

Wat er gebeurt als het klaar is

Een permanent actieve listener houdt de gegenereerde pipeline in de gaten en vertaalt de eindtoestand terug naar de orkestratie en het bovenliggende ticket, zodat voltooiing en mislukking opduiken op de plekken die je al volgt. De orkestratiefunctie heeft geen eigen uitvoeringsengine nodig.

Je kunt een orkestratie op elk moment annuleren; het annuleren breekt het werk af dat nog loopt.

Zie ook

Pipelines en automatisering: de engine waarop een gematerialiseerde orkestratie draait
Tickets en delegatie: het bovenliggende ticket waarop een orkestratie is verankerd
Het agentmodel: de rollen die een orkestratie invult of aanwerft
Een orkestratie uitvoeren
Werken in Plan Studio