Background and parallel agents

Module 08 had you working with one agent in one session, watching it work. Every major coding agent can now also work in the background: you hand over a task, close your laptop, and come back to a pull request. Many engineers run several at once. This module shows how to do that well with any agent, which tasks to hand over, how to write the brief, and why your review, not the number of agents, sets the pace.

1. The idea

A background agent works on a task without you watching each step. You describe the task, it works in its own copy of the code, and it hands back a pull request. Run several on independent tasks and you have parallel agents. Words you'll need:

2. How it works

On your own machine, the tool that keeps parallel agents apart is git worktrees. They're plain git, so they work with every agent:

A background agent can't ask you to clarify every few minutes, so the brief does the work a conversation would. Compare a vague brief with a good one:

3. Try it yourself

Hand it over?

For each task, decide: hand it to a background agent now, write a brief (or spec) first, or keep it in an interactive session where you can steer.

How many agents?

More agents produce more pull requests, but somebody has to review them. Move the sliders and watch where the bottleneck moves.

4. Why it matters at work

Background agents are good at work that is well defined, easy to verify and doesn't overlap with other work. They are poor at work where the hard part is deciding what to do.

Best practices

The portable recipe

On your machine: one worktree per task, any agent in each. AGENT_CMD is your tool's headless command (Module 13).

#!/usr/bin/env bash
# run-tasks.sh: one worktree and one background agent per task brief in tasks/*.md
AGENT_CMD="${AGENT_CMD:-claude -p}"   # or "codex exec", "copilot -p", "agent -p", "agy -p"
for brief in tasks/*.md; do
  name=$(basename "$brief" .md)
  git worktree add "../wt-$name" -b "agent/$name"          # a separate folder and branch
  ( cd "../wt-$name" &&
    $AGENT_CMD "$(cat "$OLDPWD/$brief") Run ./scripts/check before finishing. Commit your work." \
      > "agent.log" 2>&1 &&
    git push -u origin "agent/$name" &&
    gh pr create --draft --fill ) &                            # each runs in the background
done
wait   # then review the draft PRs; remove a worktree with: git worktree remove ../wt-NAME

# tasks/upgrade-date-lib.md: a brief that works without a conversation
Goal: upgrade date-fns from 2.x to 3.x.
Context: docs/dependencies.md; the breaking changes list at the date-fns changelog.
Constraints: no behaviour changes; don't touch src/billing/ (owned by another team).
Done when: ./scripts/check passes and no date-fns 2.x imports remain.
If unsure: stop and write your question at the top of the PR description.

In CI instead, the same brief can start a job (for example a GitHub Actions workflow triggered by an issue label) that runs AGENT_CMD on a fresh runner and opens a draft PR. That is roughly what the built-in cloud agents do for you, with a prepared environment.

5. In your five tools

Every tool can run agents away from your screen; they differ in where. Git worktrees plus the headless command work locally with all of them. Checked 31 October 2026.

6. Remember it

7. Common mistakes

8. Hands-on lab (roadmap week 8)

1. Pick three small, independent tasks from your backlog: for example a test gap, a dependency bump and a docs fix.
2. Write a brief for each with goal, context, constraints, done-when and "if unsure".
3. Run them in parallel locally: one git worktree each, tool A in all three (or the script above).
4. Run one in the cloud with your tool's cloud agent, and compare the experience.
5. Review all four PRs and time yourself. Which brief produced the best result, and why?
6. Find your number: using your real review times in the calculator above, how many agents are worth running for you?

9. Self-check quiz

10. Go deeper