When can AI agents actually run in parallel?

The advice most people are given about running AI agents at the same time is a number. Don't run more than one. Or don't run more than three. Or run as many as you like, it's fine.

All three are wrong in the same way, because the number was never the variable.

I learned this expensively. I once pointed 5 agents at a single feature and got a mess I couldn't even write up afterwards. For a long time I told that story as a lesson about 5 being too many. It wasn't. All 5 were working on one branch, one working tree, and one settings object they each had a different opinion about. Two would have failed identically.

The rule people are given, and why it's too blunt

The standard advice — multi-agent is a sequential practice, not a parallel one — is right about the failure it observed and wrong as a general law. It conflates two different things.

Contention is two agents mutating the same thing at the same time. Real, expensive, correctly forbidden.

Concurrency is several agents doing several bounded jobs that share nothing. That isn't a failure mode at all. It's just work getting done.

Collapsing them into one rule bans the second in order to prevent the first. So here's the version that actually holds, and it's two questions rather than a headcount.

Question one: is there an edge?

An edge means one agent's output is another's input. Something actually crosses between them.

The word that trips people is after. "Run the API work after the schema work" sounds like a dependency, and sometimes it is — if the API work reads the schema the first job produces, that's a genuine edge and the two must go in order. But "run the docs update after the tests" is usually not a dependency at all. It's just the order you happened to write them down.

The test is to name what crosses. If you can name the artefact — the schema, the route table, the migration — it's an edge. If the only thing you can say is "it comes second", it isn't one, and you've been queuing for no reason.

This is also why a lead agent and a review agent run in sequence and always will. The reviewer reads what the builder produced. You can't review an artefact that doesn't exist yet. That's a real edge, and it's the one that made the old rule look universal.

Question two: is there a shared surface?

A surface is everything an agent mutates or contends for.

Files are the obvious part. The part that catches people is everything else — a database, a rate-limited external API, a message queue, a staging environment, one deploy target. Anything two agents both reach for.

The failure has a name worth knowing: false independence. Two agents whose instructions never mention each other, quietly colliding over something neither brief declared. One writes a row the other deletes. Both burn the same API quota and one starts getting 429s. Both deploy to staging and the second overwrites the first.

Hidden edges bite hardest, because nothing in the plan says they exist. When I check a plan now, I don't ask what each brief writes. I ask what it contends for.

That check takes about 5 minutes and it's mostly already written down. If you use prompt briefs, each one carries a pre-flight list of the files it will touch, and that list is most of the answer. Put them side by side and add the things a file list can't show:

PB-1  auth middleware        files: src/auth/*        also: sessions table, staging deploy
PB-2  billing webhook        files: src/billing/*     also: Stripe test API (rate limited)
PB-3  docs for both          files: docs/*            also: —

edges     none — no brief reads another's output
surfaces  PB-1 and PB-2 share nothing · PB-3 shares nothing
verdict   all three fan out

Three columns, one per brief. Files, then everything else it reaches for. If two rows collide anywhere in that second column, you've found a hidden edge and those two sequence. If nothing collides, they run at once.

Stuart Leo

Two agents on one surface is the anti-pattern, however urgent the session feels. Twelve agents on twelve disjoint surfaces, each with a brief that clears the quality gate, is the method working.

Isolation solves one of these, not both

Git worktrees are the standard fix for parallel agents, and they're genuinely good. A worktree is a second working directory attached to the same repository, checked out to its own branch, so each agent gets a filesystem nobody else can touch.

But be precise about what that buys. A worktree isolates the filesystem and nothing else. Two agents in two immaculate worktrees still collide on one shared database, because the database was never in the worktree.

So isolation is the seatbelt for one specific topology — parallel writes to files — not a general permission slip. It's worth using every time you fan out. It is not the thing that makes fanning out safe.

The decision table

Both questions, in one place:

The honest cost of the fan-out is that it asks you to do the thinking up front. You have to know what each job touches before you start, which means writing the brief properly rather than discovering the scope as you go. That's real work, and on a small change it isn't worth it.

When not to bother

Most days, don't.

Skip it when the task is small or self-contained. Skip it when the work is exploratory and you don't yet know what you're looking for, because a wide run explores confidently in 6 wrong directions instead of 1. Skip it when the steps genuinely depend on each other. And skip it when you want to approve every step — that's a legitimate choice, and a fan-out is precisely the shape that runs without you watching each move.

The tell is simple. If you can't find two jobs with no edge between them, there's nothing to spread. One agent working in sequence is the right answer, and it's the right answer far more often than the current enthusiasm suggests.

The test is the surface

The number of agents was never the thing. It's a proxy people reach for because it's easy to count, and it gets the diagnosis wrong in both directions — banning safe concurrency, and permitting 2 agents to trample one file because 2 sounds modest.

Ask the two questions instead. Is there an edge, and is there a shared surface? Agents run at once when the answer to both is no. The test is the surface, not the headcount.

Start here: see multi-agent vs single agent, how to isolate parallel agents with git worktrees, or read the method.