Orca Supports Twenty Nine Agents With One Terminal

SnackOnAI Engineering | Senior AI Systems Researcher | Technical Deep Dive | September 16, 2026

Read the README and Orca is an agent orchestrator. Read the contributor rules and it is a cross-platform process-supervision product with an agent UI on top, and the second reading is the one that tells you whether it will survive your machine.

What this covers: the worktree isolation model, the agent-status store, the SSH liveness vocabulary, the Windows spawning hazards, and the relay behind the mobile app. What this excludes: Design Mode, the editor, and the Linear and GitHub integrations.

Orca is an MIT-licensed Agent Development Environment from Stably AI. An Electron desktop app for macOS, Windows and Linux, plus iOS and Android companions, that runs fleets of CLI coding agents in parallel git worktrees and tracks them in one place.

The headline is breadth. Twenty nine named agents on the feature wall, from Claude Code and Codex through Devin, Goose, Qwen Code and Mistral Vibe, plus a catch-all.

The integration contract explains how they got there, and it is one sentence: if it runs in a terminal, it runs in Orca.

That is not an integration matrix. It is a terminal. Per-agent engineering is close to zero, which is a genuinely good design decision and also means the agent count is not the achievement it looks like.

Now open AGENTS.md, the rules file the project gives to agents working on its own codebase. The Considerations section is dominated by platform hazards, each pointing at its own dedicated reference document:

Six documents about spawning processes on Windows. One sentence about supporting twenty nine agents.

Caption: Focus on the second and third boxes. The verdict vocabulary and the spawn wrapper are where the correctness lives, and neither appears anywhere in the product marketing.

Three decisions carry this design.

One, the git worktree is the isolation primitive. Each agent gets its own worktree, its own branch, its own files. Fan one prompt across five agents and they cannot collide, because git already solved that problem in 2015 and nobody needed to invent a sandbox.

Two, one status store, many readers. The execution host owns agent status in a single store, the hook server's, and the sidebar, worktree ps, mobile and dashboard all subscribe. The rule is explicit: new producers write into that store, readers keep only presentation policy. No caches, no reader-side precedence rules.

Three, the execution host owns execution. For remote work this is the whole ballgame. The host that runs the process is the only thing allowed to report on it, and the client never infers.

Caption: shell: true is refused rather than discouraged, and a ratchet test enforces the boundary. Three separate Windows parsing hazards are handled in one place because handling them in many places is how you get a shipped quoting bug.

Caption: Three states, one forbidden collapse. The cost of getting this wrong is not a wrong badge in a sidebar, it is a destroyed worktree.

Caption: A code-signing certificate proves who shipped the binary. It says nothing about what the binary does at runtime, and behavioral EDR only scores the second thing.

Input: one prompt, fanned across five agents on a remote box, driven from a phone.

Step one, worktrees. Orca creates five git worktrees, each on its own branch. Five agents start, one per worktree, each a CLI process in a terminal. No sandbox was invented, because git already isolates files and branches.

Step two, spawning. Every one of those processes starts through runProcess. On Windows that means windowsHide pinned, shell: true refused, .cmd arguments encoded against two different parsers, and npm shims resolved so cmd.exe is skipped entirely.

Step three, status. Each agent writes into the single store owned by the hook server. Four surfaces read it, and none of them caches or re-derives.

Step four, the SSH drops. Contact is lost. The store reports unverifiable, not exited. Nothing gets reaped. The agents keep working on the remote host, which is the only thing that actually knows.

Step five, the phone. The desktop holds an outbound WebSocket to a relay cell. The phone holds its own. The cell splices frames between them, and a director decides which cell owns which host. When an agent finishes, the desktop authenticates to a separate push service with its X25519 key, mints a 24 hour session, and asks it to notify the phone. The phone never holds an Orca credential.

The structural numbers. Twenty nine named agents supported by one terminal abstraction. Six Windows and WSL reference documents. Three verdict states with synonyms explicitly banned. Four status readers, one writer. Twenty five cloud workflows, all inert in the public repo behind an unset variable. One ratchet test standing between the codebase and a quoting bug.

It works because the isolation problem was delegated rather than solved. Parallel agents need separate files and separate branches, and git worktree has done exactly that for a decade. Everything Orca adds sits above a primitive that already had the semantics right, which is why the agent count could grow to twenty nine without a matrix.

It works a second time because the status model refuses convenience. One writer, four readers, three verdicts, no synonyms. Most fleet UIs accumulate a cache here, a precedence rule there, and end up with a sidebar that disagrees with the CLI. This design makes that structurally impossible rather than discouraged.

What it trades away:

Electron weight. A Chromium runtime per desktop install, on a product whose users are already running five agent processes and a language server. The README does not publish a memory figure, and for a fleet tool that is the number most worth knowing.

An enormous platform surface. macOS, Windows, Linux, WSL, SSH remote, iOS, Android, plus a relay fleet on GCE and Cloud Run with Terraform. Every one of those is a place to be broken by someone else's update. The six Windows documents are what that surface costs in practice.

Feature velocity over documentation. The README says it plainly: we ship daily, so this list is perpetually behind, and the changelog is the real feature list. That is honest and it means the docs are a lagging indicator of what the app does.

A closed half. The Terraform foundation and apps roots, plus the API and auth services, live in a private repository. The MIT repo is the client and the relay, not the whole system.

No published benchmarks. For a product about running many agents, there is no figure for how many worktrees a machine sustains, what the memory curve looks like, or where the relay saturates. That absence is the most significant gap in the project's public material.

There is no moat in the orchestration. Terminal multiplexing plus git worktree is a weekend for a competent team, and the twenty nine agent integrations are one terminal.

The moat is the platform tail, and it is real. Six Windows and WSL documents, each earned by a bug that shipped or nearly shipped. Knowing that wsl.exe expands $name under -- but not under --exec is not a design decision, it is scar tissue. Knowing that MSYS rewrites /c when you call cmd.exe from Git Bash is the same. Knowing that a behavioral EDR will score your daemon relocation regardless of your certificate is the same again. None of it is discoverable from first principles and all of it is load-bearing for a product that spawns processes on other people's machines.

The second moat is the relay. Outbound-only WebSockets from both ends, a director assigning hosts to cells, migration coordination, a separate push service holding the APNs key, aggregate-counters-only logging, and twenty five deployment workflows serialized through a compare-and-swap lease against a shared Cloud SQL instance. That is a small infrastructure team's year, shipped as a subdirectory of an IDE.

The third is enforcement. The ratchet test on child_process. The lint gate that fails on raw palette colors and computed className strings. The beforePack guard that turns a thin native install into a build failure rather than a silently broken artifact. Rules with failing checks survive contributor turnover. Rules in a style guide do not.

Insight One: the agent breadth is a terminal, and the difficulty went somewhere nobody is looking.

Twenty nine agents on the feature wall. The contract that makes it possible is one sentence: if it runs in a terminal, it runs in Orca.

That is a strong design choice. It means no per-agent adapter, no protocol negotiation, no version skew when Codex ships a new flag. The abstraction is a PTY, and PTYs are stable.

It also means the number is a marketing artifact. Adding the thirtieth agent costs a logo in the README.

Meanwhile, the contributor rules point at six separate reference documents about spawning a process on Windows, covering shell selection, .cmd runner semantics, the spawn wrapper, process enumeration, daemon relocation under auto-update, and EDR posture. Plus a seventh on WSL argument construction and an eighth on the Linux glibc floor.

The ratio is the finding. Twenty nine agents required one abstraction. Starting a child process on three operating systems required eight documents and a ratchet test.

For anyone evaluating agent orchestrators, this reframes the comparison. Do not compare supported-agent lists, because that column is nearly free for everyone. Compare what happens when the SSH drops, when auto-update moves the daemon, when a .cmd shim swallows an argument containing a space. That is where these products actually differ and none of them advertise it.

Insight Two: an AI coding tool has to work at not looking like malware.

From the Windows EDR posture rule, quoted in full because the phrasing matters: behavioral EDR scores each of those, and being signed does not clear them.

The forbidden list reads like a detection ruleset because it is one. No -ExecutionPolicy Bypass. No -EncodedCommand. No cmd.exe /c with escaped free text. No per-operation interpreter spawning. No runtime Add-Type compilation.

Now list what Orca legitimately does. It spawns arbitrary child processes on demand. It runs user-authored setup scripts. It enumerates the Windows process table. It relocates a daemon into %LOCALAPPDATA% so it survives auto-update, then runs that daemon from the copy.

Read that as a detection engineer and it is a persistence mechanism with a process spawner attached.

This is a new and underdiscussed cost of the agent era. The behavior profile of a legitimate agent orchestrator overlaps substantially with the behavior profile of an implant, because both need to run arbitrary code on a machine and survive restarts. Signing your binary establishes provenance, which is a different question from behavior, and the AGENTS.md line says so directly.

Every team shipping a desktop agent runner is going to meet this, and most will meet it as a support ticket from an enterprise customer whose EDR quarantined the app. Orca met it early enough to write the rule down.

Loss of contact is never evidence of process death. The verdict vocabulary is live, unverifiable, exited, with no synonyms.

That sentence is a rule in a contributor document, and it is the most valuable line in the repository.

The tempting implementation is one comparison. If the socket is not connected, the agent is gone. It is what most fleet tools do, it is always available, and it is wrong in a specific and expensive way.

An SSH connection drops for reasons that have nothing to do with the remote process. Wifi changed. The laptop slept. A VPN reconnected. Meanwhile the agent on the remote box is still running, still editing files, still holding a worktree with real work in it. Report exited and any cleanup path downstream is now authorized to reap a branch that was mid-change.

So the design refuses the collapse. Three states, and the middle one exists specifically to be uncomfortable. unverifiable means the system does not know, will not guess, and will not let a reader guess on its behalf.

The clause that makes it stick is "with no synonyms." Without it, somebody adds disconnected because it reads better in a tooltip, somebody else adds stale, and six months later a switch statement somewhere has a default branch that treats every unfamiliar string as dead. Banning synonyms is not pedantry, it is closing the path by which the collapse returns.

The general principle is worth more than the SSH case. In any distributed system, the absence of a signal is not a signal. Most architectures encode that as a comment and then quietly violate it at the first UI that needs a binary badge. Encoding it as a closed vocabulary, in a document that contributors and agents both read, is how it survives.

If your system has a state that means "we do not know," check whether anything downstream has already decided what it means.

AI coding assistants have become good enough that running one is no longer the interesting question. Running eight at once is.

That creates an immediate practical problem. Eight assistants editing the same folder would overwrite each other constantly. You need each one working on its own copy, and you need somewhere to see what all eight are doing.

Orca is a desktop application that does this. It gives every assistant an isolated copy of your code using a feature version control has had for years, runs each one in its own terminal, and shows them in a single window with a phone app for checking in.

The surprising part is where the difficulty lives. Supporting twenty nine different assistants took almost no work, because they all run in a terminal and a terminal is a terminal.

The hard parts were somewhere else entirely. Starting a program correctly on Windows, where two different layers each try to interpret quotation marks. Deciding what it means when you lose contact with a machine, because a dropped connection does not mean the work stopped. Making sure security software does not mistake the app for an attack, since running other programs and surviving restarts is also what malware does.

The wider lesson is that the visible feature list and the actual engineering rarely overlap. When you evaluate tools in this category, the interesting questions are about failure, not about capability.

Orca is an MIT Electron Agent Development Environment from Stably AI that runs fleets of CLI coding agents in parallel git worktrees across desktop, mobile and SSH remotes, supporting twenty nine named agents through a single abstraction: if it runs in a terminal, it runs in Orca. Its contributor rules reveal where the engineering actually went, with six dedicated documents on Windows process spawning, a ratchet test banning direct child_process use, a three-state agent verdict vocabulary that forbids treating lost contact as death, and a relay fleet with a director, cells and a separate push gateway. It matters because the visible feature list and the real difficulty barely overlap, and the comparison that decides which orchestrator survives your machine is about failure modes nobody publishes.

The habit from this issue: when a project ships an AGENTS.md or a contributor guide, read it before the README. One is written to persuade you and the other is written to stop the next contributor breaking production, and only one of them tells you what the product actually costs to build.

SnackOnAI runs this teardown weekly on the systems engineers actually deploy, agent runtimes, orchestrators, serving stacks, and the contributor docs that quietly contradict the feature wall. No announcements, no press release summaries. Subscribe at snackonai.com and join 10,000+ engineers reading it.

Forward this to whoever on your team is comparing agent orchestrators on supported-agent count.

Scaling a campaign globally means finding a voice that resonates everywhere—without losing the overall message. For Deel's "Feeling of Deeling" campaign, agency SuperBloom needed exactly that: a consistent brand voice across markets, deployed fast, without sacrificing quality or consent. They built it with Branded AI Voice, powered by real, professional talent.

SuperBloom and Voices break down how the campaign came to life in this on-demand video session—from strategic talent selection through seamless production workflows and global scale, to the governance that future-proofs an audio strategy built to last. You'll hear directly from the team on how they made this happen, plus their advice if you're looking to explore AI voice for your brand.

If you're a marketing executive, agency creative, or brand leader mapping campaigns in international markets, watch this on-demand session to get a real playbook, not a hypothetical—lessons any creative team can apply to their own global rollout.

Watch On-Demand Now