Running multiple AI coding agents in parallel.

Why run more than one agent

Because one agent session is mostly waiting. The agent reads, thinks, edits, runs tests; you approve something occasionally. Once you trust the loop, the obvious question arrives: why is the rest of the backlog idle while this one task cooks?

Three honest reasons to go parallel, in decreasing order of payoff: throughput on independent tasks (the bug fix does not need to wait for the feature); specialization (one agent implements while another reviews, or different vendors get the tasks they are best at, which is why our comparison ends with "stop choosing"); and evaluation, giving two agents the same task and keeping the better result.

And one bad reason: making a single hard task faster. Splitting one tightly-coupled problem across agents multiplies coordination instead of speed. Parallelism pays on independent work, exactly like it does with humans.

Patterns that actually work

Parallel independent tasks

The workhorse. Each agent takes a task from the backlog and works in its own git worktree, a separate checkout of the same repository. No shared files, no collisions; you merge branches when each finishes. This alone is 80 percent of multi-agent value.

Builder and reviewer

Agent A implements; agent B, ideally from a different vendor, reviews the diff with fresh context and no attachment to the choices. Cross-vendor review catches real issues because the models have different blind spots. Cheap to run, consistently worth it.

Planner and implementers

One agent breaks an epic into tasks with explicit boundaries ("do not touch the auth module"), then implementers pick tasks up. This is the pattern that most needs a shared board, because the plan is the coordination.

Cross-CLI handoff

Start a task in one agent, continue in another: Claude Code plans, Codex executes the surgical part, or a stuck session moves to a fresh model. The trap is context: the second agent knows nothing the first learned unless the state lives outside the agents, in the repo, the board and written handoff notes.

The three hard problems

1. Collisions

Two agents editing one file do not conflict like humans; they overwrite silently. Each holds the file in memory, and the last write wins without either noticing. Worktrees prevent this by construction. Where agents must share a checkout, you need file locks: a file one agent is editing is off-limits until released. We learned to match locks by filename across the whole tree after watching two agents "safely" edit the same config through different relative paths.

2. Context

Each agent has its own memory and forgets everything when its session ends. Multi-agent work needs state that outlives sessions: a task board that is the single source of truth for who does what, and per-agent memory that persists between sessions. Otherwise Monday's decisions get relitigated by Tuesday's agents.

3. Oversight

One agent in a terminal is barely supervisable; four terminals are a wall of scrolling text nobody reads. Meanwhile the costs multiply: four agents burn tokens in parallel, and one stuck in a retry loop can quietly outspend the rest combined. Parallel agents need per-agent cost, live, and a way to see at a glance who is working, who is stuck and who is waiting for your approval.

What we learned shipping a multi-agent workspace

The Termi Protocol runs mixed fleets (Claude Code next to Codex next to Gemini CLI) in one 3D room, so the coordination problems above are not theory to us; they are our bug tracker. The lessons that survived:

• Locks must be automatic. Any scheme that relies on agents volunteering to respect boundaries fails; the lock has to be enforced by the layer running them.
• The board must be agent-driven. If humans maintain the task board, it drifts from reality within an hour. Our agents move their own cards; the human reads.
• Checkpoints per agent, not per project. When agent three ruins something, you want to rewind agent three, not the whole afternoon.
• Waiting must be loud. An agent blocked on approval is free capacity doing nothing. In our rooms a waiting agent physically idles at its desk and pings you; in a terminal it is just one more silent tab.
• Two good agents beat five unwatched ones. Every time.

A starter setup

1. Pick two tasks from your backlog that share no files.
2. Create a worktree per task: git worktree add ../proj-task-a and -b a branch each.
3. Run one agent in each (same vendor is fine to start), with approvals on.
4. When both land, have each agent review the other's branch before you merge.
5. Only then scale to three, and only if the backlog still has independent work.

Or skip the plumbing: Termi gives every agent its own desk, worktree isolation, automatic file locks, an agent-driven task board, per-agent checkpoints and live cost, in a room where you can see all of it at once.