The first time you run two agents at once it feels like a cheat code. Two tasks moving while you drink one coffee. So you run three, then five, then eight, and somewhere in there the feeling changes. You’re not writing code anymore and you’re not really resting either. You’re context-switching between panes, holding eight partial states in your head, deciding whose turn for your attention is next. You’ve given yourself a second job, and the job is scheduler.
I run work this way every day building PaellaDoc, and parallelism is genuinely how you get throughput out of agents. But the throughput isn’t free, and the cost isn’t tokens. It’s a specific kind of human attention that gets more expensive the more sessions you add, and understanding that cost is the difference between parallelism that scales and parallelism that just makes you frazzled.
The mechanical part: worktrees
The enabling trick is git worktrees. A worktree is a second working directory backed by the same repository, on its own branch. Instead of one checkout that every agent fights over, each agent gets its own directory and its own branch, and they can all edit at full speed without touching each other’s files.
This matters because the naive setup, several agents in one directory, corrupts itself immediately. Agents can’t see each other’s uncommitted changes, so two of them writing to the same tree will overwrite and confuse each other constantly. Worktrees give each agent isolation, which is the precondition for everything else. Collisions don’t vanish, they move to the merge, where you can handle them deliberately. This is the mechanical floor under all multi-agent work: without isolation there’s nothing to orchestrate, just a pileup.
The setup itself is not complicated. A worktree per task, a branch per worktree, an agent per branch. The complexity isn’t in the git mechanics. It’s in the human standing in the middle of eight of them.
The part nobody warns you about: you’re the scheduler
Once the worktrees are running, a new role lands on you whether you wanted it or not. Every one of these jobs is now yours, all at once:
- Priority. Which session gets your attention next? They finish and stall at different times, and the one that needs you isn’t always the one you’re looking at.
- Context. Each session holds a different piece of the product in its head, and so must you, because when session four asks a question, you need to reload what session four was even doing.
- Recovery. A run dies at an awkward moment and just sits there, done nothing, waiting. If you don’t notice, it’s a dead pane burning nothing but your throughput.
- Routing. Different tasks want different engines, the architecture task and the mechanical refactor shouldn’t run on the same model at the same cost, and picking is on you. That’s the whole argument for routing every task to the right engine, which becomes acute exactly when you’re running many at once.
- Integration. They all come back as branches that have to merge into one coherent thing, and the merge is where the drift between them surfaces.
None of these is hard in isolation. The cost is that they’re concurrent and they’re interrupt-driven. You don’t get to do them in order. You get pulled to whichever pane demands you, mid-thought on another one, and every switch pays the tax of reloading what you were doing there. That reload is the same context loss that hits the agents, except it’s hitting you, in real time, eight ways at once.
Why the cost is superlinear
Here’s the uncomfortable math. Two sessions is not twice the load of one. It’s more, because on top of the two sessions there’s the switching between them, and the switching cost grows faster than the session count.
With one session you’re never interrupted, there’s nothing to switch to. With two, you switch occasionally. With eight, you’re almost always mid-switch, and the states are colliding in your working memory: you go to answer session three and can’t immediately remember whether the thing you’re looking at belongs to three or to six. The sessions scale linearly. The coordination between them, the thing that’s actually running on you, does not. That’s why five agents can feel productive and eight can feel like drowning, even though it’s only three more.
This is the concrete, felt version of the whole runtime argument. When people say a good developer can run agents fine by hand, they’re right, and this is exactly the “by hand” part. You’re the scheduler, the memory, the recovery loop, and the router, all in real time, and the reason it works is that you’re absorbing a superlinear coordination cost with human attention. It works right up until it doesn’t, and where it stops is different for everyone but it always stops. The manifesto’s name for this is that you are the runtime, and running eight sessions is the most physical way to feel it.
What actually helps
You don’t fix this by running fewer sessions, that just caps your throughput at whatever one human can babysit. You fix it by moving pieces of the scheduler’s job off yourself and into the system.
The routing decision can be made by a router instead of by you picking a model per pane. Recovery can be a governed retry that notices a dead run and restarts it, instead of you catching the stalled pane, which is a whole discipline once you treat recovery as a first-class workflow. Context can live in durable memory each session loads on its own, so switching to session four doesn’t require you to personally remember what four was doing. Integration can be a real reconciliation step instead of you merging eight branches by feel and hoping. This is the same reason agents need a runtime and not just a bigger model: intelligence per session doesn’t touch the coordination cost between sessions, and the coordination cost is the thing that’s actually capping you. I wrote the long version of that in agents need a runtime, not a bigger model.
Each of those moves takes one job off the scheduler, which is you. Do enough of them and the superlinear cost stops climbing with every added session, because the coordination is happening in the system instead of in your head. That’s the whole game: not more agents watched by a more heroic human, but the same agents coordinated by something that isn’t your attention. Run eight sessions if you want the throughput. Just don’t be the eighth thing holding it all together.
How many parallel sessions can you run before you stop building and start refereeing? Tell me on the forum.
Frequently asked questions
How many agent sessions can I run in parallel?
There is no fixed number; the limit is where the coordination cost outruns your attention, and it is different for everyone. What is predictable is the shape: five sessions can feel productive and eight can feel like drowning, even though it is only three more. The cost is superlinear because the switching between sessions grows faster than the session count. You extend the ceiling by moving the scheduler’s jobs into the system, not by being more heroic.
How do I run multiple AI coding sessions at once?
Use git worktrees: one worktree per task, a branch per worktree, an agent per branch. A worktree is a second working directory backed by the same repository, on its own branch, so each agent edits at full speed without touching another’s files. The naive setup — several agents in one directory — corrupts itself immediately, because agents cannot see each other’s uncommitted changes. Worktrees give the isolation that everything else depends on.
Why does running many agents in parallel get overwhelming?
Because you become the scheduler, and five concurrent jobs land on you at once: priority, context, recovery, routing and integration. They are interrupt-driven, so you are pulled to whichever pane demands you mid-thought on another, and every switch pays the cost of reloading what you were doing. That reload is context loss hitting you in real time, eight ways at once. The sessions scale linearly; the coordination running on you does not.
What are git worktrees and why do agents need them?
A worktree is a second working directory from the same repository on its own branch. Agents need them because isolation is the precondition for parallel work: without it, two agents writing to the same tree overwrite and confuse each other constantly. Worktrees do not make collisions vanish, they move them to the merge, where you can handle them deliberately. This is the mechanical floor under all multi-agent orchestration.