Orchestrare

Un singur agent este bun la un singur lucru. Unele cereri sunt mai mari de atât: „cercetează piața pentru X și scrie un document de poziționare”, „livrează această funcționalitate de la un capăt la altul”, „auditează acest modul și repară ce găsești”. O orchestrare este modul în care Control Center le tratează: un orchestrator (de obicei agentul tău CEO) propune un plan pentru toată echipa, îl aprobi o singură dată, iar un materializator determinist îl transformă într-un pipeline care face munca.

Se situează între cele două moduri existente de a face munca:

Când vrei să…	Folosește
Dai o singură sarcină unui singur agent	Un mesaj într-un spațiu
Codifici manual un proces pe care îl știi deja	Un șablon de pipeline
Spui obiectivul și lași echipa să stabilească planul	O orchestrare

Cum arată o propunere

Când îi dai orchestratorului un obiectiv, acesta returnează un OrchestrationProposal structurat: un plan tipizat pe care aplicația îl poate valida și executa, în loc de proză liberă. O propunere are:

Obiectiv: cererea ta de nivel înalt, reformulată.
Roluri: cine face munca. Fiecare rol este fie un agent existent pe care îl alegi, fie o angajare nouă pe care orchestrarea o creează la aprobare.
Sub-tichete: munca, împărțită într-un DAG de tichete.
Cercetare (opțional): o fază de cercetare care rulează prima și alimentează restul.
Discuție (opțional): o rundă delimitată în care fiecare rol publică o poziție structurată înainte de începerea muncii.
Sinteză: pasul final care produce livrabilul.
Buget: un plafon de cost declarat.

Unde îl revizuiești

Două suprafețe afișează aceeași orchestrare.

Cardul propunerii trăiește în conversația care a produs planul. Este un singur mesaj care se randează din nou pe tot parcursul ciclului de viață — propus, se execută, finalizat — cu acțiunile de aprobare și anulare pe el.

Plan Studio este editorul: un canvas DAG, un inspector de noduri, un sertar de revizii și diff-uri și bara de aprobare care poartă estimarea. Se deschide ca un tab de editor direct din acel card. Nu există în mod deliberat un element „Planuri” în bara laterală; /plans și /plans/:kind/:id există ca linkuri directe pentru partajare.

Aprobarea este doar pentru operatori. Nu există un instrument MCP pentru ea: un agent poate propune (propose_orchestration), poate trimite un plan (submit_plan) sau poate instanția un playbook (run_playbook), dar doar un om aprobă. Reviziile inițiate de agenți sunt în plus limitate ca frecvență printr-o perioadă de așteptare de două minute, astfel încât o buclă de replanificare se contopește în loc să îți inunde fluxul.

Ce poți schimba înainte de aprobare este exact ce expune inspectorul de noduri: schimbi titlul sau rescrii un sub-tichet, schimbi care rol îl deține, reconfigurezi dependențele lui, editezi schema lui de ieșire sau ștergi nodul complet. Nodurile structurale (cercetare, discuție, sinteză) și nodurile care au fost deja executate sunt doar în citire. Nu poți fixa un rol pe un anumit agent anume și nu poți edita bugetul, din editor.

Doi editori pe un singur plan se rezolvă prin concurență optimistă, nu prin fuzionare. Fiecare editare poartă base_revision față de care a fost făcută; o editare bazată pe o revizie învechită este refuzată cu „planul a avansat”, în loc să suprascrie în tăcere munca altcuiva. Nici derularea înapoi nu este o ștergere — adaugă propunerea mai veche ca revizie nouă, astfel încât cronologia reviziilor doar crește.

Estimări sincere sau deloc

Estimarea din bara de aprobare este construită din istoricul real al rulărilor finalizate pentru fiecare rol, ca interval intercuartilic (p25–p75). Totalurile de cost însumează nodurile estimabile; durata este calea critică prin DAG, nu suma (ramurile paralele se suprapun).

Un nod al cărui rol nu are istoric de rulări finalizate raportează sampleSize: 0 și intervale null. Asta se afișează exact așa — necunoscut —, niciodată ca o valoare punctuală fabricată, pentru că o estimare în care nu poți avea încredere este mai rea decât nicio estimare. Când unele noduri au istoric și altele nu, totalul este marcat ca parțial. Raza de impact apare doar când un nod a declarat referințe de proveniență symbol sau file; un nod fără ele rămâne „necunoscut” în loc să deducă din proză.

O singură aprobare, apoi execuție deterministă

Aceasta este ideea centrală: agentul planifică; o funcție deterministă execută. Când aprobi, OrchestrationMaterializer, o funcție pură, fără LLM și fără I/O, transformă propunerea într-un pipeline real. Având aceeași propunere și aceleași roluri rezolvate, produce întotdeauna același DAG. Asta contează pentru că pipeline-ul generat moștenește tot ce face deja motorul gratuit: suspendare și reluare între reporniri, recuperare după crash, totaluri de cost și tokenuri pe rulare și interfața de detalii a rulării.

Aprobarea creează și structura de suport de care are nevoie munca:

angajează orice roluri marcate ca noi (și înregistrează id-urile agenților angajați, astfel încât un crash la mijlocul aprobării să poată relua fără angajări duplicate)
o echipă care grupează rolurile
un proiect care înregistrează tichetul părinte
șablonul de pipeline + rularea care le pune pe toate în mișcare

Ciclul de viață

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

Stare	Semnificație
`proposed`	Planul este gata și așteaptă singura ta aprobare inițială
`approved`	L-ai aprobat; materializarea este în curs (angajări, echipă, proiect, pipeline)
`executing`	Pipeline-ul generat rulează: sub-tichete, discuție, muncă
`synthesizing`	Sub-tichetele sunt gata; pasul de sinteză produce livrabilul
`completed`	Gata: tichetul părinte este marcat ca finalizat, iar livrabilul este publicat în spațiul comun
`failed`	Materializarea a eșuat sau rularea pipeline-ului generat a eșuat
`cancelled`	L-ai anulat

Un număr de revizie monoton urmărește propunerea pe măsură ce orchestratorul o revizuiește cât timp aceasta este încă proposed; aplicația înregistrează ce revizie ai aprobat. propose_orchestration refuză o revizie odată ce starea nu mai este proposed.

O orchestrare se deschide întotdeauna față de un tichet părinte și partajează un singur spațiu de discuție, astfel încât întregul efort este trasabil până la un singur element de lucru, iar echipa vorbește într-o singură cameră.

Ce se întâmplă când se termină

Un ascultător menținut activ urmărește pipeline-ul generat și mapează starea lui terminală înapoi pe orchestrare și pe tichetul părinte, astfel încât finalizarea și eșecul apar în locurile pe care le urmărești deja. Funcționalitatea de orchestrare nu are nevoie de propriul motor de execuție.

Poți anula o orchestrare oricând; anularea desființează munca în curs.

Vezi și

Pipeline-uri și automatizare: motorul pe care rulează o orchestrare materializată
Tichete și delegare: tichetul părinte pe care este ancorată o orchestrare
Modelul agenților: rolurile pe care o orchestrare le completează sau le angajează
Rulează o orchestrare
Lucrează în Plan Studio