Orchestrator-Subagent

// 60-second mental model

How to hold it in your head

A planner owns the goal and never does the specialist work. It dispatches specialists, then merges their results.

An orchestrator agent decomposes the goal, delegates via tool-shaped contracts to subagents, and fans results back into a final synthesis.

// Mini architecture

Orchestrator dispatches; specialists work; results fan in

              ┌─────────────────┐
              │  Orchestrator   │
              │  (goal + plan)  │
              └────────┬────────┘
         ┌─────────────┼─────────────┐
         ▼             ▼             ▼
   ┌──────────┐  ┌──────────┐  ┌──────────┐
   │ Research │  │  Draft   │  │ Critique │
   │ subagent │  │ subagent │  │ subagent │
   └────┬─────┘  └────┬─────┘  └────┬─────┘
        └─────────────┼─────────────┘
                      ▼
              ┌─────────────────┐
              │ Merged output   │
              └─────────────────┘

Orchestrator may only call delegate_* tools — it is not allowed to draft the essay itself.

// Mini-project

Brand-style research → draft → critique

Orchestrator + three stub subagents

Goal: Produce a short brief by dispatching research, draft and critique stubs — orchestrator only merges.

1. Orchestrator receives: “Brief me on X for a LinkedIn post.”
2. It must call `delegate_research`, then `delegate_draft`, then `delegate_critique` (stubs return fixed strings).
3. Refuse any path where the orchestrator writes the draft in its own voice.
4. Merge critique notes into a final brief.
5. Log which specialist ran at each step (for the lesson demo).

Stubs are fine. The contract is the lesson: tool-only delegation, no “I’ll just do it myself”.

// Common failure

What goes wrong

// Self-reflection

Sit with this

Would your current multi-step agent be clearer as orchestrator + specialists?