Orkestrering

En enskild agent är bra på en sak. Vissa förfrågningar är större än så: “undersök marknaden för X och skriv ett positioneringsdokument”, “leverera den här funktionen från början till slut”, “granska den här modulen och åtgärda det du hittar”. En orkestrering är hur Control Center hanterar sådana: en orkestrerare (oftast din CEO-agent) föreslår en plan för hela teamet, du godkänner den en gång och en deterministisk materialiserare omvandlar den till en pipeline som utför arbetet.

Den ligger mellan de två befintliga sätten att få arbete utfört:

När du vill…	Använd
Ge en uppgift till en agent	Ett meddelande i en yta
Koda en process du redan känner till, för hand	En pipelinemall
Ange målet och låt teamet lista ut planen	En orkestrering

Så är ett förslag uppbyggt

När du ger orkestreraren ett mål returnerar den ett strukturerat OrchestrationProposal: en typad plan som appen kan validera och köra, i stället för fri prosa. Ett förslag innehåller:

Mål: din övergripande förfrågan, omformulerad.
Roller: vilka som gör arbetet. Varje roll är antingen en befintlig agent som du väljer, eller en ny anställd som orkestreringen skapar vid godkännandet.
Underärenden: arbetet, uppdelat i en DAG av ärenden.
Forskning (valfritt): en forskningsfas som körs först och matar resten.
Diskussion (valfritt): en avgränsad omgång där varje roll lägger fram en strukturerad position innan arbetet börjar.
Syntes: det sista steget som producerar leveransen.
Budget: ett deklarerat kostnadstak.

Var du granskar den

Samma orkestrering visas på två ställen.

Förslagskortet finns i samtalet som tog fram planen. Det är ett enda meddelande som renderas om genom hela livscykeln – föreslagen, körs, slutförd – med åtgärderna godkänn och avbryt på sig.

Plan Studio är redigeraren: en DAG-duk, en nodinspektör, en låda för revisioner och diffar och godkännandefältet med uppskattningen. Den öppnas som en flik i redigeraren direkt från kortet. Det finns medvetet inget “Planer”-objekt i sidomenyn; /plans och /plans/:kind/:id finns som djuplänkar för delning.

Att godkänna är förbehållet en operatör. Det finns inget MCP-verktyg för det: en agent kan föreslå (propose_orchestration), skicka in en plan (submit_plan) eller instansiera en playbook (run_playbook), men bara en människa godkänner. Agentinitierade revisioner begränsas dessutom av en nedkylningsperiod på två minuter, så en omplaneringsslinga slås samman i stället för att översvämma ditt flöde.

Det du kan ändra innan du godkänner är det som nodinspektören visar: byta namn på eller skriva om ett underärende, ändra vilken roll som äger det, koppla om dess beroenden, redigera dess utdataschema eller ta bort noden helt. Strukturella noder (forskning, diskussion, syntes) och noder som redan har körts är skrivskyddade. Du kan inte låsa en roll till en specifik namngiven agent och du kan inte redigera budgeten från redigeraren.

Att två redigerare arbetar med samma plan löses med optimistisk samtidighetskontroll, inte sammanslagning. Varje redigering bär den base_revision den gjordes mot; en redigering som bygger på en inaktuell revision avvisas med “planen har gått vidare” i stället för att tyst skriva över någon annans. Att spola tillbaka är inte heller en borttagning – det lägger till det äldre förslaget som en ny revision, så revisionstidslinjen växer bara.

Ärliga uppskattningar, eller inga

Uppskattningen i godkännandefältet byggs från verklig historik över slutförda körningar för varje roll, som ett interkvartilband (p25–p75). Kostnadstotaler summerar de noder som går att uppskatta; varaktigheten är den kritiska vägen genom DAG:en i stället för summan (parallella grenar överlappar).

En nod vars roll inte har någon historik över slutförda körningar rapporterar sampleSize: 0 och null-intervall. Det visas som just det – okänt – aldrig som ett påhittat punktvärde, eftersom en uppskattning du inte kan lita på är sämre än ingen uppskattning. När vissa noder har historik och andra inte markeras summan som delvis. Spridningsradie visas bara när en nod har deklarerat symbol- eller file-härkomstreferenser; en nod utan dem förblir “okänd” i stället för att gissa utifrån prosa.

Ett godkännande, sedan deterministisk körning

Det här är kärnidén: agenten planerar; en deterministisk funktion kör. När du godkänner omvandlar OrchestrationMaterializer, en ren funktion utan LLM och utan I/O, förslaget till en riktig pipeline. Givet samma förslag och samma upplösta roller producerar den alltid samma DAG. Det spelar roll eftersom den genererade pipelinen ärver allt motorn redan gör gratis: avbrott och återupptagning över omstarter, återhämtning efter krascher, kostnads- och tokensammanställningar per körning och körningsdetaljvyn.

Godkännandet skapar också den stomme arbetet behöver:

anställer alla roller som markerats som nya (och registrerar id:n för de anställda agenterna så att en krasch mitt i godkännandet kan återupptas utan dubbelanställningar)
ett team som grupperar rollerna
ett projekt som registrerar föräldraärendet
pipelinemallen + körningen som driver allt

Livscykeln

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

Status	Betydelse
`proposed`	Planen är klar och väntar på ditt enda förhandsgodkännande
`approved`	Du godkände den; materialiseringen pågår (anställningar, team, projekt, pipeline)
`executing`	Den genererade pipelinen körs: underärenden, diskussion, arbete
`synthesizing`	Underärendena är klara; syntessteget producerar leveransen
`completed`	Klart: föräldraärendet markeras som slutfört och leveransen publiceras i den delade ytan
`failed`	Materialiseringen misslyckades, eller körningen av den genererade pipelinen misslyckades
`cancelled`	Du avbröt den

Ett monotont revisionsnummer följer förslaget medan orkestreraren reviderar det så länge statusen fortfarande är proposed; appen registrerar vilken revision du godkände. propose_orchestration avvisar en revision när statusen inte längre är proposed.

En orkestrering öppnas alltid mot ett föräldraärende och delar en diskussionsyta, så att hela insatsen går att spåra till ett enda arbetsmoment och teamet pratar i ett och samma rum.

Vad som händer när den är klar

En lyssnare som hålls vid liv bevakar den genererade pipelinen och mappar dess slutstatus tillbaka till orkestreringen och föräldraärendet, så att slutförande och misslyckande syns på de ställen du redan bevakar. Orkestreringsfunktionen behöver ingen egen körningsmotor.

Du kan avbryta en orkestrering när som helst; avbrottet river ner arbetet som pågår.

Se även

Pipelines och automatisering: motorn som en materialiserad orkestrering körs på
Ärenden och delegering: föräldraärendet som en orkestrering är förankrad i
Agentmodellen: rollerna som en orkestrering fyller eller anställer
Kör en orkestrering
Arbeta i Plan Studio