Background and Parallel Agents

Once you trust an agent on a scoped task, the next move is obvious: run several at once. Modern tools let you kick off background agents — each on its own branch or worktree (a separate working copy of the project, so one agent's edits never collide with another's) — so three or four scoped tasks make progress while you do something else.

This is a real speedup, but only for independent work. The cost you're trading against is coordination. Two agents editing the same file will produce conflicting diffs, and merging them by hand can cost more than you saved.

• Split by boundary, not by line count. Give each agent a chunk that doesn't overlap the others — separate modules, separate features, separate files. "Agent A does the export feature, Agent B writes the docs" is clean. "Both agents edit app.js" is a merge headache waiting to happen.
• Isolate the workspaces. Run each agent on its own git branch or worktree so they can't step on each other's uncommitted changes. Merge them back one at a time, running your checks at each merge.
• Keep the count honest. You still have to review every result. Four agents running is four diffs to read and four sets of tests to trust. Past a handful, the review queue — not the agents — becomes your bottleneck.

Each agent works in its own isolated worktree so their edits never collide; you merge them back one at a time, running checks at each gate:

              ┌─────────────────────────────┐
              │  YOU split by boundary       │
              └──────────────┬──────────────┘
            ┌────────────────┼────────────────┐
            ▼                ▼                 ▼
   ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
   │ AGENT A      │ │ AGENT B      │ │ AGENT C      │
   │ worktree-a/  │ │ worktree-b/  │ │ worktree-c/  │
   │ export feat  │ │ docs         │ │ settings page│
   └──────┬───────┘ └──────┬───────┘ └──────┬───────┘
          │ branch-a       │ branch-b       │ branch-c
          └────────────────┼────────────────┘
                           ▼
                  ┌──────────────────┐
                  │  MERGE one-by-one │  run checks at each merge
                  │  → main           │
                  └──────────────────┘
   isolated copies = no collisions   · review queue is the real limit

The mistake is treating parallelism as free. It isn't — you've moved the work from writing to reviewing and integrating. Often a great trade, but only if you actually do the reviewing.