Orchestration

Acest conținut nu este încă disponibil în limba selectată.

A single agent is good at one thing. Some asks are bigger than that: “research the market for X and write a positioning doc”, “ship this feature end to end”, “audit this module and fix what you find”. An orchestration is how Control Center handles those: an orchestrator (usually your CEO agent) proposes a whole-team plan, you approve it once and a deterministic materializer turns it into a pipeline that does the work.

It sits between the two existing ways of getting work done:

When you want to…	Use
Hand one task to one agent	A message in a space
Encode a process you already know, by hand	A pipeline template
Say the goal and let the team figure out the plan	An orchestration

The shape of a proposal

When you give the orchestrator a goal, it returns a structured OrchestrationProposal: a typed plan the app can validate and execute, rather than free-form prose. A proposal has:

Goal: your high-level ask, restated.
Roles: who does the work. Each role is either an existing agent you pick, or a new hire the orchestration creates on approval.
Sub-tickets: the work, broken into a DAG of tickets.
Research (optional): a research phase that runs first and feeds the rest.
Discussion (optional): a bounded round where each role posts a structured position before work begins.
Synthesis: the final step that produces the deliverable.
Budget: a declared cost ceiling.

Where you review it

Two surfaces show the same orchestration.

The proposal card lives in the conversation that produced the plan. It is one message that re-renders through the whole lifecycle — proposed, executing, completed — with the approve and cancel actions on it.

Plan Studio is the editor: a DAG canvas, a node inspector, a revision and diff drawer and the approval bar carrying the estimate. It opens as an editor tab straight from that card. There is deliberately no “Plans” item in the sidebar; /plans and /plans/:kind/:id exist as deep links for sharing.

Approving is operator-only. There is no MCP tool for it: an agent can propose (propose_orchestration), submit a plan (submit_plan), or instantiate a playbook (run_playbook), but only a human approves. Agent-initiated revisions are additionally rate-limited by a two-minute cooldown, so a replanning loop coalesces instead of flooding your feed.

What you can change before approving is what the node inspector exposes: retitle or rewrite a sub-ticket, change which role owns it, rewire its dependencies, edit its output schema, or delete the node outright. Structural nodes (research, discussion, synthesis) and nodes that have already executed are read-only. You cannot pin a role to a specific named agent and you cannot edit the budget, from the editor.

Two editors on one plan is resolved by optimistic concurrency, not merging. Every edit carries the base_revision it was made against; an edit based on a stale revision is refused with “the plan moved on” rather than silently clobbering someone else’s. Rewinding is not a delete either — it appends the older proposal as a new revision, so the revision timeline only ever grows.

Honest estimates, or none

The estimate on the approval bar is built from real completed-run history for each role, as an interquartile (p25–p75) band. Cost totals sum the estimable nodes; duration is the critical path through the DAG rather than the sum (parallel branches overlap).

A node whose role has no completed-run history reports sampleSize: 0 and null ranges. That renders as exactly that — unknown — never as a fabricated point value, because an estimate you cannot trust is worse than no estimate. When some nodes have history and some do not, the total is marked partial. Blast radius appears only when a node declared symbol or file provenance refs; a node without them stays “unknown” rather than inferring from prose.

One approval, then deterministic execution

This is the core idea: the agent plans; a deterministic function executes. When you approve, the OrchestrationMaterializer, a pure function with no LLM and no I/O, converts the proposal into a real pipeline. Given the same proposal and the same resolved roles, it always produces the same DAG. That matters because the generated pipeline inherits everything the engine already does for free: suspension and resume across restarts, crash recovery, per-run cost and token rollups and the run-detail UI.

Approval also creates the scaffolding the work needs:

hires any roles marked as new (and records the hired agent ids so a crash mid-approval can resume without duplicate hires)
a team grouping the roles
a project that files the parent ticket
the pipeline template + run that drives it all

The lifecycle

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

Status	Meaning
`proposed`	The plan is ready and waiting for your one upfront approval
`approved`	You approved it; materialization is in progress (hires, team, project, pipeline)
`executing`	The generated pipeline is running: sub-tickets, discussion, work
`synthesizing`	The sub-tickets are done; the synthesis step is producing the deliverable
`completed`	Done: the parent ticket is marked complete and the deliverable is posted in the shared space
`failed`	Materialization failed, or the generated pipeline run failed
`cancelled`	You cancelled it

A monotonic revision number tracks the proposal as the orchestrator revises it while it is still proposed; the app records which revision you approved. propose_orchestration refuses a revision once the status is no longer proposed.

An orchestration always opens against a parent ticket and shares one discussion space, so the whole effort is traceable to a single work item and the team talks in one room.

What happens when it finishes

A kept-alive listener watches the generated pipeline and maps its terminal state back onto the orchestration and the parent ticket, so completion and failure surface in the places you already watch. The orchestration feature does not need its own execution engine.

You can cancel an orchestration at any time; the cancellation tears down the in-flight work.