Heavy users run five, ten, even hundreds of agents at once. But your attention doesn't parallelize, and naive parallelism creates conflicts and duplicate work. Learn how to isolate agents with worktrees, pick tasks that don't collide, and keep the orchestration tax under control.
Key takeaways
- Power users run several agents at once, each on independent work.
- Give each agent its own checkout: git worktrees locally, or cloud sandboxes at scale.
- Your attention doesn't parallelize. Every extra agent adds routing, review and merging work for you.
- Parallelize reads freely; parallelize writes only when tasks don't touch the same code.
- Trust one agent before you run ten.
Try it with your agent
With your next few tasks:
Here are my next tasks: [list them]. Tell me which can run in parallel without touching the same files, which depend on each other, and a safe order. Then start the first independent one in a new git worktree on its own branch, and verify it before a PR.
Transcript
Intro
The people who ship the most with agents rarely run just one. But parallelism has a hidden cost, and it's paid in the scarcest resource you have: your attention.
How many?
How many is normal? Boris Cherny runs five to ten sessions at a time, which between them hold a few hundred agents, and thousands more overnight. Peter Steinberger runs five to ten agents in parallel on his projects. Ben Vinegar keeps about six checkouts going.
Macro actions
Karpathy describes the shift as working in macro actions. Not a line of code or a function at a time, but whole pieces of functionality. Here's a new feature, give it to agent one. Here's another that won't interfere with the first, give it to agent two.
Isolation
The first rule is isolation. Agents can't safely edit the same folder at once. So give each one its own checkout. Git worktrees make this cheap: each agent gets its own folder and branch, and comes back as a pull request. Matt Pocock says he now uses worktrees for everything.
Worktrees share your local services, though: the same database, the same caches. Teams running agents at scale, like Cursor and Airbnb, move to cloud sandboxes, where each agent gets its own machine with its own database. More setup, but it scales to hundreds of agents.
The orchestration tax
Now the hidden cost. Addy Osmani calls it the orchestration tax. More agents running does not mean there is more of you available. Your cognitive bandwidth does not parallelize. Peter Steinberger says it feels like managing five or ten employees at once, and it's mentally more taxing than writing code.
Naive parallelism
And naive parallelism backfires in software. Luke Alvoeiro from Factory lists the problems: agents step on each other's changes, duplicate work, and make inconsistent architectural decisions. Matt Pocock warns that sixteen agents on sixteen backlog tasks would be absolute hell, full of merge conflicts and hidden dependencies.
Reads vs writes
Factory's answer is surprising. They run feature work serially, one writer at a time, and parallelize only the read-only work: searching code, researching APIs, reviewing. It looks slower on paper, but the error rate drops dramatically. Parallelize reads freely. Parallelize writes only when tasks truly don't overlap.
What works
So what works? Pick tasks that don't touch the same code; you can even ask the agent which tasks will intersect. Make dependencies explicit, so blocked work waits its turn. Prefer longer, self-verifying tasks, so you check in less often. And Lauren Tan's rule: you can't spawn a hundred agents when you don't even trust the output of one.
Competition mode
There's also a different way to use parallel agents: competition. When Mitchell Hashimoto has low confidence in a task, he gives the same prompt to different agents in separate checkouts, and keeps the best result.
Quick check
Quick check. You have six backlog tasks, and three of them touch the same checkout module. How should you run them? Tap your answer.
Try it
Plan your next batch of work for parallel agents. This prompt finds what can run side by side, what must wait, and starts the first task in its own worktree.
Recap
Recap. Run agents in parallel on work that doesn't collide. Isolate each one: worktrees locally, sandboxes at scale. Remember your attention doesn't parallelize. Parallelize reads freely and writes carefully. And trust one before you run ten. Next: agents that run for hours on their own.