Agent Skills: Dispatching Parallel Agents

Fans out work across multiple agents — same prompt to many for Best-of-N, different prompts for parallel exploration, or a scout before committing. Use when user says "parallel agents", "fan out", "best of N", "scout", "race", "vote", "spawn workers".

UncategorizedID: wayne930242/Reflexive-Claude-Code/dispatching-parallel-agents

Install this agent skill to your local

pnpm dlx add-skill https://github.com/wayne930242/Reflexive-Claude-Code/tree/HEAD/plugins/rcc/skills/dispatching-parallel-agents

Skill Files

Browse the full folder contents for dispatching-parallel-agents.

Download Skill

Loading file tree…

plugins/rcc/skills/dispatching-parallel-agents/SKILL.md

Skill Metadata

Name
dispatching-parallel-agents
Description
Fans out work across multiple agents — same prompt to many for Best-of-N, different prompts for parallel exploration, or a scout before committing. Use when user says "parallel agents", "fan out", "best of N", "scout", "race", "vote", "spawn workers".

Dispatching Parallel Agents

Overview

Dispatching parallel agents IS trading compute for confidence or throughput.

A single Agent call is one bet. N Agent calls in one message is N bets — they execute concurrently and you pick or merge. The runtime fans out automatically when multiple Agent tool uses appear in a single response; serializing by mistake (one Agent call per response) wastes the entire benefit.

Core principle: Parallelism is a property of the dispatch (one message, N tool uses), not of the agents themselves.

Task Initialization (MANDATORY)

Follow task initialization protocol.

Tasks: 0. Classify the dispatch pattern

  1. Choose agents and inputs
  2. Fan out in a single message
  3. Merge results
  4. Report to user

Announce: "Created 5 tasks (0–4). Starting execution..."

Task 0: Classify the Dispatch Pattern

Goal: Pick exactly one pattern. Mixing patterns = confused merge step.

| Pattern | When | Inputs | Merge strategy | |---------|------|--------|----------------| | P-Thread (parallel, divergent) | Independent subtasks, each agent owns a slice | N different prompts | Concatenate — each result stands alone | | F-Thread (Best-of-N, fusion) | One hard question, want confidence or cherry-pick | N identical prompts | Vote / diff / cherry-pick | | Scout (throw-away recon) | Unfamiliar territory, want to learn before committing | One scout prompt, discard the code | Read scout's findings → write better main prompt | | B-Thread (nested orchestrator) | One sub-agent dispatches further sub-agents | Single Agent call to an orchestrator agent | Orchestrator handles its own merge |

Anti-patterns:

  • "I'll fan out 5 agents to write the same file" — they collide. Fanout is for read-only or sliced-write tasks.
  • "I'll fan out then iterate on each" — that's serial, not parallel. Decide the dispatch shape upfront.
  • "Best-of-N for a deterministic question" — if the answer is git log, one agent suffices. F-Thread costs N× tokens; pay only when judgment varies.

Verification: Can name the pattern in one word and justify it in one sentence.

Task 1: Choose Agents and Inputs

Goal: Pick the agent type per call and the prompts.

Agent selection:

| Need | Use | |------|-----| | Read-only research | Explore (Haiku, fast, no Write/Edit) | | Planning | Plan | | Code review (F-Thread voting) | Project reviewer agents (e.g. rcc:skill-reviewer) | | General multi-step | general-purpose |

Prompt design for fanout:

  • Each prompt is self-contained — agents do not see this conversation, do not see each other's output.
  • For F-Thread: identical prompts, identical context. The only variable is the agent's stochastic output.
  • For P-Thread: explicit slice in each prompt — "you handle X, ignore Y."
  • For Scout: tell the scout it's a scout — "your output will be discarded; report what you learned, what files you touched, where you got stuck."

Tool set: Pass minimal tools. Fanout amplifies any tool the agent has — five Edits in parallel = five chances to corrupt the same file.

Verification: Each prompt readable cold, no implicit context, tool set scoped.

Task 2: Fan Out in a Single Message

Goal: Issue all N Agent calls in one assistant turn.

Why this matters: the runtime parallelizes tool uses within a single message. Splitting across turns serializes them and you pay round-trip latency × N.

Correct shape:

[one assistant message]
  Agent(prompt=A, ...)
  Agent(prompt=B, ...)
  Agent(prompt=C, ...)

Wrong shape (serial):

[message 1] Agent(A) → wait → [message 2] Agent(B) → wait → ...

Background flag: for long-running fans (>2 min each), set run_in_background: true so the main turn doesn't block. The runtime notifies on completion.

Verification: All Agent calls visible in a single assistant message.

Task 3: Merge Results

Goal: Collapse N outputs into one decision or report.

Merge strategies by pattern:

| Pattern | Strategy | |---------|----------| | P-Thread | Concatenate sections. Each agent owned a slice; the slices compose. | | F-Thread (vote) | Count agreement. ≥ ⌈N/2⌉+1 agree → that answer wins. Disagreement → escalate to user. | | F-Thread (diff) | Show user the N outputs side-by-side. User picks or cherry-picks. | | F-Thread (cherry-pick) | Take the strongest part of each — only when outputs are structured (e.g. YAML lists you can union). | | Scout | Discard scout's code. Extract the lessons (files touched, blockers found) into the next prompt. |

Reviewer F-Thread special case:

When voting reviewer agents (e.g. 3× rcc:skill-reviewer), if YAML outputs disagree on pass, the safe default is fail — any reviewer flagging an issue counts.

Verification: A single artifact (decision, file, report) emerges from N inputs.

Task 4: Report to User

Goal: Make the parallel dispatch legible.

Report shape:

  • State the pattern: "Ran F-Thread, 3 reviewers."
  • Show the merge: "All 3 passed" or "2 pass / 1 fail — flagging the failing concern."
  • Surface dissent — never silently drop the minority output.

Verification: User can audit which agent said what without re-running.

Red Flags - STOP

These thoughts mean you're rationalizing. STOP and reconsider:

  • "I'll just run them one at a time, it's the same thing"
  • "Fanout is overkill for this"
  • "Best-of-N for everything makes results better"
  • "I'll fan out 5 agents to edit the same file"
  • "Scout is wasteful, just write the real prompt"
  • "Hide the dissenting reviewer, the others passed"

All of these mean: You're about to lose the value of parallel dispatch. Follow the process.

Common Rationalizations

| Excuse | Reality | |--------|---------| | "Serial is simpler" | Serial costs N× wall-clock. The whole point is the wall-clock saving. | | "More agents = better answer" | F-Thread costs N× tokens. Use it for judgment-heavy questions, not lookups. | | "Scout is throwaway, skip it" | The scout's blockers are intel. Skipping = re-discovering them yourself. | | "Fanout writes are fine" | Two agents writing the same file race. Fanout writes only on disjoint slices. | | "Pick the best output silently" | The user can't audit a hidden decision. Surface dissent. |

References

  • writing-subagents — design agents that survive fanout
  • User-level investigating skill — scout pattern detail (lives outside this plugin)