Multi-Agent Orchestration with Orca: Setup and What It Unlocks
Running several AI coding agents on one codebase at once: worktree isolation, orchestration runs, decision gates, and why a second provider beats more subagents.
Four agents. One repository. Different providers, working at the same time, and none of them stepping on another’s files.
That is the thing I could not do reliably before this week, and it turned out not to need a better model. It needed a layer underneath the agents: separate checkouts, addressable sessions, and a defined way to report finishing. I moved my daily loop onto Orca — an agent-orchestration desktop app with an orca CLI — and this is what actually changed.
The shift
A multi-part change used to crawl through one session in sequence — backend, then client, then tests, then docs — with each slice waiting on the last even when they barely touched each other.
Parallel work removes waiting. It does not remove dependency ordering, and it does not remove review.
Worktrees are the whole trick
Two agents editing one working tree overwrite each other’s files, disturb each other’s index, switch branches underneath one another, and make every test result meaningless. This is why “just open more terminals” fails.
Give each agent a real Git worktree and the problem evaporates. Own branch, own index, own dependencies, own terminal. Commits still integrate through ordinary Git.
Orca creates and tracks these as first-class objects, so you can survey every slice at once instead of remembering which tab was doing what.
Two providers beat one provider’s subagents
My default now: genuinely different providers on anything that matters. One worker on Claude Code, another on Codex, a third on whatever else is installed.
This needs care, because I have measured the adjacent question and I was wrong. In The Concurrency Cliff That Never Arrived I predicted subagent fan-out would stop paying off around two or three workers. Across 165 trials it did not — every valid route kept gaining throughput through N=5.
But that measured throughput, not correctness:
| Property | More subagents | A second provider |
|---|---|---|
| Throughput | Real, scales further than I expected | Roughly the same |
| Independent errors | Little — children inherit the parent’s reading | The actual point |
| Blind spots | Shared with the parent | Uncorrelated |
Subagents inherit the parent’s interpretation of the task. When the parent misreads it, the children reproduce the misreading with impressive consistency. Different providers fail differently — one catches a lifecycle bug, another an unsafe interface.
So fan out within a provider for speed, and add a second provider for independence. Agreement across providers is real evidence. Disagreement is better still: it points straight at the part that needs a human.
Runs and gates
The old multi-agent loop was manual — copy an answer out of one terminal, paste it into another, explain where it came from, carry the reply back. Context died at every handoff.
The part I did not expect to care about this much is the gate. When two workers disagree on something load-bearing, Orca does not keep whichever answer landed first — the task blocks until someone decides. A hidden choice contaminates every slice downstream of it, so making disagreement stop the line is the feature, not the friction.
It does not stop at the editor
Three things widened what a worker can finish on its own:
--on <environment>puts a worker on another paired machine — different hardware, different toolchain — while the run and its inbox stay with the coordinator.- Browser control lets an agent open the deployed page, snapshot it, click through it, and screenshot the result instead of stopping at a green build.
orca computerdoes the same for desktop applications through the accessibility layer.
That last category matters more than it sounds. It closes the gap between “the files changed” and “it works where a person will use it.”
Parallelism multiplies output. It multiplies unverified claims at exactly the same rate, so set the floor before the workers start.
What it costs
- Sprawl. Worktrees and processes accumulate and need cleanup, or you get a board of half-finished slices nobody owns.
- Review load. Four workers produce four plausible changes at once. Integration judgement does not get cheaper.
- Quota. I route mechanical work to cheaper agents and keep the strongest model for architecture and conflict resolution.
- Claims. A
worker_donemessage is a routing signal, not proof.
How this page was built
One worktree, one run, two slices, two providers drafting concurrently — then a coordinator that re-checked every documented command against the live CLI and assembled the halves.
Three things failed. One provider’s CLI was not installed on this host and died at launch. Another returned server errors and was cut. The merge request could not go through Orca’s hosted review at all — that surface is not exposed on a headless host — so it went through the GitLab API and will not appear in Orca’s own PR statistics. I would rather say that than let the number look right.
One worker caught something I would have shipped: on Linux, orca is also the GNOME screen reader, so outside a managed terminal you want the orca-ide executable. That is the second-provider argument in one line.
The diagrams are hand-authored SVG. No screenshots, deliberately — a real console view of this estate would leak repository names, work items, and session content.
Start here
Register one repository, cut two worktrees, and run two agents from two different providers against two genuinely independent slices. That single exercise teaches the whole model.
Exact commands, selectors, worker-brief templates, and the conventions I make my agents follow are in the Orca agent quick reference — written to be pasted into an agent’s instructions file rather than read end to end.