The Superpowers Parallel Agents Skill: Dispatching Parallel Agents in Depth

Most agent work is a single file: one context window, one task queue, one thing happening at a time. The superpowers-dispatching-parallel-agents skill breaks that line into lanes. When you have two or more genuinely independent problems, it dispatches focused subagents that work them concurrently — and a two-hour audit collapses into twenty minutes. This deep-dive covers how the superpowers parallel agents skill decides when to fan out, how to write prompts that make a subagent useful, and where parallelism quietly stops paying.

What the skill actually does

The skill formalizes a delegation pattern built on a primitive called delegate_task. The orchestrating agent — the one holding your conversation — identifies independent problem domains, writes a self-contained brief for each one, and dispatches them as subagents that run concurrently (in Hermes, up to three at a time). Each subagent starts with a blank context: it never inherits your session history. The orchestrator constructs exactly what the subagent needs — goal, error messages, file paths, constraints, verification command — and gets back a structured result: status, summary, duration, token usage, and a tool trace.

That isolation is the point, not a limitation. Because subagents don't share context, they can't corrupt each other's assumptions, and — critically — they don't consume the orchestrator's context window. A ten-thousand-line log analysis that would blow out your main session's memory runs off to the side, and the orchestrator only ever sees the returned summary. The core principle the skill states in one line: one agent per independent problem domain, working concurrently.

The word doing all the structural work here is independent. Everything downstream — the decision tree, the prompt rules, the failure modes — is a consequence of that one requirement.

The decision tree: when to fan out, when to queue

The skill opens with a gate, not a cheerleading session. Parallel dispatch is the right tool only when a short checklist passes:

The most skipped branch is the first one. Three failing test suites in authentication, rate limiting, and CSV export are three domains: go wide. Three failing tests that all touch the session store are one domain wearing a disguise: one agent, one root cause. The skill's blunt guidance — if fixing one might fix the others, investigate together — is the difference between parallel work and parallel waste.

The shared-state branch has teeth beyond file edits. Two agents running docker system prune "just to check" on the same host will fight over the Docker daemon; two agents restarting the same service will mask each other's results. Independence means the blast radius is disjoint, not just the target files.

A real example: the SYNAS storage + network audit

Here is the pattern on a real system. The SYNAS file server — OpenMediaVault on Debian, 32 Docker containers spread across 26 networks — needed a health audit. The work decomposed naturally into three lanes, two of which were textbook-parallel:

• Storage audit: container/image/volume footprint, reclaimable space, disk pressure, swap usage.
• Network topology audit: all 26 Docker networks, which containers attach to each, isolation quality, orphaned networks.
• Container health status (kept in the orchestrator — it was a few commands and needed to stay in the conversation for interpretation).

Storage and networking shared nothing: different commands, different data, different conclusions, zero file overlap. The orchestrator dispatched both as one batched call:

delegate_task(tasks=[
  {
    "goal": "Audit Docker storage on SYNAS: image/container/volume/build-cache "
            "footprint, reclaimable space, disk and swap pressure. Return a table "
            "of consumers and a list of safe cleanups.",
    "context": "Host: syphen@10.10.10.12 (SSH key auth). Commands: docker system "
               "df -v, docker ps -a, df -h, free -h. Do NOT run any prune command.",
    "toolsets": ["terminal"]
  },
  {
    "goal": "Map Docker network topology on SYNAS: every network, every container "
            "attachment, orphaned networks, isolation assessment.",
    "context": "Host: syphen@10.10.10.12 (SSH key auth). Commands: docker network "
               "ls, docker network inspect, docker inspect each container. Read-only.",
    "toolsets": ["terminal"]
  }
])

Both subagents came back in roughly three minutes. Because they ran concurrently, wall-clock time was about three minutes — not the six-plus minutes of doing them back to back. The combined findings folded straight into the final status report: the storage agent surfaced roughly 1.9 GB of dangling images, 532 MB of dead build cache, and a container writing 1.87 GB into its own writable layer instead of a volume; the network agent confirmed every service properly isolated on its own bridge, flagged four orphaned networks safe to prune, and raised the one genuinely interesting question in the whole audit — why vaultwarden sits on two networks. Each flag was a one-paragraph summary in the orchestrator's context, not raw command output.

Two constraints in those briefs deserve notice, because they're easy to forget: read-only, do not prune. A subagent acting on its own judgment can have side effects across a production host. Constraints are the seatbelt on a very fast car.

The anatomy of a subagent brief

A subagent is a brilliant contractor who has never met you, cannot ask follow-up questions, and bills by the token. The skill specifies four properties of a brief that works:

1. Focused — one clear problem domain. If the goal needs an "and" between two unrelated verbs, split it.
2. Self-contained — the error text, the file paths, the commands to run. The subagent has zero session history; paste what you know.
3. Specific about output — say what "done" looks like: "Return a summary of root cause and changes made." Otherwise you get an essay.
4. Constrained — what not to touch: don't change test expectations, don't alter the public API, don't prune anything.

delegate_task(
    goal="Fix the 3 failing tests in tests/test_auth.py",
    context="""
    Failing tests:
    1. test_token_expiry — expects 401, gets 200
    2. test_refresh_flow — refresh token not invalidated
    3. test_concurrent_sessions — race on session store

    Root cause likely in src/auth/session.py or src/auth/tokens.py.

    Constraints:
    - Do NOT modify test expectations unless the tests are wrong
    - Do NOT change the public API
    - Verify with: pytest tests/test_auth.py -v

    Return: summary of root cause and changes made.
    """,
    toolsets=["terminal", "file"]
)

Notice the toolsets list: ["terminal", "file"], not "everything." A storage auditor with a browser open is one accidental detour away from a wasted run. Least privilege applies to your own subagents too.

Common mistakes, and the one-line fix for each

After the agents return

Dispatching is the easy half. The skill closes with a four-step integration loop: read every summary before touching anything; check for conflicts — did two agents quietly edit the same file?; run the full verification suite, not just each agent's local test; and spot-check, because subagents make systematic errors — a misread brief fails consistently, at scale, with confidence. This is where the skill leans on the verification-before-completion discipline: "both agents said success" is a claim, not evidence. In the SYNAS audit, integration was light by design — the briefs were read-only, so the orchestrator's job was confirming the two findings lists didn't contradict each other before writing the report.

Related Deep Dives in the Series

The superpowers parallel agents skill is an execution-phase tool, and it has a lighter sibling and a heavier one. When you have a written plan whose tasks are sequential and small, superpowers-executing-plans just runs the plan, checkbox by checkbox, in the main session — no delegation overhead. When the work is one long chain of implementation tasks that each need review, subagent-driven-development runs one subagent per task with a two-stage review after each. Dispatching-parallel-agents occupies the middle lane: multiple simultaneous investigations or fixes that don't need a reviewer between them, only integration at the end. They compose, too — a plan can execute sequentially at the top level while a single plan step fans out into parallel audits, exactly as the SYNAS status report did.

• Superpowers Verification Before Completion — evidence before claims — prove it works before calling it done.

Frequently asked questions

Can a subagent spawn its own subagents?

No — delegation depth is capped at two. Subagents cannot call delegate_task, ask clarifying questions, or write to long-term memory. Fan-out is a star topology with exactly one hub: you.

How many parallel agents is too many?

In Hermes the batch mode runs a maximum of three concurrent children, and the skill argues you rarely want more even if you could. Every additional agent is another brief to write and another result to integrate; three well-briefed agents beat eight thin ones.

Do subagents see the conversation I've had so far?

Never — and that's the design. Isolation keeps your context window for coordination and forces every brief to be explicit. If the subagent needed to know it, it has to be in the brief.

Key terms

delegate_task

The primitive the skill drives: dispatch a goal-plus-brief to an isolated subagent, optionally as a concurrent batch.

Orchestrator

The main agent that decomposes work, writes briefs, dispatches, and integrates. Its context is the scarce resource the pattern protects.

Subagent

A spawned worker with fresh context and a scoped toolset. Returns status, summary, duration, token usage, and a tool trace.

Shared state

Overlapping files, services, or daemons that make concurrency dangerous. Its absence is the precondition for dispatching.

Integration pass

The orchestrator's post-return work: read summaries, check conflicts, run full verification, spot-check for systematic errors.

Coordination tax

The overhead of writing briefs, duplicating context, and integrating results — the cost that makes small tasks unparallelizable.

Parallelism is not speed; it's a trade — wall clock and context window against tokens, brief-writing time, and integration risk. The superpowers-dispatching-parallel-agents skill is the discipline of making that trade deliberately: check independence first, brief like the agent can't ask, constrain like it won't stop, and verify like it's wrong. Do that, and two three-minute audits arrive in three minutes.