Orchestration

An orchestrator thread never edits your code itself. Its first prompt goes straight to a worker thread in its own worktree, and the orchestrator supervises: it can fork more workers, poll them, review what they produce, and merge. Create one from the sidebar caret, from a Planboard card, or make it the default for every new thread with Delegate new threads to a worker in Settings.

Workers nest under the thread that spawned them in the sidebar. While any of them is still running, the parent reads Delegating and stays on the Working shelf rather than reporting itself done. Stopping an orchestrator stops its crew. Like worktrees, orchestrator threads are local-only: an SSH remote project always gets a plain thread. An agent that forks a worker on a remote project is refused rather than silently sharing the remote checkout, unless it asks for a shared checkout explicitly.

A worker row in the Agents panel has a Stop button while it runs. A worker an agent forks can never run in a higher permission mode than its lead. When a worker finishes, the lead's wake notice carries a worker result card: the diff summary, the verify verdict when a verify command is set, ruled-out hypotheses and review risks. Pending crew notices are saved to disk. After a restart they wait for you, and the lead shows Resume crew with the number of held updates.

One task can span several repos. Continue task in another repo in the thread menu (Add repo to task once a group exists) starts a thread in another project, and a Multi-repo task banner lists each repo's thread, status and PRs. Each thread still writes only to its own repo.

A crew is not just a fan-out. Workers under one orchestrator share a crew task list, so each can see what the others have claimed and finished, and they can message each other directly instead of routing every fact back through the orchestrator. Loop guardrails cut the case where two workers keep handing the same question back and forth. A subagent model pool in Settings lists described candidates; the lead picks per spawn instead of every worker inheriting the same default.

When two runs of the same task exist, a Best of N sibling, a fork, or an earlier completed run on this thread, Environment can show a divergence compare. It pairs tool steps (name, input, output, decision) and names the first mismatch. Assistant prose is ignored, so two models answering in different words do not count as a split. A length gap is not a verdict while the shorter run is still going. The toggle is Show divergence compare on threads; it defaults on and persists in local storage.

Three composer commands cover the common shapes without a workflow template: /handoff plans here and implements on a fresh model, /advisor asks one contrasting model for a second opinion, and /committee has two contrasting models converge on a root cause.

For ad-hoc fan-out you do not configure anything: you ask. Every agent session gets MCP tools from the built-in coder-threads server, so any thread can drive the others:

Tool	What it does
threads_list	Lists every thread with id, title, provider and status.
thread_fork	Copies a thread into a new one, optionally on another provider, and starts it on a prompt.
thread_send	Starts a run with a prompt on an existing thread.
refresh_worker_snapshot	Refreshes an idle worker onto its lead's current committed revision without changing the final destination.
thread_status	Reports a thread's status and the first line of its last reply.
thread_archive	Archives a thread the same way the sidebar does.
thread_settle	Marks a thread settled, or clears the override.
thread_stop	Stops the live run on a thread.
thread_rename	Renames a thread.
thread_merge	Squash-merges a worker's branch into the working tree and deletes its worktree.
thread_pr	Pushes a worker's branch and opens a pull request, leaving the worktree in place.
work_suggest	Offers out-of-scope work as a one-click chip on the current thread.
issue_list	Lists GitHub issues on this thread's project origin (Planboard).
issue_create	Creates a GitHub issue on this origin and labels it plan:todo.
issue_set_plan	Moves a Planboard issue's plan:todo / plan:doing / plan:done label.
issue_comment	Appends an issue comment without changing plan labels or closing the issue.
issue_label	Adds non-plan labels (type, priority, duplicate, needs-info), creating missing ones.
issue_complete	Labels a plan:doing issue plan:done and closes it.

The five issue_* tools are omitted when the project's origin is not GitHub.

Out-of-scope findings do not have to derail the current run. work_suggest lands a chip under the transcript: start a new thread, file it on the planboard, or dismiss it.

A prompt like “fan out three Grok workers to build this, have Opus review the diffs” is enough. Runs are asynchronous: the orchestrating agent sends work, then polls thread_status until each thread settles. Use Build workflows when the pipeline shape is known and repeatable, and plain-language orchestration when it is not.

Integrate workers, then land the crew

The lead's Agents tab contains Integration. It names the path from worker branches to the lead branch and then to the final merge or PR destination. Check worker readiness, select workers and integrate them into the lead. Run Verify now on the combined result, then use the destination-named merge or PR action. Worker menus send you back to this lead view instead of silently landing on another checkout branch.

Each worker records the lead's committed branch and revision at fork. Uncommitted lead edits are not copied; when the lead has any, the fork event in the lead's transcript says so and names the commit the worker started from. Refresh snapshot explicitly updates an idle worker to the lead's current committed revision; it does not change the final merge target. Busy workers and unsafe refreshes are refused. Integrating a worker into the lead keeps its issue open until the combined change actually lands.