Orchestrace

Jeden agent umí jednu věc. Některá zadání jsou větší: „prozkoumej trh X a napiš dokument k pozicování“, „doveď tuhle funkci od začátku do konce“, „projdi tenhle modul a oprav, co najdeš“. Orchestrace je způsob, jakým to Control Center řeší. Orchestrátor (obvykle tvůj agent CEO) navrhne plán pro celý tým, ty ho schválíš jednou a deterministický materializátor z něj udělá pipeline, která práci provede.

Leží mezi dvěma způsoby, kterými se práce zadává už teď:

Když chceš…	Použij
Předat jeden úkol jednomu agentovi	Zprávu v prostoru
Ručně zapsat proces, který už znáš	Šablonu pipeline
Říct cíl a nechat plán na týmu	Orchestraci

Podoba návrhu

Když orchestrátorovi dáš cíl, vrátí strukturovaný OrchestrationProposal: typovaný plán, který aplikace umí ověřit a spustit. Volný text to není. Návrh má:

Cíl: tvoje zadání na vysoké úrovni, přeformulované.
Role: kdo práci dělá. Každá role je buď existující agent, kterého vybereš, nebo nový nábor, kterého orchestrace při schválení založí.
Podřízené tickety: práce rozložená do DAGu ticketů.
Průzkum (volitelné): fáze, která proběhne první a zbytek plánu z ní čerpá.
Diskuse (volitelné): omezené kolo, v němž každá role před začátkem práce napíše strukturované stanovisko.
Syntéza: poslední krok, který vytvoří výstup.
Rozpočet: deklarovaný strop nákladů.

Kde ho kontroluješ

Stejnou orchestraci ukazují dvě plochy.

Karta návrhu žije v konverzaci, která plán vytvořila. Je to jedna zpráva, která se po celý životní cyklus překresluje — navrženo, provádění, hotovo — a nese akce schválení a zrušení.

Plan Studio je editor: plátno DAG, inspektor uzlu, zásuvka revizí a diffu a lišta schválení s odhadem. Z té karty se otevře rovnou jako karta editoru. V postranním panelu schválně není položka „Plány“. Cesty /plans a /plans/:kind/:id jsou přímé odkazy pro sdílení.

Schvalovat smí jen operátor. Nástroj MCP na to není: agent umí navrhnout (propose_orchestration), odeslat plán (submit_plan) nebo založit běh playbooku (run_playbook), schválit ale umí jen člověk. Revize, které spouští agent, navíc brzdí dvouminutová prodleva, takže smyčka přeplánování splyne do jedné aktualizace a kanál nezaplaví.

Než plán schválíš, změnit jde to, co ukáže inspektor uzlu: přejmenovat nebo přepsat podřízený ticket, změnit roli, která ho vlastní, přepojit jeho závislosti, upravit výstupní schéma, nebo uzel rovnou smazat. Strukturální uzly (průzkum, diskuse, syntéza) a uzly, které už proběhly, jsou jen ke čtení. Roli z editoru nepřipneš ke konkrétnímu pojmenovanému agentovi a rozpočet odtud neupravíš.

Dva editory jednoho plánu drží optimistická souběžnost, ne slučování. Každá úprava nese base_revision, ze které vyšla. Úprava ze zastaralé revize se odmítne hláškou „the plan moved on“ a cizí změnu potichu nepřepíše. Ani přetočení nic nemaže. Starší návrh se připojí jako nová revize, takže časová osa revizí jen roste.

Poctivý odhad, nebo žádný

Odhad na liště schválení se staví ze skutečné historie dokončených běhů dané role, jako mezikvartilové pásmo (p25–p75). Součty nákladů sčítají uzly, které jdou odhadnout. Trvání je kritická cesta skrz DAG, ne součet, protože paralelní větve se překrývají.

Uzel, jehož role nemá historii dokončených běhů, hlásí sampleSize: 0 a rozsahy null. Vykreslí se to jako neznámé, ne jako vymyšlené číslo. Odhad, kterému nejde věřit, je horší než žádný. Když část uzlů historii má a část ne, součet se označí jako částečný. Dosah dopadu se ukáže jen u uzlu, který deklaroval odkazy na původ symbol nebo file. Uzel bez nich zůstane „neznámý“ a z textu se nic nedovozuje.

Jedno schválení, pak deterministické provedení

Jádro je tohle: plánuje agent, provádí deterministická funkce. Když schválíš, OrchestrationMaterializer, čistá funkce bez LLM a bez I/O, převede návrh na skutečnou pipeline. Ze stejného návrhu a stejných vyřešených rolí vyjde vždy stejný DAG. Na tom záleží, protože vygenerovaná pipeline zdarma zdědí, co engine už umí: pozastavení a obnovení přes restart, zotavení po pádu, souhrny nákladů a tokenů za běh a rozhraní detailu běhu.

Schválení taky postaví kostru, kterou práce potřebuje:

najme role označené jako nové (a zapíše id najatých agentů, aby se pád uprostřed schválení dal obnovit bez duplicitních náborů)
tým, který role sdruží
projekt, do kterého se založí nadřazený ticket
šablonu pipeline a běh, které to celé pohánějí

Životní cyklus

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

Stav	Význam
`proposed`	Plán je připravený a čeká na tvoje jediné schválení předem
`approved`	Schválil jsi ho; probíhá materializace (nábory, tým, projekt, pipeline)
`executing`	Vygenerovaná pipeline běží: podřízené tickety, diskuse, práce
`synthesizing`	Podřízené tickety jsou hotové; krok syntézy tvoří výstup
`completed`	Hotovo: nadřazený ticket je dokončený a výstup je zveřejněný ve sdíleném prostoru
`failed`	Materializace selhala, nebo selhal běh vygenerované pipeline
`cancelled`	Zrušil jsi ji

Monotónní číslo revize sleduje návrh, dokud ho orchestrátor upravuje a stav je pořád proposed. Aplikace si zapíše, kterou revizi jsi schválil. propose_orchestration revizi odmítne, jakmile stav už není proposed.

Orchestrace se vždy otevře proti nadřazenému ticketu a sdílí jeden diskusní prostor. Celé úsilí tak vede k jedné položce práce a tým mluví v jedné místnosti.

Co se stane, když skončí

Posluchač, který se po startu neodpojí, sleduje vygenerovanou pipeline a její konečný stav promítne zpět na orchestraci i nadřazený ticket. Dokončení a selhání se tak ukážou na místech, která už sleduješ. Orchestrace proto nepotřebuje vlastní vykonávací engine.

Orchestraci můžeš kdykoli zrušit. Zrušení strhne práci, která právě běží.

Viz také

Pipelines a automatizace: engine, na kterém běží zmaterializovaná orchestrace
Tickety a delegování: nadřazený ticket, ke kterému je orchestrace ukotvená
Model agentů: role, které orchestrace obsadí nebo najme
Spusťte orchestraci
Pracujte v Plan Studio