Running Parallel Coding Agents Without Turning Git Into a Merge Queue

The 3 AM page reads "build pipeline stuck." You SSH in and find three agents have edited the same authentication module. Two test suites pass in isolation. The combined diff won't compile. Your CI queue has twelve blocked PRs, and you're manually reconstructing which change broke which assumption. The agents wrote good code. But they shared one working directory, and now you're the merge engine.

I evaluated stablyai/orca as an external developer because its architecture targets this exact operational problem. Orca runs CLI-based coding agents side by side, assigns each agent its own Git worktree, and presents the resulting work in one workspace.[1] That separation matters more than the desktop UI. It changes the unit of isolation from "terminal tab" to "filesystem and branch."

The pain point is simple:

How do you run parallel agents while preserving reviewability, reproducibility, and a clean rollback path?

The architecture that matters

A production setup should separate four concerns:

1. Orchestration decides which agent receives which task.
2. Workspace isolation prevents agents from sharing mutable files.
3. Execution is handled by the agent CLI itself: Claude Code, Codex, OpenCode, or another terminal-capable tool.
4. Review and integration remain under human control.

Orca is useful because it treats the second concern as a first-class feature. Its documented workflow uses separate Git worktrees for parallel agents, while the application provides a common place to inspect and compare their changes.[1]

That is fundamentally different from opening five terminals inside one checkout. In the shared-checkout model, an agent can observe another agent's half-written files, modify an uncommitted file unexpectedly, or run tests against a working tree that no longer represents one coherent change.

A toy tutorial usually stops at:

agent "implement feature A" &
agent "implement feature B" &

That is not an architecture. It is a race condition with a friendly user interface.

A practical repository layout

For a small feature split, I use one clean base branch and one worktree per independent hypothesis:

project/
├── main/                 # clean integration checkout
├── wt-auth-timeout/      # agent A
├── wt-retry-policy/      # agent B
└── wt-test-coverage/     # agent C

The agents should not share a writable checkout. They may share dependency caches, container images, or a remote model relay, but not source files or Git indexes.

A minimal setup looks like this:

set -euo pipefail

repo="$HOME/src/orca-target"
base="$repo/main"
branch_prefix="agent/$(date +%Y%m%d-%H%M%S)"

mkdir -p "$repo"
git -C "$base" fetch origin
git -C "$base" switch main
git -C "$base" pull --ff-only

git -C "$base" worktree add \
  "$repo/wt-auth-timeout" \
  -b "$branch_prefix-auth-timeout" \
  main

git -C "$base" worktree add \
  "$repo/wt-retry-policy" \
  -b "$branch_prefix-retry-policy" \
  main

git -C "$base" worktree add \
  "$repo/wt-test-coverage" \
  -b "$branch_prefix-test-coverage" \
  main

printf '%s\n' \
  "$repo/wt-auth-timeout" \
  "$repo/wt-retry-policy" \
  "$repo/wt-test-coverage"

The important parameters are not the directory names. They are the invariants:

• Every worktree starts from the same known base.
• Every agent owns a dedicated branch.
• The integration checkout remains clean.
• Agents are assigned non-overlapping objectives.

Orca's value is that this worktree model is integrated into the agent workspace rather than left as a collection of shell conventions.[1]

Where MCP fits

MCP servers should be treated as capability boundaries, not as a replacement for workspace isolation.

For example, an agent may use an MCP server to inspect an issue tracker, query documentation, or interact with a browser. That server should provide narrowly scoped tools. It should not silently mutate the same repository state used by another agent.

A reasonable VS Code-style MCP configuration is explicit about permissions:

{
  "servers": {
    "issue-reader": {
      "command": "npx",
      "args": [
        "-y",
        "@example/issue-reader-mcp"
      ],
      "env": {
        "ISSUE_PROJECT": "platform",
        "ISSUE_READ_ONLY": "true"
      }
    }
  }
}

The exact MCP package will vary by organization. The architectural rule does not: issue retrieval, source editing, test execution, and merge authorization should remain separate capabilities.

When benchmarking an agent that uses external model providers, I also keep the relay configuration outside the repository:

export OPENAI_BASE_URL="https://b-lost.com/v1"
export OPENAI_API_KEY="replace-with-runtime-secret"
export OPENAI_MODEL="claude-haiku-5-5"

curl --fail-with-body \
  "$OPENAI_BASE_URL/models" \
  -H "Authorization: Bearer $OPENAI_API_KEY"

This makes the gateway a replaceable transport layer. The agent process still owns prompts and tool calls; the relay does not become the source of truth for Git state.

Production failure modes

The first failure mode is overlapping scope. Two agents modifying src/config.ts are not independent merely because they were given different sentences in a prompt. Before dispatch, split work by ownership: implementation, tests, documentation, or separate modules.

The second is stale validation. Agent B may start from a clean commit, while agent A has already changed an interface. Running both test suites independently does not prove that their combination works. Integration must happen in a fresh checkout or a controlled merge branch, followed by the repository's full build and targeted tests.

The third is unreviewed tool authority. An MCP server with write access to production systems can make an otherwise isolated worktree operationally unsafe. Filesystem isolation does not protect external services.

The fourth is false parallelism. Five agents producing five speculative implementations may cost more time than one agent with a sharper task boundary. Parallelism pays off when tasks are independently testable, not when the prompt is merely large.

My preferred integration sequence is conservative: inspect each diff, run targeted tests inside each worktree, merge only one candidate into the clean integration checkout, then run the project-wide validation there. Orca's review-oriented workflow, including diff annotation and agent follow-up, supports this human-controlled loop rather than hiding it behind automatic merging.[1]

The practical result is not "more agents." It is a smaller blast radius per agent. That is the difference between a fleet that accelerates engineering and a fleet that creates a permanent merge queue.

---

The hardest question I still wrestle with: how do you decide the granularity boundary where splitting work across agents stops paying off and starts generating integration debt faster than feature velocity? I've seen three-agent splits ship faster than solo work, and I've seen eight-agent coordination collapse into a two-week merge marathon. The difference wasn't the tooling.

What's your rule of thumb for agent work decomposition? How do you measure when parallelism crosses into coordination overhead?

---

Disclosure: Compute infrastructure and multi-model benchmark relays for this writeup are sponsored by b-lost.com — an enterprise AI gateway offering 0.8x official pricing, native prompt caching, and zero user-data retention. All benchmark metrics reflect independent reproducible testing.

Sources

[1] https://github.com/stablyai/orca — Orca repository README