A free playbook, as a PDF and an EPUB
The multi agent orchestration playbook
Split one coding agent into a planner, an engineer and a reviewer, with scoped tools, a hand-off contract and caps, then trace the team against the agent it replaced.
The playbook is open in a new tab
If it did not open, open the PDF. For a reading app, download the EPUB. Both links work for a day; the form gives you new ones any time.
Build it live, with an engineer reviewing your choices
Build a Multi-Agent System with MCP. A planner, an engineer and a reviewer that take one issue from plan to pull request, each with only the tools its role needs.
Look insidePages from the PDF, as they print.
Page 2: Contents 
Page 3: Acme's issue-to-PR agent becomes a team one step at a time. 
Page 16: The research win came with breadth and far more tokens, and most issues lack the breadth. 
Page 25: Write it down: .claude/agents/planner.md. 
Page 31: An agent with private data, untrusted input and a way out can be turned against you. 
Page 38: Agents pass paths to written work, not summaries of it. 
Page 53: Keep this page beside the agent files.
What the playbook covers
- 1
From one coding agent to a team that ships
Acme Inc is a made up company. Its coding agent takes a GitHub issue and opens a pull request with one agent and every tool. This playbook runs one issue through it, the invoices page needing a CSV export, then splits the agent into a team one step at a time.
- 2
Why a team of agents fails more often than one agent
Acme's issue is at step 0 on the map: nothing is split yet, and this is the case against. Multi agent systems fail often, cost far more tokens, and break at the hand-off between agents, not inside one.
- 3
Measure the single agent on one real issue
Acme's issue is at step 1. Run it once through the single agent with telemetry on, and write down its quality, time, tokens and trace. Every later chapter is judged against this page.
- 4
Run the test for whether a second agent pays
Acme's issue is at step 2. The same split can help one task and wreck another, so answer the test on the baseline issue before you split anything.
- 5
Pick the pattern: orchestrator-worker, pipeline, maker-checker or swarm
Acme's issue is at step 3. Every framework ships the same few patterns under different names. Pick one for the CSV export issue, and write down why the others lost.
- 6
Split it into planner, engineer and reviewer
Acme's issue is at step 4. Each role becomes a subagent file with one job. A subagent knows only its file and the prompt the lead sends it, so the file and the prompt carry everything.
- 7
Scope each role's tools
Acme's issue is at step 5. The single agent held the secrets, read text anyone can file as an issue, and could push. Split by role, each role holds less of that, the lead holds only the Agent tool, and the harness, not the prompt, enforces the limits.
- 8
Write the hand-off contract and the caps
Acme's issue is at step 6. Repeated work and agents that drift from the task are among the commonest failures in a team, so the hand-off is written down, and every role has a turn cap, the run a budget, and the tree a depth.
- 9
Rerun the issue and debug the team against the baseline
Acme's issue is at step 7. The same CSV export issue runs again, now through the team. A team hides its cost and its mistakes inside the lead, so read the trace, not the final message.
- 10
Hand it over with the pre-ship checklist and an owner
Acme's issue is at step 8. The team runs on every issue only when someone owns each file and a checklist gates the first unattended run.
- 11
The page to keep
Every file, rule and cap from the playbook on one page.