Blog

Running several coding agents in parallel without chaos

The Memmo team · · 5 min read

Working with one coding agent has a rhythm: you write the task, the agent works, you wait, you review. A lot of that time is waiting. The obvious next step is to run two or three agents at once on different tasks. The obvious first attempt, several agents in one checkout, ends with them overwriting each other's files, fighting over the dev server port and running migrations on the same database.

Here is a setup that works, and the habits that keep it from turning into chaos.

One worktree per agent

Git worktrees let you check out several branches of the same repo at once, each in its own folder. They share the same history and objects, so creating one is fast and cheap. Each agent gets its own folder and branch:

# from your main checkout
git worktree add ../app-invoice-export -b feat/invoice-export
git worktree add ../app-fix-timezones -b fix/report-timezones

git worktree list        # see them all
git worktree remove ../app-invoice-export   # when the branch is merged

Start one agent session in each folder. They can now edit, build and test at the same time without touching each other's files. Your main checkout stays clean for reviewing.

Two things don't come along automatically:

  • Dependencies. Each worktree needs its own install. With pnpm this is quick, because packages come from a shared store.
  • Untracked files. Your .env and local config are not in git, so they are not in the new folder. A small script that creates the worktree, copies the env files and runs the install saves you from doing it by hand each time.
#!/usr/bin/env bash
# scripts/new-worktree.sh <branch>
set -euo pipefail
branch="$1"; dir="../app-${branch//\//-}"
git worktree add "$dir" -b "$branch"
cp .env "$dir/.env"
(cd "$dir" && pnpm install --frozen-lockfile)
echo "Ready: $dir"

Separate ports and databases

Two dev servers can't both listen on port 3000, and two agents running migrations against one local database will break each other's tests. Give each worktree its own:

  • Ports from an environment variable, set differently in each worktree's .env.
  • A database per worktree: a separate database name on the same server, or a separate container. With Docker Compose, a different project name per folder (docker compose -p invoice-export up) keeps containers and volumes apart.
  • Tests that don't share state: if your test suite uses a fixed database or a fixed temp folder, parallel agents will see flaky failures that have nothing to do with their change.

Tell the agent about this setup in your rule file, or it will helpfully “fix” the port back to 3000.

Choose tasks that don't collide

Worktrees prevent agents from clobbering each other while they work. They don't prevent merge conflicts afterwards. Pick parallel tasks in different parts of the codebase, and watch for the shared files that everything touches: a central routes file, a shared types file, the lockfile.

When two branches both change the lockfile, don't merge it by hand. Take one side, then run the install again and commit the result. And merge in a sensible order: the change that others depend on goes first, and the remaining branches rebase onto it before review.

You are now the bottleneck

Three agents can produce three pull requests in an hour. If you can carefully review one per hour, two of them will wait, go stale and need a rebase. Parallelism only helps up to your review capacity. For most people that means two or three agents, not ten.

Habits that help:

  • Keep each task small enough to review in one sitting.
  • Write clear “done when” criteria up front, so review is checking, not discovering.
  • Review in batches instead of switching context every time an agent finishes.
  • Let CI do the first pass. Don't start reviewing a branch whose tests are red.

Shared rules, shared lessons

Every agent in every worktree reads the same committed rule files, which is good. But lessons learned during a session are another matter. If the agent in one worktree finds out that the reports module must use UTC, the agent in the next worktree doesn't know, and the same mistake shows up in a parallel branch an hour later.

Parallel agents make this problem bigger, not smaller. Whatever you use to carry lessons between sessions, whether a shared notes file, rule files or a team memory like Memmo, it needs to reach every session, not just the next one in the same folder.

Clean up

git worktree remove ../app-invoice-export
git branch -d feat/invoice-export
git worktree prune     # forget folders you deleted by hand

Old worktrees take disk space and keep their branches checked out, which stops you from checking out those branches anywhere else. Removing them when the pull request merges keeps things tidy.

Give your agents and reviews your team's memory.

One command in your repo. Nothing reaches an agent until a person approves it.