Orkestrering

En enkelt agent er god til én ting. Noen oppgaver er større enn som så: «undersøk markedet for X og skriv et posisjoneringsdokument», «lever denne funksjonen fra ende til annen», «revider denne modulen og rett det du finner». En orkestrering er hvordan Control Center håndterer slike: en orkestrator (vanligvis CEO-agenten din) foreslår en plan for hele teamet, du godkjenner den én gang, og en deterministisk materialisator gjør den om til en pipeline som utfører arbeidet.

Den ligger mellom de to eksisterende måtene å få arbeid utført på:

Når du vil …	Bruk
Gi én oppgave til én agent	En melding i et område
Kodifisere en prosess du allerede kjenner, for hånd	En pipeline-mal
Si målet og la teamet finne ut planen	En orkestrering

Formen på et forslag

Når du gir orkestratoren et mål, returnerer den en strukturert OrchestrationProposal: en typet plan appen kan validere og kjøre, i stedet for fri prosa. Et forslag har:

Mål: den overordnede oppgaven din, gjenfortalt.
Roller: hvem som gjør arbeidet. Hver rolle er enten en eksisterende agent du velger, eller en nyansatt som orkestreringen oppretter ved godkjenning.
Undersaker: arbeidet, brutt ned i en DAG av saker.
Forskning (valgfritt): en forskningsfase som kjører først og mater resten.
Diskusjon (valgfritt): en avgrenset runde der hver rolle legger fram en strukturert posisjon før arbeidet starter.
Syntese: det siste steget som produserer leveransen.
Budsjett: et oppgitt kostnadstak.

Hvor du gjennomgår den

To flater viser den samme orkestreringen.

Forslagskortet ligger i samtalen som produserte planen. Det er én melding som tegnes på nytt gjennom hele livssyklusen — foreslått, kjører, fullført — med handlingene for å godkjenne og avbryte på seg.

Plan Studio er redigeringsverktøyet: et DAG-lerret, en nodeinspektør, en revisjons- og diffskuff og godkjenningslinjen som viser estimatet. Det åpnes som en redigeringsfane rett fra kortet. Det finnes med vilje ingen «Planer»-oppføring i sidepanelet; /plans og /plans/:kind/:id finnes bare som dypelenker for deling.

Godkjenning er forbeholdt operatøren. Det finnes ikke noe MCP-verktøy for det: en agent kan foreslå (propose_orchestration), sende inn en plan (submit_plan) eller instansiere en playbook (run_playbook), men bare et menneske godkjenner. Agent-initierte revisjoner er i tillegg begrenset av en nedkjøling på to minutter, slik at en omplanleggingssløyfe samles opp i stedet for å oversvømme nyhetsstrømmen din.

Det du kan endre før du godkjenner, er det nodeinspektøren viser: gi en undersak ny tittel eller skriv den om, endre hvilken rolle som eier den, legge om avhengighetene, redigere utdataskjemaet eller slette noden helt. Strukturelle noder (forskning, diskusjon, syntese) og noder som allerede er kjørt, er skrivebeskyttet. Du kan ikke feste en rolle til en bestemt navngitt agent, og du kan ikke redigere budsjettet, fra redigeringsverktøyet.

To redaktører på én plan løses med optimistisk samtidighet, ikke sammenslåing. Hver redigering bærer base_revision den ble gjort mot; en redigering basert på en utdatert revisjon avvises med «planen har gått videre» i stedet for å overskrive noen andres i stillhet. Å spole tilbake er heller ikke en sletting — det legger til det eldre forslaget som en ny revisjon, så revisjonstidslinjen bare vokser.

Ærlige estimater, eller ingen

Estimatet i godkjenningslinjen bygges fra reell historikk fra fullførte kjøringer for hver rolle, som et interkvartilbånd (p25–p75). Kostnadstotalene summerer de estimebare nodene; varigheten er den kritiske stien gjennom DAG-en i stedet for summen (parallelle grener overlapper).

En node hvis rolle ikke har historikk fra fullførte kjøringer, rapporterer sampleSize: 0 og nullområder. Det vises som nettopp det — ukjent — aldri som en oppdiktet punktverdi, fordi et estimat du ikke kan stole på, er verre enn ikke noe estimat. Når noen noder har historikk og andre ikke, merkes totalen som delvis. Sprengningsradius vises bare når en node oppgir symbol- eller file-opphavsreferanser; en node uten dem forblir «ukjent» i stedet for å utledes fra prosaen.

Én godkjenning, deretter deterministisk kjøring

Dette er kjerneideen: agenten planlegger; en deterministisk funksjon utfører. Når du godkjenner, gjør OrchestrationMaterializer, en ren funksjon uten LLM og uten I/O, forslaget om til en ekte pipeline. Gitt det samme forslaget og de samme oppløste rollene produserer den alltid den samme DAG-en. Det er viktig fordi den genererte pipelinen arver alt motoren allerede gjør gratis: suspensjon og gjenopptakelse på tvers av omstarter, krasjgjenoppretting, kostnads- og tokenoppsummeringer per kjøring og brukergrensesnittet for kjøringsdetaljer.

Godkjenningen oppretter også stillaset arbeidet trenger:

ansetter alle roller merket som nye (og registrerer id-ene til de ansatte agentene, slik at et krasj midt i godkjenningen kan gjenopptas uten dupliserte ansettelser)
et team som grupperer rollene
et prosjekt som den overordnede saken plasseres i
pipeline-malen + kjøringen som driver alt sammen

Livssyklusen

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

Status	Betydning
`proposed`	Planen er klar og venter på din ene godkjenning på forhånd
`approved`	Du godkjente den; materialiseringen pågår (ansettelser, team, prosjekt, pipeline)
`executing`	Den genererte pipelinen kjører: undersaker, diskusjon, arbeid
`synthesizing`	Undersakene er ferdige; syntesesteget produserer leveransen
`completed`	Ferdig: den overordnede saken er merket som fullført, og leveransen er lagt ut i det delte området
`failed`	Materialiseringen mislyktes, eller kjøringen av den genererte pipelinen mislyktes
`cancelled`	Du avbrøt den

Et monotont revisjonsnummer sporer forslaget mens orkestratoren reviderer det så lenge det fortsatt er proposed; appen registrerer hvilken revisjon du godkjente. propose_orchestration avviser en revisjon når statusen ikke lenger er proposed.

En orkestrering åpnes alltid mot en overordnet sak og deler ett diskusjonsområde, slik at hele innsatsen kan spores til ett enkelt arbeidselement, og teamet snakker i ett rom.

Hva som skjer når den er ferdig

En lytter som holdes i live, følger den genererte pipelinen og mapper sluttilstanden tilbake til orkestreringen og den overordnede saken, slik at fullføring og feil dukker opp der du allerede følger med. Orkestreringsfunksjonen trenger ikke sin egen kjøringsmotor.

Du kan avbryte en orkestrering når som helst; avbruddet river ned arbeidet som er i gang.

Se også

Pipelines og automatisering: motoren en materialisert orkestrering kjører på
Saker og delegering: den overordnede saken en orkestrering er forankret i
Agentmodellen: rollene en orkestrering fyller eller ansetter
Kjør en orkestrering
Jobb i Plan Studio