Orchestration

Some jobs are too big for one agent working alone. Orchestration puts a lead agent in charge of a team: it decomposes the task, spawns workers, assigns each a scoped subtask, polls their progress, and integrates and verifies the combined result.

Two flavors

Start either one from the slash menu:

• /orchestrate-agent — the workers are Mel agents, each spawned into its own pane or tab as a full conversation. The lead delegates rather than authoring: its own toolset deliberately drops write_file and edit_file, so the code is written by workers while the lead plans, assigns, reads results, and verifies.
• /orchestrate-cli — the workers are CLI coding agents (the claude, codex, or opencode CLIs) running in panes as real interactive sessions. The lead types into them and reads their screens.

The lifecycle

1. Plan — the lead thinks through the decomposition: which files each worker owns, what interfaces they share, what "done" means for each.
2. Confirm — before anything spawns, a confirmation card asks "Can I start additional agents for this task?" showing the proposed fleet, which you can edit before accepting. Accept spawns; Reject keeps everything single-agent. This gate stays even in autonomous mode.
3. Spawn — workers open in split panes or new tabs (the lead chooses right / down / tab placement); focus stays on the lead so you can watch the coordination.
4. Assign & poll — each worker gets a self-contained task (owned files, interfaces, acceptance criteria). As they report in, the transcript shows worker status cards — an avatar monogram, the worker's name, and a "Started: …" / "Complete: …" status line.
5. Integrate & verify — the lead doesn't take worker reports on faith: it checks the actual on-disk changes (diffs, builds, tests) before summarizing, and flags discrepancies rather than hiding them.
6. Synthesize — a structured roll-up: per-worker results with what changed, anything to flag, and how to proceed.

Workers run hands-off

Orchestration defaults autonomous mode on, and CLI workers are launched in their own non-interactive, auto-approved modes — claude --permission-mode acceptEdits -p, codex exec --full-auto, opencode run — so a nested permission prompt inside a worker can't stall the whole fleet.

Shared memory across the team

Lead and workers all get the remember / recall tools scoped to the project, so decisions made by one agent (naming, interfaces, "the API lives in src/api") are visible to the rest of the team — and to future conversations. See Project memory.

Watching it work

Every worker is a real pane: click into one to watch it live, or let the lead's transcript summarize. Worker conversations are saved like any other and appear in conversation history tagged by their role. Because workers edit the same checkout, git diff — and the code review panel — always shows you the team's combined output.