Running Two Agents in Parallel: The Exact Setup I Use

Parallel agent work is harder than the demos make it look. After six months of actually running two Claude Code sessions side by side on real client code, the setup that works is specific and opinionated. Here is the exact configuration.

The Split

• Agent A: feature branch, writes new code
• Agent B: main branch, investigates, writes tests, never edits shared files

The rule is simple: only one agent owns the writable path. The other agent is read-only on whatever the first agent touches. Violating this rule produces merge hell every time.

The Git Setup

Each agent runs in its own git worktree. Worktrees share a repo but have independent working directories and branches.

git worktree add ../project-agent-a feature/auth
git worktree add ../project-agent-b investigation/perf

Two Claude Code windows, two directories, zero conflicts.

The Communication Channel

The agents do not talk to each other. I am the channel. Agent B produces findings, I paste them into Agent A. Agent A produces code, I paste the diff into Agent B for a review opinion.

Attempts to automate the communication added more bugs than they saved. The human in the loop is doing coordination work, not typing work. That is fine.

The Verification Loop

After Agent A finishes a change, I run:

git diff main...feature/auth

Paste the diff into Agent B with instructions to review. If Agent B flags issues, I apply them through Agent A on the feature branch. Two agents, one merge.

When This Pays Off

• Large refactors where investigation and execution can separate
• Bug hunts where one agent reproduces and another fixes
• Any task where context would bloat a single session

For small changes, two agents is overkill. The switching cost eats the parallelism win.

What I Learned the Hard Way

Early attempts at parallel agents failed because I let both agents write to the same branch. They overwrote each other, produced contradictory commits, and I spent more time cleaning up than I would have in a single session. The write-ownership rule is non-negotiable now.

The Next Step

I am experimenting with a third agent: a pure reviewer that runs on every commit from Agent A. So far the reviewer catches about one in ten issues that would have survived two agents alone. Worth the setup if the blast radius justifies it.

The git worktree documentation is worth reading once before trying this setup.

The Cognitive Load

Running two agents doubles the cognitive load on the orchestrator, which is me. Two windows, two contexts, two sets of decisions landing on my screen at once. After a full day of this I am more tired than after a full day of solo agent work. The throughput is real. The cost on your attention is also real. Do not schedule parallel agent work back to back for eight hours. You will burn out. Three hours of parallel work plus a long break is a sustainable shape.

What I Tell Clients

I do not tell clients I run two agents. I tell them I deliver faster. The mechanism is my problem. Clients do not want a lecture on tooling. They want to see the demo ship on Friday. Parallel agents are a backstage choice, not a front-of-house feature.