Orchestrazione

Un singolo agente è bravo in una cosa sola. Alcune richieste sono più grandi di così: “studia il mercato di X e scrivi un documento di posizionamento”, “porta questa funzionalità dalla prima riga alla produzione”, “analizza questo modulo e correggi quello che trovi”. Un’orchestrazione è il modo in cui Control Center gestisce richieste del genere: un orchestratore (di solito il tuo agente CEO) propone un piano per tutto il team, tu lo approvi una volta sola e un materializzatore deterministico lo trasforma in una pipeline che fa il lavoro.

Sta in mezzo ai due modi esistenti di far fare il lavoro:

Quando vuoi…	Usa
Assegnare un’attività a un singolo agente	Un messaggio in uno spazio
Codificare a mano un processo che già conosci	Un modello di pipeline
Dire l’obiettivo e lasciare che il team trovi il piano	Un’orchestrazione

La forma di una proposta

Quando dai un obiettivo all’orchestratore, questo restituisce un OrchestrationProposal strutturato: un piano tipizzato che l’app può convalidare ed eseguire, invece che prosa libera. Una proposta contiene:

Obiettivo: la tua richiesta di alto livello, riformulata.
Ruoli: chi fa il lavoro. Ogni ruolo è un agente esistente che scegli tu, oppure una nuova assunzione che l’orchestrazione crea al momento dell’approvazione.
Sotto-ticket: il lavoro, suddiviso in un DAG di ticket.
Ricerca (opzionale): una fase di ricerca che parte per prima e alimenta il resto.
Discussione (opzionale): un giro circoscritto in cui ogni ruolo pubblica una posizione strutturata prima che il lavoro inizi.
Sintesi: il passo finale che produce il risultato.
Budget: un tetto di costo dichiarato.

Dove la rivedi

Due superfici mostrano la stessa orchestrazione.

La scheda della proposta vive nella conversazione che ha prodotto il piano. È un unico messaggio che si ridisegna lungo tutto il ciclo di vita — proposto, in esecuzione, completato — con le azioni di approvazione e annullamento direttamente su di esso.

Plan Studio è l’editor: un canvas DAG, un pannello di ispezione dei nodi, un cassetto delle revisioni e dei diff e la barra di approvazione che porta la stima. Si apre come scheda dell’editor direttamente dalla scheda della proposta. Non c’è deliberatamente alcuna voce “Piani” nella barra laterale; /plans e /plans/:kind/:id esistono come link diretti da condividere.

L’approvazione è riservata agli operatori. Non esiste uno strumento MCP per farlo: un agente può proporre (propose_orchestration), inviare un piano (submit_plan) o istanziare un playbook (run_playbook), ma solo un umano approva. Le revisioni avviate da un agente sono inoltre limitate da un cooldown di due minuti, così un ciclo di ripianificazione si accorpa invece di inondare il tuo feed.

Ciò che puoi modificare prima di approvare è esattamente ciò che espone il pannello di ispezione dei nodi: cambiare il titolo o riscrivere un sotto-ticket, cambiare quale ruolo lo possiede, ricollegarne le dipendenze, modificarne lo schema di output o eliminare del tutto il nodo. I nodi strutturali (ricerca, discussione, sintesi) e i nodi già eseguiti sono di sola lettura. Dall’editor non puoi associare un ruolo a un agente specifico per nome, né modificare il budget.

La presenza di due editor sullo stesso piano si risolve con la concorrenza ottimistica, non con una fusione. Ogni modifica porta con sé la base_revision su cui è stata fatta; una modifica basata su una revisione superata viene rifiutata con “il piano è cambiato”, invece di sovrascrivere in silenzio quella di qualcun altro. Anche il riavvolgimento non è un’eliminazione: aggiunge la proposta più vecchia come nuova revisione, così la cronologia delle revisioni può solo crescere.

Stime oneste, o nessuna

La stima sulla barra di approvazione è costruita a partire dallo storico reale delle esecuzioni completate per ogni ruolo, come fascia interquartile (p25–p75). I costi totali sommano i nodi stimabili; la durata è il percorso critico attraverso il DAG e non la somma (i rami paralleli si sovrappongono).

Un nodo il cui ruolo non ha esecuzioni completate nello storico riporta sampleSize: 0 e intervalli nulli. Il rendering è esattamente quello — sconosciuto — e mai un valore puntuale inventato, perché una stima di cui non ti puoi fidare è peggio di nessuna stima. Quando alcuni nodi hanno storico e altri no, il totale è contrassegnato come parziale. Il raggio d’impatto compare solo quando un nodo ha dichiarato riferimenti di provenienza symbol o file; un nodo che non li ha resta “sconosciuto” invece di dedurli dalla prosa.

Una sola approvazione, poi esecuzione deterministica

Questa è l’idea centrale: l’agente pianifica; una funzione deterministica esegue. Quando approvi, OrchestrationMaterializer, una funzione pura senza LLM e senza I/O, converte la proposta in una vera pipeline. A parità di proposta e di ruoli risolti, produce sempre lo stesso DAG. Questo conta perché la pipeline generata eredita gratis tutto ciò che il motore già fa: sospensione e ripresa tra un riavvio e l’altro, ripristino dopo un crash, riepiloghi di costi e token per esecuzione e l’interfaccia di dettaglio dell’esecuzione.

L’approvazione crea anche l’impalcatura che serve al lavoro:

assume i ruoli contrassegnati come nuovi (e registra gli id degli agenti assunti, così un crash durante l’approvazione può riprendere senza assunzioni duplicate)
un team che raggruppa i ruoli
un progetto in cui viene archiviato il ticket padre
il modello di pipeline + l’esecuzione che guida tutto il resto

Il ciclo di vita

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

Stato	Significato
`proposed`	Il piano è pronto e attende la tua unica approvazione iniziale
`approved`	L’hai approvato; la materializzazione è in corso (assunzioni, team, progetto, pipeline)
`executing`	La pipeline generata è in esecuzione: sotto-ticket, discussione, lavoro
`synthesizing`	I sotto-ticket sono finiti; il passo di sintesi sta producendo il risultato
`completed`	Fatto: il ticket padre è contrassegnato come completato e il risultato è pubblicato nello spazio condiviso
`failed`	La materializzazione non è riuscita, oppure l’esecuzione della pipeline generata è fallita
`cancelled`	L’hai annullato

Un numero di revisione monotono tiene traccia della proposta mentre l’orchestratore la rivede finché è ancora proposed; l’app registra quale revisione hai approvato. propose_orchestration rifiuta una revisione quando lo stato non è più proposed.

Un’orchestrazione si apre sempre su un ticket padre e condivide un unico spazio di discussione, così l’intero impegno è riconducibile a un singolo elemento di lavoro e il team parla in una sola stanza.

Cosa succede quando finisce

Un listener mantenuto in vita osserva la pipeline generata e mappa il suo stato terminale di nuovo sull’orchestrazione e sul ticket padre, così il completamento e il fallimento emergono nei posti che già tieni d’occhio. La funzionalità di orchestrazione non ha bisogno di un proprio motore di esecuzione.

Puoi annullare un’orchestrazione in qualsiasi momento; l’annullamento smonta il lavoro in corso.

Vedi anche

Pipeline e automazione: il motore su cui gira un’orchestrazione materializzata
Ticket e delega: il ticket padre su cui è ancorata un’orchestrazione
Il modello degli agenti: i ruoli che un’orchestrazione ricopre o assume
Esegui un’orchestrazione
Lavora in Plan Studio