Why Orca Makes Parallel AI Coding a Systems Problem
Orca is a desktop IDE and orchestration layer for running multiple AI coding agents side by side. This opening focuses on the systems question hidden inside that promise: how can several agents attempt one change without losing track of files, processes, evidence, or the human decision about what ships? The answer will give you a working model of Orca: it uses real Git worktrees to separate attempts, turns agent terminals into observable sessions, and connects their output to review and delivery. The models and command-line agents remain external participants; Orca organizes the space in which they work.
Parallel agents create a coordination problem
Imagine a race to fix a login race condition. One agent proposes a lock, another changes the request lifecycle, and a third rewrites the test before touching the implementation. Running them one after another is simple but slow. It also makes the second and third attempts inherit the first attempt’s framing, whether or not that framing was sound. Running them at the same time is attractive because each attempt can expose a different interpretation of the bug. Yet three agents cannot safely edit the same checkout. Their files would collide, their branches would need constant switching, and a hurried stash or reset could erase the very differences you wanted to compare.
The difficulty is not just concurrency. It is the loss of a stable comparison point. If an agent is allowed to change the same files another agent is reading, a later diff no longer tells you which reasoning produced which change. If the operator opens several ordinary terminals without a workspace boundary, the prompt, branch, current directory, and process identity become easy to confuse. A race that was meant to produce alternatives instead produces an untraceable mixture.
That is the problem Orca addresses. Its first-session flow is deliberately concrete: add a repository, create a worktree, choose an agent, repeat the operation for other attempts, split the panes so the sessions are visible, inspect the diffs, send feedback, and ship one result. The product is not claiming that three agents automatically produce a correct answer. It is making three attempts separable enough that a developer can compare them without reconstructing their histories from memory.
The same prompt can be useful in this setting because it holds the question roughly constant while the agents, branches, and implementation paths vary. It can also be valuable to assign deliberately different prompts when the goal is to explore competing hypotheses. In both cases, Orca’s contribution is the bookkeeping that makes the experiment legible: each attempt has a named workspace, an on-disk location, a session, and a diff that can be inspected on its own.
This distinction matters because “parallel AI” is not one capability. It has at least three separate requirements. The files must be isolated. The running processes must be observable. The results must be judged. If any one of those is missing, parallelism becomes either unsafe or opaque: agents overwrite one another, the operator cannot tell which one is waiting, or a completed process is mistaken for an accepted change.
There is also a fourth requirement that is easy to overlook: the experiment must have an ending. Once a candidate is selected, the other worktrees should be identifiable as alternatives rather than silently left consuming attention and disk space. Orca’s documented flow includes review, commit, push, and cleanup for this reason. The system is not complete when several agents stop typing; it is complete when the developer can explain which result survived and why.
The diagram is more than a feature map. It shows why Orca’s pieces depend on one another. Worktrees create the independent branches of the race. Agent sessions provide activity and output inside those branches. The review surface turns output into a decision. Shipping and deletion close the loop, so the experiment does not leave a permanent thicket of abandoned directories and branches.
The unit Orca coordinates
Orca’s basic unit is not a model. It is a task attached to a worktree, a session, and a visible review context. A repository supplies a base ref, usually the branch from which new work begins. When you create a workspace, you choose a start-from ref—often that base ref, but potentially another branch or a specific commit. Orca then creates a real Git worktree with its own directory and branch. The agent starts in that directory, and the worktree becomes the place where its edits can be inspected.
The two references answer different questions. The base ref is the repository-level default for new work; the start-from ref is the decision for this particular attempt. That distinction matters when an engineer wants to try a change on top of a branch already under review, or when several attempts must begin from the same commit so their diffs mean the same thing. The worktree records the relationship well enough for the review surface to compare the attempt against an intelligible starting point.
That choice preserves a useful relationship with ordinary software practice. You can still use Git directly: check status, compare branches, rebase, cherry-pick, commit, or remove a worktree from a terminal. Orca adds a coordination layer around those operations; it does not replace the repository’s history or invent a second version-control system. When the work is ready, the selected branch can be committed, pushed, and opened as a hosted review. The alternatives can be removed with their worktrees and branches, subject to Git’s protection for branches that may contain unmerged commits.
The same unit also includes the agent process. Orca can launch Claude Code, Codex, Cursor CLI, OpenCode, and many other command-line agents from an agent picker. It can pass the chosen working directory and, where supported, observe provider hooks and terminal status. A plain shell remains possible, but it does not become a recognized agent simply because it occupies an Orca tab. This is an important boundary: Orca offers a common launch and workspace surface, not identical behavior from every provider. A shared launcher can standardize where a process starts; it cannot standardize the model’s reasoning, the provider’s prompts, or the quality of its edits.
The developer is part of the unit as well. The purpose of creating several worktrees is not to remove judgment; it is to make judgment more informed. If one implementation has a clearer diff, another has stronger tests, and the third found a hidden edge case, the operator can combine those discoveries or choose none of them. Agent agreement can be a useful signal, especially when it points several independent attempts toward the same small change. But agreement can also reflect a shared misunderstanding, a copied assumption, or a common limitation in the prompt. It is not independent verification, and it does not replace tests, review, or understanding of the codebase.
Isolation is only the first boundary
The worktree solves the most visible collision: competing agents no longer write into the same files. It does not solve every problem that appears when work moves in parallel. A clean Git checkout may not contain ignored dependencies, caches, local configuration, or secrets. Orca therefore has ways to share selected ignored directories, copy literal ignored files, or run repository setup commands after creation. Those choices are practical, but they are also design decisions. A shared dependency directory can save time while coupling attempts through mutable state. A copied configuration file keeps worktrees separate but can become stale. A setup hook can make the environment usable while introducing another command whose failure must be understood.
This is why “isolated” should be read precisely. Git isolates the tracked working tree and branch history. It does not automatically isolate every process, cache, credential, service, or external resource an agent can reach. Two worktrees that share a dependency directory may still influence one another through generated files. Two agents using the same remote service may still race at the application level. Orca’s structure makes the boundary visible, but the repository and the operator decide what crosses it.
The second boundary is session state. A worktree can exist while its agent is working, waiting for permission, done, blocked, or no longer running. Orca exposes those distinctions through status indicators, dashboards, notifications, and restart controls. The visible state is useful only because it is tied to observations from the terminal or the agent’s hooks. A restored status row is not automatically proof that the process is still alive; the system deliberately treats some restored information as unconfirmed until fresh evidence arrives.
That distinction changes how an operator reads the interface. “Done” can mean that an agent reported a completed turn, not that a reviewer accepted the patch. “Waiting” may require a human answer before more work can happen. A restart control can put the agent back in the same worktree, but it cannot recreate context that was never persisted or decide whether a partial edit should be kept. Orca makes these states easier to find; it does not make them interchangeable.
The third boundary is location. By default, the files, agents, terminal, and interface can all live on one desktop. But Orca can also place a worktree and its agent on an SSH host, connect the client to a Remote Orca Server that owns the entire runtime, or use a recipe-defined per-workspace environment. Those options change where credentials, processes, Git operations, and authoritative state live. A remote interface may look local while the actual work belongs to another machine. Understanding that distinction is essential before interpreting a disconnect or retry.
So Orca should not be understood as a button that makes an agent autonomous. It is a system for making parallel attempts controllable: separate the files, keep the running work visible, compare the evidence, and put a person at the delivery boundary. Its value lies in connecting those controls into one workflow. Its limits appear wherever the controls stop—when shared setup hides coupling, when a status signal becomes stale, when a provider offers only shallow integration, or when a remote host cannot be observed.
The next question is therefore concrete: what does a real Git worktree contribute beyond a branch name, and how does Orca make an isolated checkout usable without abandoning ordinary Git? Answering that question explains the foundation on which the terminals, review tools, and later coordination features depend.