orchestration is not one of Matt's Skills. It comes with Orca, the app that runs several coding agents side by side, each in its own terminal.
What it's for
It lets one agent, the coordinator, supervise other agents, the workers. Orca keeps a record of who owns each piece of work, which attempt counts, and when the work has finished. Workers can ask the coordinator a blocking question and wait for the reply, and each one reports back when it's done.
the coordinatorone coordinator waits for all of them and answers their questions
the workersthree agents build three Tickets of a FastAPI backend at oncea blocking question the coordinatorA worker_done message from each worker the coordinator
It lets one agent, the coordinator, supervise other agents, the workers.
When to use it
Use it when you want to supervise agents, not just start them: watch them, wait for their results, answer their questions, or run pieces of work in a set order. For example, three agents build three Tickets of a FastAPI backend at once, and one coordinator waits for all of them and answers their questions.
When not to use it
If you only want another agent to take over the work, with nobody watching, the guide sends you to Orca's orca-cli Skill instead, and no orchestration records are made.
When the work has to travel, say to a colleague, with nobody supervising, use handoff: it writes a document that the next agent reads. To build a whole Spec's Tickets with the Main flow, use implement-spec.
What it needs to start
Orca running, and its real guide loaded. The installed Skill file is only a stub: the agent asks the Orca CLI to print the guide that matches the installed version (skills get orchestration).
A Task spec for each worker that stands on its own. Orca uses "Task" for one piece of work given to a worker, much like a Ticket. The spec names the files in scope, the change, what not to touch, what the worker may edit, and the evidence that proves it's done.
What it creates
A Run: the coordinator's inbox for one piece of supervised work.
Tasks, each with a Dispatch: one attempt at a Task by one worker.
A worker_done message from each worker: a three-sentence summary and a clear outcome, succeeded or failed.
At the end, a report from the coordinator naming, per Task, its outcome, the evidence, and anything still blocked.
Going deeper
5 min read · Going deeper not read
Why it exists
On 2026-04-15 heyramzi opened a discussion in Orca's repo. It began: "Orca already runs Claude Code, Codex, and OpenCode side by side". He asked Orca to make them work together, and named what was missing:
The missing piece is the glue — the coordinator that makes the agents collaborate instead of just coexisting.
Twelve days later, on 2026-04-27, Orca's maintainer Jinwoo-H opened the pull request that built it. Its first line says it "Implements the inter-agent orchestration system described in the design doc and discussion #681". It shipped behind a switch: one commit says it moves "inter-agent orchestration behind an experimental toggle in Settings." On 2026-05-05 he told the discussion: "We've added experimental orchestration capabilities to our Orca CLI".
Orca's docs page (undated, read on 2026-10-30) sums up the job in one line: "Use it when you need ownership, completion tracking, or a DAG."
How it works underneath
The first version, merged on 2026-04-28, was built around a mailbox. Messages went into a database, and check --wait "blocks until a message arrives, replacing sleep+poll loops". So a coordinator waits on its inbox instead of sleeping and polling in a loop. It also had a "Circuit breaker: 3 consecutive failures → , prevents infinite retries".
Part of that first version is gone. In the pull request, orchestration run "starts a coordinator loop in the runtime". The docs now call it "the retired orchestration run command". The guide the Course pins (Orca 1.4.243, taken on 2026-10-29) is newer, so it decides: the coordinator agent runs the loop itself.
One commenter in the discussion, who runs this pattern daily, said on 2026-09-10 that coordinating was never the hard part: "Knowing when a worker was done was." He argued that a coordinator needs "three states rather than two": finished, needs input, and unknown. "The third is where the time actually goes".
Orca's guide also refuses a simple alive-or-dead answer. It keeps three verdicts, "live / unverifiable / exited", and warns that "contact loss is not process death." Only one kind of fact lets a coordinator give up on a worker: "Only positive proof of exit authorizes stop, abandon, or retry".
A real example
The pull request that built orchestration lists an end-to-end test in its test plan: 3 Tasks, two in parallel and one in sequence, done in about a minute. In its words: "full 3-task DAG orchestration (2 parallel + 1 sequential) completes ~1 min". A DAG here is a plan of Tasks with dependencies between them. Orca's guide adds: "Use dependencies only for real ordering".
Where it goes wrong
Workers that never report. On 2026-08-30 an Orca contributor described a 12-hour run with no one watching and "up to 10 Codex lanes". In it, "≥6 workers completed their work (commit + push verified by OID) and never sent worker_done". His guess was "lifecycle-instruction decay over Codex's long context": the worker forgot its reporting rules. But his issue admits that cause "was not isolated experimentally".
He had asked Orca to settle such Tasks from checked result evidence tied to the attempt. His issue warned that "An existing commit or artifact is not enough unless its provenance and relevance are established." On 2026-09-11 he closed the issue himself, because the guide went the other way: recovering the attempt from evidence "would reintroduce success inferred from artifacts, which the guide rules out." Today's guide settles a Task only with "A valid worker_done", and adds: "Absence never authorizes stop, abandon, retry, or release; keep waiting or inspect."
A report lost while Orca is down. On 2026-08-07 a user reported a run of three workers in which the Orca runtime stopped answering. "The workers did not stop." But a worker sends worker_done only once. If that send fails, "the work is done but invisible". The coordinator can't easily tell either: "a runtime outage is easy to mistake for a quiet window". A second user confirmed it on Windows on 2026-08-18. The issue was still open on 2026-10-30.
Both failures teach the same habit. An empty inbox is not a result: inspect the worker before you decide anything, and count a Task as done only from a valid worker_done.
Try it
In your practice project (set it up first with keeping-track's Try it step if you haven't), open the yoga-studio repo in Orca and ask one agent to supervise two workers: one adds a test for listing classes in api/, the other adds a page that lists classes in web/.
Before the workers start, read the two Task specs the coordinator wrote. Each should name its target, change, constraints, ownership and observable acceptance. When each worker_done arrives, run that worker's acceptance test yourself and compare it with the reported outcome. If three waits in a row come back empty, don't start a second worker on the same Task; ask the coordinator to list its workers (worker-list) and say what each is doing.
From snapshot/skills/orchestration/orca-guide.md, lines 97–99: “Send worker_done exactly once, from the dispatched terminal, with a three-sentence executive summary, both lifecycle IDs, and explicit --outcome succeeded or --outcome failed.”
From snapshot/skills/orchestration/orca-guide.md, lines 173–179: “Every Task spec must be self-contained and name: - Target: the files, component, or environment in scope. - Change: the concrete result to produce. - Constraints: invariants, compatibility rules, and do-not-touch boundaries. - Ownership: what this worker may edit and any coordination boundary. - Observable acceptance: the test, output, or evidence that proves completion.”