Parallelism: When Parallel Agents Earn Their Overhead
Introduction: The Arithmetic Nobody Does Before Dispatching
Adding agents adds work. That is the uncomfortable starting point of the Superpowers parallel agents theme, and it is the sentence that separates teams that get faster from multiple subagents from teams that just get more busy. A sequential run costs roughly the sum of its tasks. A parallel run costs something different: dispatch (writing a self-contained brief per lane) plus the longest lane plus integration (reading every report back, checking for conflicts, verifying the pieces work together). Parallelism wins only when collapsing the sum beats the two new terms it introduces — and there are whole classes of work where it doesn’t.
The three skills that make up this theme each answer a different part of the question. dispatching-parallel-agents is the mechanics: how to write a brief and run lanes concurrently. subagent-driven-development is the discipline: fresh context per task, a review gate per diff, and a hard rule about what may never run concurrently. executing-plans is the honest baseline: the sequential checklist that is often the right answer, and always the fallback when the parallel math doesn’t close.
This article is the decision procedure between them — grounded in a real audit where the answer was yes, and the failure modes where the answer is no.
Real Example: The SYNAS Storage + Network Parallel Audit
SYNAS is a home lab server running 32 Docker containers across 26 networks on OpenMediaVault — 62 GB of RAM, game servers, an n8n/Tactical RMM stack, an LLM stack, Plex, Vaultwarden. The job was a full health audit. Read as one task, it is a monster: image hygiene, volume usage, writable-layer waste, network topology, attachment mapping, isolation quality, orphan detection. Read as the decision tree below prescribes, it is three lanes — and two of them are textbook-parallel.
A storage lane (image and container disk usage, volume inventory, build cache, dangling artifacts) and a network lane (every network, every attachment, isolation assessment, orphans) share nothing: different commands, different data, different conclusions, zero file overlap. Both are read-only. So the orchestrator dispatched both as a single batched call and let them run concurrently, while the third lane — the health roll-up, which depends on what the other two find — waited its turn.
Both subagents finished in roughly three minutes. Sequentially, the same work was about six minutes of wall clock — a two-for-one, respectable but not the headline. The headline is what isolation bought: each agent could hold its entire lane in context — dozens of command outputs, cross-referenced line by line — in a window dedicated to exactly one question, while the controller stayed lean for integration. What came back was evidence, not vibes:
- Storage agent: roughly 1.9 GB of dangling images, 532 MB of dead build cache, and one container quietly writing 1.87 GB into its own writable layer instead of a volume — a finding no one had asked it to hunt for, caught because the whole disk picture was in front of one focused mind.
- Network agent: a complete map of all 26 networks and every container attachment, an isolation quality assessment, and an orphan check.
Three rules made this safe, and they are worth naming because they are the ones people skip. The lanes were read-only — auditors that can’t edit can’t conflict. The prompts were self-contained — each said what to run, what to conclude, and in what format to return, without inheriting session history. And the toolsets were least-privilege — terminal and files for a disk auditor; a browser open on an audit lane is one accidental detour from a wasted run. Headline claims got re-checked with fresh commands before anything shipped, which is the executing-plans contract applying to parallel output: a subagent’s summary is a report to verify, not a fact to paste.
The Decision Tree: Independent? Parallelizable? Shared State?
The skills agree on one procedure. Before any dispatch, answer three questions in order — the order matters, because each gate is cheaper to test than the next.
Is this 2+ tasks in genuinely different problem domains?
│ (each can succeed or fail without affecting the others)
├─ No → SEQUENTIAL. One agent holding the whole picture.
└─ Yes ↓
Can each task be briefed self-contained?
│ (goal + context + constraints + output format, no session history)
├─ No → You're still in discovery. Brainstorm first, then re-ask.
└─ Yes ↓
Any shared state? (same files, same config, same mutable resource)
├─ Yes → SERIALIZE the contended resource, or split the state
│ (git worktrees), then re-ask.
└─ No → DISPATCH IN PARALLEL. Batch the lanes, one domain each.
Gate one kills most bad dispatches. “Two tasks” is not the test; “independent problems” is. Fixing a validation bug and fixing a formatting bug in the same request pipeline are two tasks with one problem domain — the second agent redoes the first one’s investigation to learn what a request even looks like. Gate two is the briefing test: if you cannot write a lane’s brief without pasting your session’s history into it, the decomposition is fake — the lanes aren’t self-contained, they’re just your context cut into pieces. Gate three is where correctness lives. Shared mutable state is the one condition no amount of prompt engineering fixes, which is why subagent-driven-development forbids parallel implementers by name.
When Parallelism Helps
Multiple systems to check, each with its own scope. This is the SYNAS shape: storage and network are different subsystems with different commands and different definitions of “healthy.” Any inspection task that naturally splits along subsystem lines — disk vs. network, backend vs. frontend, service A vs. service B — is a candidate, because independence came from the domain, not from your imagination.
Read-only sweeps. Audits, research passes, log analysis across unrelated services, test suites that exercise different code. Read-only lanes cannot corrupt each other, so the worst failure mode is a wasted run rather than a corrupted system — and a wasted run costs minutes, not a restore.
Genuinely different failures in different files. Three tests failing in three separate modules, each with its own pasteable error and its own test command, is the canonical batch in the skill: one goal, one brief, one scoped verification per lane.
Two practical ceilings belong in the math. Hermes’ batch dispatch runs up to three subagents concurrently with a maximum nesting depth of two — agents cannot spawn their own reviewers — so six lanes is not six-way speedup; it’s two waves of three, and the queue time is real. And the serial fraction of any job caps the win exactly the way Amdahl’s law says: briefing and integration are sequential no matter how many lanes run, so five lanes on a job that is 40% integration top out just under two times faster, not five.
When It Hurts
Related failures. If fixing one problem might fix the others — three symptoms, one root cause — parallel agents are three billings for one insight, and worse, they will each build a confident local theory from partial evidence before any of them sees the pattern. The skill’s warning is explicit: investigate together if fixing one might fix the rest. Related failures want one mind and one evidence trail.
Shared state. Two implementers editing the same tree is a guaranteed conflict, and the conflict is worst where review is concerned: each agent’s self-review sees a working tree another agent is mutating underneath it, so the thing being reviewed isn’t the thing either of them wrote. subagent-driven-development handles this structurally — its task loop is sequential, a fresh subagent per task, never alongside another — and reserves parallel dispatch for lanes like SYNAS’s: read-only, disjoint, mergeable by inspection. If the shared state is a git branch rather than a live system, isolation can be manufactured with git worktrees; if it’s a database, a config file, or a running server, serialize.
Exploratory debugging. Parallelism presumes you already know where the seams are. While you’re still discovering what’s broken, those seams are guesses, and every lane dispatched on a wrong seam manufactures confident findings about a boundary that doesn’t exist. This is the domain of systematic debugging — one tight loop of evidence, pattern, hypothesis, test. Decompose after diagnosis, not during it.
| Smell in the work | Verdict |
|---|---|
| Different subsystems, different commands, no shared files | Parallel — dispatch the batch |
| Read-only audits or research sweeps | Parallel — safe by construction |
| Fixing lane A might fix lane B | Sequential — one agent, whole picture |
| Lanes would edit the same files | Serialize, or split with worktrees |
| You can’t write the brief without pasting history | Not decomposed yet — brainstorm first |
| You’re still finding out what’s broken | Sequential debugging loop |
| Lane runs about as long as its briefing takes | Sequential — overhead eats the win |
How the Three Skills Interact
The theme is not three tools in a bag; it’s a pipeline with roles. executing-plans owns the checklist: it loads the plan, works it task by task, and at each checkpoint is also where the sequential-or-parallel call gets made. In the SYNAS run, the plan said “audit storage and network”; the controller ran the decision tree, got three green gates, and only then reached for concurrency.
dispatching-parallel-agents supplies the mechanics for a green-lit checkpoint. Every lane gets a prompt with the skill’s four properties — focused (one problem domain), self-contained (paste the errors, paths, and commands; the agent has no memory of your session), specific about output (name the report format), and constrained (say what not to touch). Least-privilege toolsets ride along. And the skill owns the part everyone forgets: the post-return loop. Read every summary, check that lanes didn’t step on each other, run the full verification across the merge, and spot-check claims — subagents make systematic errors at scale, one wrong assumption times N lanes.
subagent-driven-development is what keeps the whole theme honest. Its whole premise is isolation for focus — a fresh subagent per task — but its task loop is deliberately sequential with a two-stage review (spec compliance, then code quality) after every task, because implementation lanes share the one thing audits don’t: a tree they’re both writing. It also brings the ledger, a detail that matters doubly in parallel runs: when the controller’s context compacts mid-run, the ledger — not the chat — is what prevents re-dispatching lanes that already finished. The composition rule the three skills converge on: dispatch decides how a checkpoint runs; subagent-driven development decides what a checkpoint must produce before it counts; executing-plans provides the checklist they both hang on.
Common Mistakes at Dispatch Time
| Mistake | Fix |
|---|---|
| Goal spans two problem domains | Split the lane or drop the batch — one domain per agent |
| Brief assumes shared memory | Paste errors, paths, and commands; agents inherit nothing |
| No constraints | Say what NOT to change; silence reads as permission |
| “Report what you find” | Name the output contract: format, claims, evidence |
| Trust-the-summary integration | Re-verify headline claims with fresh commands before shipping |
| Unbounded concurrency appetite | Respect the batch ceiling: three lanes, depth two |
Related Deep Dives in the Series
- dispatching-parallel-agents — the full dispatch mechanics: batch mode, prompt anatomy, the post-return verification loop.
- subagent-driven-development — fresh agents per task with two-stage review, and the ban on parallel implementers.
- executing-plans — the sequential baseline: when the checklist alone is the right tool.
- using-git-worktrees — manufacturing isolation when the shared state is a repository.
Key Takeaways
- Parallel cost is dispatch + longest lane + integration; it beats sequential only when the lanes outgrow that overhead — the SYNAS storage and network lanes, ~3 minutes each on read-only disjoint work, cleared the bar.
- Run the three gates in order: genuinely independent domains, self-contained briefs, no shared mutable state. A brief you can’t write without session history means the decomposition is fake.
- Parallelism shines on multiple systems with their own scope and on read-only sweeps; it hurts on related failures, shared state, and exploratory debugging.
- Isolation buys more than wall clock: each lane held its full evidence trail in a dedicated context while the controller stayed lean for integration.
- The three skills compose: executing-plans makes the call, dispatching-parallel-agents runs the batch, subagent-driven-development polices what may never overlap — implementation lanes editing one tree.
Previous in the theme series: Planning → Execution. Next: Verification & Quality. Full mechanics in the dispatching-parallel-agents deep dive, or browse the Skills We Use series index.