ASK KNOX
beta
LESSON 421

The Parallel Dispatch Playbook

End-to-end: scope → isolate → dispatch → verify → converge — the repeatable protocol for any parallel agent session.

10 min read·Parallel Agent Dispatch & Worktrees

The Playbook

Everything in this track has been building to a single, repeatable five-phase protocol. You know the theory: why parallelism matters, how roles work, what scoped dispatch looks like, how worktrees prevent collisions, how fan-out patterns differ, how convergence works, and how verification layers catch errors. Now you run it.

The playbook is not aspirational — it is the exact sequence Knox uses for every parallel dispatch session in production. It has been validated across dozens of track-building sessions, cross-repo CI fixes, and multi-agent /ship runs. It works because it is systematic, not because it is creative.

Phase A: Scope

Before any worktrees are created, before any agents are dispatched, write every dispatch prompt.

  1. List every task in concrete terms. Not "write the lessons" — "write lesson-413.mdx through lesson-421.mdx with frontmatter matching the spec and 2+ bespoke diagrams per lesson."
  2. Classify each task: cross-repo (free parallelism), same-repo (worktree), or dependent (pipeline).
  3. Identify all shared files. Run: grep -r 'EXPECTED_' __tests__/ && cat components/mdx/index.ts | tail -5 && grep -n 'TRACKS\|TIERS' lib/
  4. Write every dispatch prompt using the five-field contract: scope, definition of done, files in scope, files off limits, verification command.
  5. Announce: "All N agents use isolation: worktree — verified." This is the structural rule from CLAUDE.md.

Phase B: Isolate

git checkout main && git pull  # always start clean

# Create one worktree per same-repo agent
git worktree add .claude/worktrees/agent-a -b feat/agent-a
git worktree add .claude/worktrees/agent-b -b feat/agent-b

# Verify
git worktree list
# main              [abc1234] main
# .claude/worktrees/agent-a  [abc1234] feat/agent-a
# .claude/worktrees/agent-b  [abc1234] feat/agent-b

# Install dependencies in each worktree — a fresh worktree has NO
# node_modules, so npm run test / npx tsc fail until this runs
(cd .claude/worktrees/agent-a && npm ci)
(cd .claude/worktrees/agent-b && npm ci)

Cross-repo agents need no setup. Dispatch them directly.

Phase C: Dispatch

Dispatch all agents in the current wave simultaneously. Do not wait for one to finish before starting the next — that is serial execution with extra steps.

Include in every prompt: the five-field contract, the exact worktree path for the agent to work in, and the critical boundary: "Do not report status without running the verification command and pasting its output."

The orchestrator's only job while workers execute: write dispatch prompts for the next wave, review outputs from the previous wave, and stay out of the code.

Phase D: Verify

For each worker that reports done:

  1. Is it a PASS with evidence (literal command output)? Or an opinion ("should work")?
  2. Does the git diff show only in-scope files? git diff feat/agent-a --name-only
  3. No off-limits files (index.ts, tracks.ts, tiers.ts, test count files) in the diff?

Any failure: diagnose in the worker's worktree. Fix. Re-verify. Only then is the worker done.

Cross-worker: do any two workers' diffs overlap? If so, resolve the overlap before cherry-picking — clarify which worker owns the file, have the other re-scope its changes.

Phase E: Converge

# In main working tree — range form picks ALL of each worker's commits
# (a bare `git cherry-pick feat/agent-a` would apply only the tip commit)
git cherry-pick main..feat/agent-a  # in dependency order
git cherry-pick main..feat/agent-b

# Orchestrator's single atomic registry pass
# Edit: index.ts (all new exports), tracks.ts (new track), tiers.ts (slug), test counts
git add components/mdx/index.ts lib/tracks.ts lib/tiers.ts __tests__/content-integrity.test.ts
git commit -m "feat: register parallel-agent-dispatch track (9 lessons, 18 diagrams)"

# Full verification
npm run test        # must all pass
npx tsc --noEmit    # must be 0 errors

# Cleanup (mandatory)
git worktree remove .claude/worktrees/agent-a
git worktree remove .claude/worktrees/agent-b
# -D, not -d: cherry-pick created new SHAs on main, so the branch tips
# are not ancestors of main — -d refuses ("not fully merged")
git branch -D feat/agent-a feat/agent-b
git worktree list   # must show only main

# Code review before PR
# Run /code-review-swarm on the accumulated diff
# Resolve all P0/P1 findings

# Open PR — never commit to main directly
gh pr create --title "feat: parallel-agent-dispatch track" --body "..."

The Audit Lab

Run the audit checklist after every parallel dispatch session. The 20-check checklist is the evidence that the playbook was followed. Before opening a PR, every GATE item must be checked.

The checklist is not optional because memory is unreliable. Six hours into a complex dispatch session, it is easy to forget whether worktrees were removed or whether the test suite ran from the main directory. The checklist makes this mechanical.

What Comes Next

This track taught the mechanics. The compound learning happens when you apply the playbook to real sessions and update lessons.md with the specific failure modes you encounter.

The patterns that broke in your sessions are more valuable than any abstract rule. When you discover that a particular combination of tasks in your specific codebase collides in a way the playbook didn't predict — that is the lesson. Write it down. Escalate it to CLAUDE.md.

For Tesseract Intelligence: the parallel dispatch pattern powers the competitive intelligence track — multiple research agents running simultaneously, results converged into a synthesis, the spec-driven-development track covers the downstream implementation. For jeremyknox.ai: the blog autopilot uses a fan-out pattern for content generation across multiple sources.

The fleet mindset is not just about efficiency. It is about scale. The practitioner who can orchestrate five agents simultaneously is not five times faster than the one who runs them serially. The orchestrator is ten times faster — because the overhead of orchestration is constant, not proportional to the number of agents.