See the whole orchestrator before you build it.

Every orchestration guide stops before the file tree.

• →Most agent orchestration content is architecture theory. Nobody shows what it looks like on disk, which is the only part you have to build.
• →You run Claude Code alone and it works. The moment you need three subagents coordinating, there is no obvious next step.
• →Nobody tells you what hardware this needs. You find out by watching your machine struggle at agent seven.
• →More agents means more ways to do something expensive without anyone approving it first.

Architecture, hardware, build order, guardrails.

• 01
  The architecture

  Orchestrator, subagents, MCP layer, file tree and watchdogs, with the real directory structure rather than boxes and arrows.
• 02
  Hardware sizing

  M2, M3 and M4 Max measured against 5, 10 and 20 parallel agents, with the number where each stops being comfortable.
• 03
  Build order

  Bare metal to a first working swarm, layer by layer, so that each stage is verifiable before the next one goes on top.
• 04
  Approval flows

  The guardrails that keep a multi-agent stack safe, including which actions always stop for a human regardless of which agent asked.
• 05
  The watchdog

  What restarts a stuck agent, what escalates, and what should simply stop and wait for you.

You, if three coordinated agents is where you stalled.

If a single agent is comfortable and coordinating several is not, this is the missing layer. Read the architecture first, then build it in the given order over a weekend.

Why now Open-source orchestration only recently became worth adopting over rolling your own. The watchdog and approval patterns are the parts that took longest to get right, and they are the parts you would have had to learn by breaking things.

The payoff is that scale stops being frightening. Adding the thirteenth agent is a file, not an architecture decision, because the decisions were all made at layer one.