Parallel versus sequential agent dispatch: the real tradeoffs

The first time I ran three agents in parallel I saved 90 seconds and felt like a wizard. The fifth time I ran three agents in parallel I got three conflicting file edits, a mangled branch, and spent 20 minutes recovering. The pattern worked until it did not.

This is the decision log I use now. Three forks: parallel, sequential, or a hybrid queue. Clear when each one earns its seat.

The fork

I have three tasks I want done by agents. Do I dispatch them all at once in parallel, dispatch them one at a time sequentially, or queue them in some ordered-but-concurrent shape?

The seductive answer is "parallel is always faster." That is true only when the tasks are actually independent. If they share state (file system, branch, context, downstream API quota), parallel is not faster. It is just broken.

Option A: parallel dispatch

What it gives you: wall-clock speedup. Three tasks that each take 60 seconds finish in 60 seconds total instead of 180. For research and review work, this is transformational.

What it costs you:

• Dispatch overhead, 3x. Each parallel sub-agent pays its own 2-4K token spawn cost. Three sub-agents is 6-12K of pure overhead.
• Race conditions. If two agents write to the same file, the later write wins and you lose data.
• Coordination complexity. You have to think about which tasks touch which files, which tasks need which outputs, and how to merge everything at the end.
• Harder debugging. When something goes wrong, you have to reconstruct which agent did what and in what order. Logs are not ordered the same way across parallel runs.

Parallel is the right call for:

• Independent research tasks that return structured summaries.
• Code review with specialized roles (see agent teams for code review).
• Content generation where each piece is isolated (an email, a social post, a metadata block).
• Test runs across separate test suites.

Option B: sequential dispatch

What it gives you: predictability. One agent at a time, one result at a time, one file-system state at a time. Easy to reason about, easy to debug, easy to rollback.

What it costs you: wall-clock time. Three 60-second tasks take 180 seconds total. The dispatch overhead is the same per task but you are paying it serially, not concurrently.

Sequential is the right call for:

• Tasks that share a filesystem (see git worktrees for the alternative if you want parallel with shared repo).
• Build pipelines where step N depends on step N-1.
• Work that touches a rate-limited API (parallelizing just blows your quota faster).
• Anything where you need to approve or inspect intermediate output before continuing.

Option C: the queue

What it gives you: bounded concurrency. You run N agents at a time (usually 2-3) with a backlog of tasks. As agents finish, new tasks get dispatched. You get some parallelism without the full blast radius of "all at once."

What it costs you: a queue manager. Something has to track which tasks are running, which are pending, and how to dispatch the next one. This is usually you, running a script or a skill.

Queues are the right call for:

• Large batches of independent tasks (say, 20 emails to generate) where full parallelism would blow the model's rate limits.
• Work where you want some overlap for speed but not full fan-out.
• Long-running jobs where a human review gate is inserted between batches.

The coordination cost nobody mentions

Parallel dispatch looks free at first. Three agents, all working, no coordination visible. The cost hides in the integration phase.

After three parallel agents return, you have three outputs. Something has to merge them. If the outputs are structured (JSON, markdown with known sections), an agent can merge them cheaply. If they are loose prose, a human usually ends up doing it.

The integration phase is where I have burned the most unexpected time. I save 90 seconds on dispatch and spend 10 minutes merging. Net: I lost time and burned tokens.

The fix: when I dispatch in parallel, I give each agent a schema for its output. "Return a JSON object with fields X, Y, Z." Now the merge is deterministic and cheap. Without the schema, the merge is ad hoc and expensive.

What I chose and why

Default to sequential. Dispatch in parallel only when:

1. The tasks are provably independent (no shared files, no shared state, no shared rate-limited API).
2. The outputs are structured so merging is a deterministic operation.
3. The wall-clock savings actually matter for the workflow I am in.

If any of those fail, I go sequential or I queue.

The tasks where parallel is an obvious win:

• Research across multiple files or services. "Read these ten sources in parallel and summarize each" is embarrassingly parallel.
• Review with specialized roles. Three reviewers, three output files, one coordinator at the end.
• Content batches. Ten emails to draft from ten briefs. Each one is independent.
• Test suites. Run the unit tests and the integration tests and the lint in parallel.

The tasks where I have learned to go sequential:

• Code edits in the same repo. Without worktrees, parallel edits race.
• Database migrations. Order matters. Sequential is the only safe path.
• Anything behind a strict rate limit. Parallel just makes you hit the limit faster.
• Work that depends on output from the previous task. Duh, but I have made this mistake.

The sub-agent overhead math

Each parallel sub-agent pays its own dispatch tax. For three parallel agents doing 15K-token tasks:

• Per-agent spawn: ~3K tokens
• Per-agent return: ~2K tokens
• Total overhead: 15K tokens across three agents
• Total actual work: 45K tokens

Overhead is about 25 percent. Fine for big tasks. Painful for small ones. The sub-agent decision log covers when dispatch is worth it even for one agent. Applied to parallel, the same rule gets stricter: the task has to be big enough that the wall-clock savings outweigh both the dispatch tax and the integration cost.

What I would revisit

Three things I do not have clean answers on yet.

The queue-vs-parallel threshold. I run parallel at 3-4 tasks. Past that I queue. But I have not measured whether the break-even is actually 4 tasks or 7. Depends on task size and rate limits.

Cross-agent communication. Sometimes agents in a parallel run would benefit from seeing each other's intermediate state. I have no clean pattern for this yet. Current workaround is to split into two sequential rounds with a coordinator in between.

Retries on partial failure. If three parallel agents return and one failed, do I retry just that one, or does the failure cascade? I mostly retry the one, but I have not automated it well.

For operators who run this pattern daily, the Operator's Stack curriculum walks through the dispatch decisions in the context of real DTC ecommerce work. The broader agent handbook indexes the full decision set.

FAQ