Parallel worktrees and the multi-agent illusion

I've been running multiple agents in parallel for most of the past year. Here's the honest version of how it actually works. The multi-agent demos that have dominated keynote AI content all suggest the same thing: you can run several agents at once and multiply your output. The reality of running multiple agents on real work is more interesting and substantially less magical. The git-worktree pattern that's emerged among people using IDE-agent tools daily exposes the trick the demos are using and shows the shape of what actually works.

Worth being honest about both because the demo framing keeps producing wrong expectations.

What the worktree pattern is

Git worktrees let you have multiple working directories pointing at the same repository, each with a different branch checked out. The pattern that emerged through 2025: spin up a worktree per agent task, point an IDE-agent at each, let them work in parallel.

The setup looks like:

~/projects/main           (main branch, where you work directly)
~/projects/feature-x      (worktree for agent A on feature-x)
~/projects/refactor-y     (worktree for agent B on refactor-y)
~/projects/bug-fix-z      (worktree for agent C on bug-fix-z)

Each worktree has an agent session running in it. The agents work on different things in parallel. You move between them as the work progresses. When an agent's task is done, you review, merge, and tear down the worktree.

That's the basic pattern. It's mostly mechanical. The interesting part is what it actually buys you.

What's actually happening when this works

The pattern works when:

• The tasks are well-bounded and independent.
• You're available to review each agent's work as it completes.
• The merge story between branches is well-understood.
• The agents are each on tasks that don't interact.

Under those conditions, the wall-clock time to complete N tasks is meaningfully less than doing them serially. The agents work while you review another agent's output; the throughput compounds.

What's actually happening: serial work with non-blocking pauses. Each agent works while you're reviewing another agent. Your attention is the binding constraint; the worktree pattern lets the agents work during the moments your attention is elsewhere.

That's the win. It's real. It's not what the multi-agent demos imply.

What the multi-agent demos are actually doing

The keynote demos that show multiple agents collaborating to "multiply output" are doing one of three things:

Performing for the camera with cherry-picked tasks. The tasks shown are the ones that go well. The failure modes that don't go on the slide deck are the ones that dominate normal use.

Synthetic tasks that don't have real interaction. The "five agents work on different parts of the same project" demo usually decomposes the task in advance into five non-interacting parts. The decomposition is the work; the parallelism is window dressing.

Hand-waving away the integration cost. The demo shows the agents producing output. It doesn't show the integration work to merge five agents' outputs into a coherent whole. The integration is non-trivial and isn't shown.

The trick is making it look like the parallelism multiplies output. The reality is that the parallelism enables non-blocking serial review, which is a real win but smaller than the demo implies.

Where the worktree pattern actually helps

Specific cases I've found it useful:

Multiple bounded refactors across the same repo. Each refactor in its own worktree; agents work in parallel; I review one while another works.

Investigating multiple hypotheses. When debugging a tricky issue with several plausible root causes, an agent per hypothesis in its own worktree. They explore in parallel; the one that finds the answer wins.

Background tasks during interactive work. While I'm focused on a primary task, a background agent in another worktree handles a routine task (dependency upgrades, test maintenance, doc updates). I check in periodically.

Exploring API design alternatives. Multiple agents each implement a different proposed interface. I compare the resulting code and pick the one that reads best.

Comparison of approaches. Same task given to two agents with different prompts. Compare the outputs; learn from the differences.

These are the use cases where the worktree pattern earns its complexity. The wall-clock savings are real; the cognitive overhead is bounded.

Where it doesn't help

Cases where the pattern adds friction without adding value:

Tasks that genuinely depend on each other. When agent B needs the output of agent A, the parallelism doesn't help. Worse, you spend time juggling the dependency than you save.

Tasks where one is much more important than the others. If task A is the priority and tasks B and C are nice-to-haves, the worktree-pattern overhead exceeds the value of parallelism. Just do A.

Tasks that interact with shared state. Multiple agents writing to the same database, file, or configuration produces conflict that takes longer to resolve than the work would have taken serially.

When you can't review fast enough. If you can't keep up with the agents' output, the worktrees pile up unreviewed work. The bottleneck is your attention; adding more agents past your review capacity makes things worse.

Anything where the integration cost dominates. When merging the agents' outputs requires significant work, the parallelism savings get eaten by the integration cost.

These are the cases where the multi-agent framing produces the wrong answer.

What this says about the multi-agent narrative

The honest framing for multi-agent collaboration in early 2026:

• Parallel agents on independent tasks work. Modest productivity lift, gettable with the worktree pattern.
• Agents collaborating on a shared task is mostly demo theater. The cases where it works are narrow; the cases where it doesn't outnumber them.
• The single-agent-with-good-tools case is still the productivity workhorse. The agentic IDE with plan mode and the design patterns that hold up is the foundation; multi-agent is an extension.
• The "agent swarm" framing is mostly aspirational. Real day-to-day use looks more like "carefully orchestrated single agents with non-blocking parallelism" than like swarms.

The multi-agent demos sell a future that the people doing the work aren't experiencing. The worktree pattern is what people are actually using. The two should be in the same conversation; usually they aren't.

What I'd recommend

For someone considering multi-agent workflows in early 2026:

• Start with the worktree pattern. It's the simplest version of "multiple agents in parallel" and it works.
• Don't try to coordinate agents on the same task. The collaboration overhead exceeds the value for most cases.
• Match parallelism to your review capacity. More agents than you can review is wasted parallelism.
• Keep the merge story simple. Branches that integrate cleanly; tasks that don't interact.
• Be skeptical of the multi-agent demos. They're showing the cherry-picked best case; the everyday reality is the worktree pattern.

The multi-agent illusion is a real cognitive trap. The worktree pattern is what works. The gap between them is the gap between marketing and practice. Worth being plain about because the marketing-shaped expectations produce frustration when the practice doesn't deliver them.

Multiple agents in parallel works; the way it works isn't the way the demos imply. The honest version is more useful, less impressive, and the actual productivity story.