Skip to content

02. Orchestrator-Worker — the default org chart

~10 min read. One boss delegates. Specialists execute. The simplest multi-agent pattern that actually works.

Built on the ELI5 in 00-eli5.md. The CEO — the orchestrator who assigns work and reads results back — is the central coordinator in this topology.

1) The picture

See. Picture before theory. This pattern is just the org chart drawn clearly. One central agent receives the job. That agent decides who should do each slice. Then specialists do narrow work. Then the boss reads return notes. Then the boss decides what goes out.

             ┌──────────────┐
             │  Orchestrator │
             │  (the CEO)    │
             └──┬─────┬──┬──┘
                │     │  │
         ┌──────┘     │  └──────┐
         ▼            ▼         ▼
   ┌──────────┐ ┌──────────┐ ┌──────────┐
   │ Research  │ │  Writer  │ │ Reviewer │
   │ (dept 1)  │ │ (dept 2) │ │ (dept 3) │
   └──────────┘ └──────────┘ └──────────┘

The CEO breaks work into parts. The CEO sends each part to the right department. Each department gets a smaller prompt and a clearer goal. Each one returns a structured handoff. The handoff is not chatter. It is a memo with findings, status, and next action. Then the CEO reads all memos together. The final answer stays in one place.

Look. This feels natural because companies already work like this. A manager assigns, checks, and combines. Simple, no?

The danger is visible in the same picture. If every question must go through one boss, that boss becomes the queue. So the same diagram shows the strength and the bottleneck.

2) How it works step by step

Use a concrete workflow. Suppose the task is a market brief. The user asks, "Write a brief on Indian UPI trends."

  1. The CEO receives the task: "Write a brief on Indian UPI trends."
  2. The boss decomposes it into research, draft, and review.
  3. The boss sends the research task to the Research agent.
  4. Research returns findings as a structured handoff.
  5. The boss sends the findings plus draft instructions to the Writer.
  6. Writer returns a draft.
  7. The boss sends the draft to the Reviewer.
  8. Reviewer returns a verdict.
  9. The boss assembles the final output.

Now slow it down once. At step 1, the orchestrator decides audience, format, deadline, and budget. This is where safety checks often sit too. At step 2, decomposition matters more than many teams expect. Good splits follow failure boundaries. Research should collect facts. Writing should shape narrative. Review should check claims and tone. If one worker tries to do two jobs, clarity starts leaking away.

At step 3, the research prompt stays narrow. It does not need writing style rules or publication format. It only needs the search objective, source criteria, time range, and output schema. That smaller context is a real advantage. At step 4, the research handoff should be crisp: summary bullets, source list, confidence notes, and open questions. That is enough for the next desk. The writer should not parse a messy essay.

At step 5, the boss passes only what matters. Findings go in. Audience and tone go in. Irrelevant logs stay out. So the writer gets signal, not noise. At step 6, the writer returns a draft, not a final business decision. Workers execute. The orchestrator owns completion. At step 7 and step 8, review becomes another specialist lane. The Reviewer checks unsupported claims, weak structure, and risky wording. At step 9, the orchestrator makes the release decision. It may accept, request one revision, or stop the workflow. Final synthesis belongs in one place. That is the whole pattern.

3) Strengths and weaknesses

First the strengths. This model is easy to reason about. You can draw the flow on a whiteboard quickly. You can log every hands_on_lab and every return memo. That makes audits much easier. In regulated environments, that matters a lot.

It is also a good place for budgets. The orchestrator can decide, "Research gets two web calls only," or, "Review runs only if confidence is below threshold." Cost control sits at the center. Safety checks can sit there too. One gate is easier than five hidden gates.

Control is the other big win. If output quality drops, you inspect the handoff and the routing logic. If latency spikes, you inspect which worker is slow. Because the org chart is explicit, debugging becomes less mysterious.

Now the weaknesses. The orchestrator can become the bottleneck. Every branch may wait for one decision-maker. If that agent is slow, the whole system feels slow. Sequential delegation creates sequential latency. Research waits. Then writing waits. Then review waits. Look. Control is buying order, but sometimes paying with time.

There is another trap. Teams keep adding logic to the center. Soon the orchestrator becomes one giant clever prompt. Then you have recreated one overloaded agent, just with extra plumbing around it. So what to do? Keep the boss thin. Let specialists stay specialists.

4) Worked example — cost comparison

Now do the math. Keep it simple. Assume a four-step workflow. We compare one giant agent versus orchestrator-worker.

Single agent path

Suppose one agent carries the whole briefing context each turn. Input prompt each step = 4000 tokens. Number of steps = 4. Total input tokens = 4000 × 4. Total input tokens = 16000.

Why so high? Because the same bulky context keeps getting repeated. Research rules repeat. Writing rules repeat. Review rules repeat. All baggage travels every time.

Orchestrator-worker path

Assume the orchestrator prompt is 500 tokens each time. Assume each worker prompt is 800 tokens. Use this flow: research worker, writer worker, reviewer worker, then one final orchestrator synthesis step. Orchestrator input total = 500 × 4 = 2000 tokens. Worker input total = 800 × 3 = 2400 tokens. Combined input total = 2000 + 2400 = 4400 tokens.

Now compare. Single agent input = 16000 tokens. Orchestrator-worker input = 4400 tokens. Savings = 16000 - 4400 = 11600 tokens. Savings rate = 11600 / 16000 = 72.5%.

Of course, real systems add output tokens and some overhead. But the core point stands. Smaller prompts stop unrelated instructions from repeating. Picture first, math second. See how specialization reduces baggage.

5) When to use and when not to

Use this pattern when central control really matters. One place can own policy, budget, and final release. Use it when specialists are mostly independent. Research can research. Writing can write. Review can review. Then one orchestrator can combine the pieces cleanly.

Do not force this pattern everywhere. If work flows in a strict assembly line, a pipeline is usually cleaner. If you need disagreement detection, a debate or critique pattern is better. If scale requires sub-managers, a hierarchy fits better.

So what is the practical rule? Start with orchestrator-worker. It is the easiest topology to debug. It is the easiest to explain to stakeholders. It is the easiest place to add logging and guardrails. Move away only when the orchestrator bottleneck becomes visible. That is the key insight. Start here. Graduate later.

Where this lives in the wild

  • Customer support platforms — a supervisor agent routes billing, refund, and technical issues to specialist agents, then sends one customer-safe reply.
  • GitHub Copilot Workspace — an orchestrator breaks coding work into search, edit, and test sub-agents, then combines results into a developer-facing outcome.
  • Content generation systems — a central coordinator assigns research, writing, fact-checking, and SEO scoring to focused workers before publishing.
  • Enterprise workflow automation — a control agent dispatches document classification, extraction, validation, and approval steps to specialized processors.
  • Data analysis pipelines — an orchestrator sends SQL, visualization, and narrative tasks to different workers, then merges them into one decision memo.

Pause and recall

  1. Why is the CEO useful even when workers are strong?
  2. What should a good handoff contain besides raw text?
  3. When does the orchestrator become a bottleneck?
  4. Why is this usually the first multi-agent pattern to try?

Interview Q&A

Q1. Why use orchestrator-worker instead of one giant agent for a regulated workflow? A. Because central routing gives clearer audit logs, policy gates, and budget control. Common wrong answer to avoid: "Because more agents are always smarter."

Q2. Why use orchestrator-worker instead of a pipeline for market-brief generation? A. Use it when one boss must choose branches, retries, and final synthesis centrally. Common wrong answer to avoid: "They are basically the same thing with different names."

Q3. Why keep review as a worker instead of folding review into the writer prompt? A. Separate review preserves an independent quality check and clearer failure signals. Common wrong answer to avoid: "If the writer is good enough, review is wasted latency."

Q4. Why not keep adding logic to the orchestrator until it handles everything? A. Because then the orchestrator turns back into one overloaded agent with extra coordination cost. Common wrong answer to avoid: "Centralizing more logic always improves consistency."

Apply now (5 min)

Exercise. Take one task you do often. Maybe weekly reporting. Maybe bug triage. Maybe proposal writing. Split it into boss work and specialist work. Name the workers. Define one input and one output for each department.

Sketch from memory. Draw the org chart on paper. Put the CEO on top. Add three workers below. Then write one sample handoff for the research lane. Keep it under six bullets.

Bridge. The CEO delegates well. But sometimes work has a strict order — research THEN write THEN review THEN publish. No branching. No parallelism. Just a clean sequence. That pattern deserves its own name: the pipeline. → 03-pipeline-topology.md