The first article argued that sub-agents are the right primitive — specialised workers with minimal context that keep cheap models in the smart zone. This article is about the pattern that uses them well: the orchestrator pattern. The orchestrator is the single agent that knows you, plans the work, spawns the workers, and synthesises the result. The workers are disposable. The pattern is what turns "I asked for sub-agents" into "I shipped a working multi-agent workflow."

Two videos anchor the pattern: the channel's blueprint for production research workflows (BOn0wpDCwrw) and the sub-agent architecture from §7.1 (K-afyUDWEtY). The blueprint is the one to copy; the architecture is the one to understand.

What you'll learn

  • The orchestrator pattern has five steps — plan, spawn, collect, synthesise, identify gaps — and each step is the orchestrator's job, not the workers' (14-subagent-blueprint.md, "Architecture").
  • The structured-output contract is what makes synthesis tractable. Five sections — Key Findings, Notable Opinions, Source Links, Patterns Observed, Gaps Identified — are the minimum useful schema. A sub-agent that returns prose is a sub-agent that has not done its job.
  • Parallel execution is the default goal, not the exception. 4 workers on 4 sources run simultaneously, completing in ~25% of the serial time. Sequential sub-agents "are not different people" — they are one agent with extra latency.
  • The orchestrator + adversarial verifier pattern from Course 3 §3.1 is the audit handle: a separate agent reviews outputs without shared conversation history, so the audit is from first principles.
  • A mixed-model strategy (Opus orchestrator + Sonnet/Minimax workers) is the cost lever. The orchestrator pays for the quality of planning; the workers pay for the throughput of execution.
  • The blueprint's automation layer — 6-hour cron, structured output, gap analysis — is the same pattern the Kanban in §7.3 implements as a UI. The Kanban adds worker logs and a retry loop on top of the blueprint.

The orchestrator pattern, step by step

The blueprint's parallel_research skill defines the orchestrator's job in five steps (14-subagent-blueprint.md, "Orchestration Strategy"):

  1. Plan the research operation — what sources to hit, what questions to ask, what the synthesis criteria are
  2. Spawn parallel sub-agents — one per source, each with a task brief and a structured-output schema
  3. Collect structured outputs — parse the five-section schema from each worker
  4. Synthesise findings — cross-source pattern recognition, contradiction detection, gap analysis
  5. Identify gaps and opportunities — the workers cannot do this; only the orchestrator sees the whole board

The five steps are not optional. The blueprint's experience is that skipping any one of them produces slop (14-subagent-blueprint.md, "Best Practices"):

  • Skip planning → workers run with inconsistent or redundant briefs
  • Skip spawning in parallel → the workers serialise and the time win is gone
  • Skip structured output → the orchestrator cannot parse the results and re-does the synthesis
  • Skip synthesis → the worker outputs are delivered raw, with no coherent narrative
  • Skip gap analysis → the unique value of multi-source research is lost

The orchestrator's only job is the coordination — the planning, spawning, synthesis, and gap analysis. The worker's only job is the work — the source-specific data gathering. The split is the entire point of the pattern.

The architecture: the four-source research blueprint

The blueprint's architecture is a 4-worker orchestrator-and-workers stack (14-subagent-blueprint.md, "Architecture"):

┌─────────────────────────────────────┐
│   Main Agent (Orchestrator)         │
│   - Plans research strategy          │
│   - Spawns parallel sub-agents      │
│   - Synthesises findings            │
│   - Identifies gaps and patterns    │
└──────────────┬──────────────────────┘
               │
       ┌───────┴───────┬───────────┬──────────┐
       │               │           │          │
┌──────▼──────┐ ┌─────▼──────┐ ┌──▼─────┐ ┌──▼─────┐
│ Sub-Agent 1 │ │ Sub-Agent 2│ │ Sub-A 3│ │ Sub-A 4│
│ Twitter/X   │ │ News Sites │ │ Reddit │ │ HN     │
│ Search      │ │ Scraping   │ │ Trends │ │ Posts  │
└──────────────┘ └────────────┘ └────────┘ └────────┘
       │               │           │          │
       └───────┬───────┴───────────┴──────────┘
               │
       ┌───────▼────────────────────────────┐
       │   Structured Output Collection     │
       │   - Key findings                   │
       │   - Notable opinions               │
│   - Source links                   │
│   - Patterns                       │
│   - Gaps                           │
       └────────────────────────────────────┘

Three structural points (14-subagent-blueprint.md, "Why This Works"):

  • Parallel execution — 4 sources searched simultaneously, 4x faster than sequential, more comprehensive coverage. The "4x" is the lower bound — in practice, the orchestrator is I/O-bound on the slowest worker, so the speedup is closer to 3-3.5x for a 4-worker pipeline, but the win is still real.
  • Structured output — consistent format from each sub-agent, easy to synthesise, actionable insights. The format is the contract; the orchestrator does not have to read the worker's prose, only its schema.
  • Gap analysis — identifies underreported angles, finds emerging trends early, creates unique value. Gap analysis is the orchestrator's value-add; the workers cannot see the cross-source pattern by definition.

The structured-output contract

The contract is the load-bearing piece. Each sub-agent must return (14-subagent-blueprint.md, "Step 1: Define Structured Output Format"):