The first time I ran four article writers in parallel, the batch finished in 22 minutes and I felt clever. Twelve in parallel went the other way: the orchestrator's context filled up before the last writer reported back, two of them stalled fighting over a shared registry write, and the whole batch took longer than running them sequentially would have. The pattern that worked at four did not just degrade at twelve. It inverted.
This is the decision log I use now to size sub-agent parallelism on a real run. There are three honest forks: sequential, parallel at three to five, parallel at eight or more. Each one has a price tag and a sweet spot. Past that sweet spot, the math turns on you.
The fork at three agents
The decision point shows up around three in flight. With one or two agents, the question is whether parallel is even worth setting up. Past three, the question is how far to push it before the orchestrator's own context becomes the bottleneck.
What was at stake on the run that pushed me to actually do the math: a 60-article content batch, each article going through an 8-stage pipeline with its own writer sub-agent. End to end, a single writer takes 25 to 40 minutes in its own context window. Sixty of them sequential would have been a 30-hour wall-clock job. Sixty of them all at once would have, in theory, finished in 40 minutes. The theory is wrong, and learning where the theory breaks is the entire point of this post. The decision-log voice I use here is the same one the parallel versus sequential piece opens with, so this is a deeper pass on a question I keep coming back to.
Option A: Sequential, one writer at a time
What it gives you. The cheapest per-task on raw tokens. Each writer fires up, runs its 8 stages, returns a final report, and gets discarded. The orchestrator's context grows by the size of one report at a time, which on my run averages 2.5K tokens per writer. After 60 sequential runs, the orchestrator has absorbed 150K tokens of reports, which is recoverable through compaction or a fresh handoff session.
You also get the cleanest debugging story. If a writer fails, you see exactly which one, you see the whole report stream up to the failure, and you can re-dispatch without disturbing anything else. No interleaved logs, no race conditions on shared state, no mystery about which writer wrote which line.
What it costs. Wall time. A 60-article batch at 30 minutes per writer is 30 hours of compute time. If you are paying for compute by the hour or your harness has a per-session budget, that is a real bill. More importantly for me: 30 hours is two full work days where I cannot ship anything else through the same harness, because the orchestrator session is occupied.
You also lose the one thing parallel runs are genuinely good at: surfacing common failure modes early. If three writers in parallel hit the same MDX parse hazard, you fix the writer prompt once and re-dispatch. If sixty writers run sequentially, you might hit the same hazard on writer 4, fix it manually in the output, and not realize until writer 47 that this is a systematic issue.
Option B: Parallel at three to five writers
This is where most of my real work lives. The "first sweet spot" of parallel sub-agent dispatch.
What it gives you. Real wall-time gains. Five writers in parallel finish a 60-article batch in roughly twelve waves of about thirty minutes each, which is six hours total instead of thirty. The cost ratio is the most important number in this post: at five-way parallelism, my orchestrator context fills with about 12.5K tokens of reports per wave (five writers, 2.5K each), which is small enough to keep the main session healthy across all twelve waves without compaction.
The tool-tax math at this scale is also forgiving. Each sub-agent dispatch incurs a fixed cost of around 1.5K to 2K tokens for tool definitions and the harness preamble before any work happens. At five writers, you spend 7.5K to 10K on tool definitions per wave. Across twelve waves that is 90K to 120K of pure overhead, but you reclaim multiples of that in wall-clock savings.
Coordination overhead is real but manageable. Two writers occasionally try to update the shared registry at the same moment. The optimistic SHA256 retry pattern I describe in the agent failure modes piece handles this cleanly: write, re-read, if the hash changed, re-merge against the latest file. Across the 60-article round and a follow-up 48-article round, that retry path fired maybe a dozen times total. Zero corruption events.
What it costs. You give up some debuggability. Five interleaved writer streams in the orchestrator's view are messier than one. If something breaks, you do triage instead of inspection. The fix is structured audit logs from each writer's last step, the same pattern that the agent council pattern for executive decisions uses to keep parallel personas legible to a coordinator.
You also pay a planning cost up front. Splitting 60 articles into 12 waves of 5 means picking 60 topics, ordering them so each wave makes sense, and pre-loading the registry with the slugs the orchestrator expects. If the input list shifts mid-run, you start eating coordination tax.
Option C: Parallel at eight or more writers
This is where the breakeven argument falls apart. I learned this the slow way.
What it gives you, in theory. Even better wall-time. Eight in parallel should knock the 60-article batch from six hours to four, and twelve in parallel should bring it to three. The math says push harder.
What it actually costs. Each writer comes back with a final report that the orchestrator absorbs into its context. At 2-4K tokens per report depending on how rich the writer's verification block is, eight parallel reports land 16-32K tokens of new context on the orchestrator in a single wave. Twelve reports land 24-48K. By the second or third wave at twelve-wide, the orchestrator is sitting on 60-100K of report data plus the original orchestration prompt plus tool definitions plus any in-flight thinking. The context window is finite. The token budget piece goes deep on the actual numbers; the punchline for sub-agent dispatch is that the orchestrator gets squeezed faster than people expect.
The other cost is failure variance. With three writers in flight, the probability that all three succeed is high enough that I rarely hit a recovery loop. With twelve in flight, the probability that at least one fails goes up sharply, and a single failed writer can poison the wave: the registry was supposed to receive 12 entries, it got 11, the next wave's writers see an inconsistent state, and now I am triaging a multi-writer dependency graph instead of shipping articles.
The third cost, the one I did not initially price: registry contention. With three writers, the SHA256 retry pattern fires maybe once per batch. With twelve, two or three writers can be staring at the same in-flight write, and the retry depth grows. I have seen four-deep retry chains at twelve-way parallelism. Each retry costs the writer real seconds. At enough scale, the gain from extra parallelism gets eaten by the overhead of the writers fighting over the shared resource.
How I model the cost now
The actual model I run in my head before dispatching has three terms.
Per-task cost. A sub-agent's bill covers three things: the tool-definition tax (1.5K to 2K when it spins up), the body of the work itself, and the final report it returns to the orchestrator. For an article writer running the 8-stage pipeline, the body lands somewhere between 80K and 140K tokens of internal context across all stages, and the final report is the piece that touches the orchestrator. The writer's internal context dies with the writer; only the report persists.
This is the most important reframe in the whole article. Sub-agent context is ephemeral; orchestrator context is the scarce resource. You can run a 200K-token writer in its own context all day. What you cannot do is run twelve of them and have them all dump rich reports back into the orchestrator without paying for it.
Parallelism gain. End-to-end wall time. Sequential N writers takes N times the per-writer time. Parallel-K writers takes ceiling(N / K) waves. The shape is sublinear gains as K grows, because each wave's wall time is set by the slowest writer in that wave, and slowest-of-K grows with K.
Breakeven point. Where the orchestrator context cost equals the wall-time savings. The heuristic I land on after the article-writer runs: K equals five for rich-output writers (2-4K reports each), K equals eight for thin-output writers (1K reports each), K equals two or three when the writers share a contended resource that needs serializing.
“Sub-agent context is ephemeral; orchestrator context is the scarce resource.
”
The two real-world numbers that anchor my heuristic: a 60-article writer round at five-way parallelism completed cleanly in roughly six hours of wall time, with an orchestrator context that stayed under 250K tokens across all twelve waves. A follow-up 48-article round at four-way parallelism completed in about five hours, with even more headroom on the orchestrator side because each wave was leaner. Those two runs told me where my own breakeven sits for this specific kind of work.
What I'd revisit, with what evidence
A few things would change the math, and I am watching for them.
Sub-agent prompt caching. If the harness lets a sub-agent reuse a cached system prompt across dispatches, the per-task tool-tax shrinks meaningfully. At eight-way parallelism, knocking 1.5K off each writer's startup is 12K reclaimed per wave. Across twelve waves on a 60-article batch, that is 144K of orchestrator-side budget I get back. Worth re-running the breakeven math when this lands cleanly.
Smaller report formats. I am experimenting with structured JSON reports of around 800 tokens instead of free-prose reports of 2-4K. If I can get good information density at one-third the report size, eight-way parallelism stops squeezing the orchestrator and the breakeven point moves up to ten or twelve. Trade-off: structured reports are harder to debug at a glance.
Coordinator-of-coordinators pattern. Instead of one orchestrator running twelve writers, run three orchestrators each running four writers, with a coarse coordinator above them. The shared resource (registry) becomes the bottleneck, but the orchestrator-context exhaustion problem disappears, because each sub-orchestrator only sees its own four writers' reports. This is more harness work than I have wanted to do, but it is the obvious next move if I want to push past sixty articles in a single run.
Harness features that change the math. When the platform adds features like report-only sub-agents, persistent sub-agent context across dispatches, or token-bounded final reports, the breakeven point moves. I do not bet on specific features shipping. I do re-run the math when they do.
For operators running this kind of dispatch in production, the skills I actually use for Shopify development covers a different angle on the same theme: keeping each sub-agent's surface narrow so the per-task cost stays sane. The Operator's Stack curriculum walks through the parallel-dispatch math alongside the rest of the agent engineering discipline I lean on, and the agent handbook hub is the index for the broader set.
FAQ
What is the actual orchestrator context overhead per parallel sub-agent?
On my runs, each sub-agent's final report lands somewhere between 1K and 4K tokens depending on how rich the verification block is. At five-way parallelism that is 5-20K per wave, which is sustainable. At twelve-way parallelism it is 12-48K per wave, which becomes the bottleneck within a few waves.
Why does the breakeven point sit around five and not higher?
Because orchestrator context, not per-task token cost, is the binding constraint. Five rich-report sub-agents fit comfortably in a single wave without crowding the orchestrator. Eight or more starts to push the orchestrator into compaction territory, and compaction loses detail that downstream waves depend on.
Can prompt caching push parallelism higher?
Possibly. Caching the system prompt across dispatches shaves 1.5K to 2K per sub-agent startup, which compounds at scale. I have not run a clean A/B yet. The breakeven for me will move up when caching is reliable across parallel sub-agents in the same harness session.
When does sequential beat parallel outright?
When the writers share a heavily contended resource (a single registry, a single file, a single API rate limit), or when failure cost is high and you need to inspect each run in detail. For exploratory work where you want to learn from the first three runs before doing the next sixty, sequential is the right call.
Is twelve-way parallelism ever the right answer?
Yes, when each writer has a tiny report (under 1K) and no shared state. If your sub-agents are doing parallel reads with structured output, twelve-way works. If they are doing parallel writes to a shared file or producing rich prose reports, twelve-way will burn your orchestrator before it finishes.
Sources and specifics
- The 60-article writer round and the 48-article writer round referenced here both shipped on the same day in late April 2026, using a custom orchestrator with five-way and four-way parallel sub-agent dispatch respectively.
- The 2.5K-token average final report figure is from the article-writer pipeline used on those rounds, where each writer returns a structured report covering slug, title, template, word count, demo component, links, and verification status.
- The orchestrator context exhaustion event at twelve-way parallelism was a single incident on an experimental run, not a published batch, and it informed the breakeven heuristic in this article.
- The SHA256 optimistic concurrency pattern on shared registry writes is the same one documented in this site's broader sub-agent failure-recovery posts; it fires maybe a dozen times across a hundred-plus parallel writer dispatches with zero corruption events on file.