Running agents in parallel

Take the “independent things at once” idea from the last lesson and scale it up — from single tool calls to whole subagents.

If one subagent saves your context, several running at once multiply your output — each grinding on a separate piece while you wait a single time.

You learned in Lesson 10.2 that a subagent goes off and does a big job on its own. You learned in Lesson 10.8 that independent steps can run together. Put them side by side and you get the real unlock: launch several subagents at once, each on its own independent job.

“Investigate three possible causes of this bug.” Instead of one subagent checking cause A, reporting, then B, then C — three subagents, one per cause, all at the same time. Three investigations, one wait. You’re the conductor now, exactly the shift Lesson 10.1 pointed at.

Same rule as before — independent

This only works when the jobs don’t depend on each other.

• Three separate areas of the codebase, one subagent each — independent. Run them together.
• “Find the bug, then fix it” — not independent. The fix needs the finding first, so it has to wait.

It’s the very same rule as parallel tool calls — just at the scale of whole jobs instead of single steps.

One conductor, many workers

When several run at once, you’re not reading each one’s work. Remember, each reports back only a summary — so you get a handful of tidy answers instead of one giant pile.

You can even let them run in the background and get pinged as each finishes, instead of staring at the screen waiting.

The win compounds: each subagent already kept its mess out of your context — running them in parallel also keeps them out of your clock.

What’s next

There’s one more kind of independence to unlock. Sometimes two jobs touch the same files and would step on each other — unless each gets its own copy of the project. That’s a worktree.