Parallelism is intuitively appealing. Eight units of work, eight agents available — what's the argument against?
The arithmetic leaves out three costs: splitting, waiting on shared resources, and merging. Add all three and the answer flips more often than not.
1. What Makes Work Divisible
One test: can each item ignore every other item's result?
Applying that to this repo's content work splits it cleanly.
Topic selection looks like the most parallelizable step and is exactly the opposite. Tell eight agents "each pick a good topic" and several come back with the same one, because each is reading the same list of existing posts and finding the same gap.
2. Shared Resources Don't Parallelize
Writing was called divisible, with a condition attached: writing a post and committing it are different jobs.
Eight agents creating files in one working tree and each running the build will see each other's half-finished states. If A runs the build while B has written only its Korean file, A's build fails — B's incomplete work trips the ko/en symmetry check.
A did nothing wrong and A fails. Worse, A can't tell why, because the error names a file it never touched.
This work took the second. Each build takes well under a second, so the bottleneck is effectively nothing. Standing up isolated workspaces and reconciling them afterward costs far more.
The deciding question is how long the shared resource is actually held. If the build took ten minutes, the answer changes.
3. The Merge Cost Is the One People Forget
Parallel results have to be read and judged by someone. That step is missing from nearly every estimate.
Eight agents return eight posts, and now those eight have to work together.
- Is the same concept called different things in different posts?
- Do three of them lean on the same example?
- Do the cross-links point at posts that exist?
- Does it read like one person wrote it?
Answering those means reading all eight. All eight then have to fit in the reviewer's context — a cost that simply doesn't exist when writing sequentially.
Sequential work accumulates that context as a side effect. By post five you already know the terminology and examples from one through four, so there's nothing to reconcile. Parallelism buys speed by discarding exactly that.
Put numbers on it and the break-even shows up
Turning "this should be faster" into arithmetic makes the crossover visible. With N items, T per item, a fixed cost F to spin up one agent and brief it, and M to read and reconcile the results:
Filling in what the eight posts actually cost — twelve minutes each, and ninety seconds to spin up an agent and hand it a brief:
Seventy-two minutes sounds like a lot. It isn't. Reading all eight closely, aligning terminology and pulling out duplicated examples at nine minutes a post is 8 × 9 = 72 — exactly break-even. And that's before any rework on the two that drifted.
(N−1) × T is the ceiling on what parallelism can win.
No matter how large N gets, the gain never exceeds N−1 times a single item, while spin-up and merge costs both grow with N. That's where the instinct that finer splits mean bigger wins breaks down.
4. Where the Split Actually Landed
In the end what ran in parallel here was research, not writing.
Research fits parallelism for two reasons: the items really are independent, and the outputs are small, so merging is cheap. Reading eight ten-line summaries is not remotely comparable to reading eight full posts.
That generalizes into a usable rule. Parallelism suits work that searches wide and answers narrow. Input scattered across many places, output compressed — exploration, search, collection, verification.
Conversely, work with large output gains little. When the artifacts themselves are big, reading and reconciling them can cost as much as producing them did.
Sorting the common work types in advance
To avoid re-deriving this every time, we sorted the work we do often. The three columns are the three costs from above.
The striking row is the last one: planning has small output and still rates worst. Output size is only one of the three costs, and here item independence is simply absent — the exact case from section 1.
"Mechanical per-file edits" runs the other way: a medium merge cost and still a good fit, because nobody reads the results to judge them — the build checks them instead. Any merge cost you can hand to a machine moves that row up a grade.
5. What Shouldn't Be Split at All
Some work gets worse when divided, regardless of speed.
- Anything needing one consistent voice. Writing meant to read as one author's shows its seams the more it's divided.
- Anything judged across the whole set. Overlap, balance, ordering — none of it is visible from a single item.
- Anything hard to undo. Eight agents heading the wrong way means undoing eight things. The blast radius widens with the fan-out.
The third matters most for unattended runs. Sequential work lets you notice something is off at item two and correct course from item three. Parallel work reveals it only after all eight have finished. Giving up the chance to correct mid-flight is parallelism's hidden cost.
6. The Order of Questions
When unsure whether to split, work down this list.
Question one eliminates most candidates — and it's the one most often answered wrong. Items that never reference each other look independent, while a constraint like "these must not overlap" quietly binds the whole set together.
When One of the Eight Fails
Fanning out introduces a state that sequential runs don't have: partial failure. Run in sequence and a stop at item three simply means three items are the result.
We've used four ways of handling it, and each belongs somewhere different.
Our default is keep partial. Throwing away six good posts because two failed hands back the entire gain. It holds only under one condition, though: the repository has to be in a valid state with just the successes. Here a post is a ko/en pair, so six of eight still leaves symmetry intact.
Retries are capped at one. A second failure means the cause wasn't transient, and a third attempt just buys the same failure again. Unbounded retry is especially dangerous unattended — nobody is watching while it repeats the same failure.
The fourth turned out to be the answer more often than expected. If the failure came from the shared-resource interference in section 2, rerunning in sequence removes the cause outright. That makes it worth trying first whenever the answer is "no idea why it failed."
Frequently Asked Questions
How many agents should run at once?
Concurrency isn't usually the binding limit — merge cost hits the wall first. In the formula, M grows with N while a reviewer's capacity to read and judge does not. For research and verification with short outputs, eight was fine. For writing, with large outputs, anything past three made merging the bottleneck.
Why not let the parallel agents talk to each other?
Then it isn't parallel. Needing each other's results means it already failed question one. Adding conversation adds waiting, and once there's waiting, total time is set by round trips rather than by the slowest single item. Where dependencies exist, sequential is simply faster.
What about running the same task several times and picking the best?
That's not parallelism for speed, it's redundancy for quality — a different goal with different arithmetic, where the payoff comes from variance rather than time. The earlier trap applies unchanged, though: identical input yields several near-identical answers. For it to be worth anything, each agent needs a genuinely different angle or constraint.
The parallel results came back in wildly different shapes
That's not a briefing problem, it's an unspecified output format. Accept free-form results on the assumption a human will reconcile them and merge cost rises accordingly. Pin the shape down in advance — field names and order included — and the merge step can concatenate instead of read. That's what "handing merge cost to a machine" meant in the table above.
How do you notice that one of them stalled?
Judge completion by artifacts, not by the agent's report. A failed agent can still say "done"; it can't produce two files and a passing build. This isn't specific to parallelism — it's the same idea as designing work to be resumable. When the completion marker lives in the result itself, you can tell later which items stopped.
Is it ever worth splitting when there's no speed gain?
Yes — when one task doesn't fit in a single context. The reason to split there isn't speed but capacity, and the criteria change accordingly. That's closer to choosing what to feed an agent than to anything here.
7. Summary
- Divisible means no item needs another's result. Set-wide constraints are dependencies too.
- Parallel decisions over identical input produce duplication, not variety.
- Shared-resource sections don't parallelize. If they're held briefly, just serialize them.
- Count the merge cost. The bigger the artifacts, the smaller the gain.
- It suits work that searches wide and answers narrow — exploration, collection, verification.
- Fanning out also forfeits the chance to correct mid-run.
Writing eight posts sequentially took longer than fanning them out would have. But something learned while writing post three changed the structure of post four, and an example from post five came back in post seven. Split apart, those connections never form — and a human would be reconciling all eight by hand afterward.
Parallelism is a trade: speed bought with context. It's a good trade where context barely matters, and a bad one where context is the quality of the result.