Orchestrator-worker

Orchestrator-worker is the workhorse multi-agent pattern. One agent (orchestrator) receives the task, breaks it down, and delegates subtasks to specialized workers. Workers return results; orchestrator synthesizes the final answer.

The shape

User -> Orchestrator
         |
         +-> Worker A (research)
         +-> Worker B (code)
         +-> Worker C (writing)
         |
         Synthesis -> User

Why split work

• Specialization: each worker has focused system prompt + tools for its domain
• Parallelism: independent subtasks run concurrently
• Cost control: cheap workers for bulk tasks, expensive model for orchestration
• Modularity: easier to test and improve one worker at a time

When it's overkill

Single-agent ReAct handles most tasks fine. Split when:

• The task genuinely has distinct, parallelizable subtasks
• Workers can use different models or different tool sets
• The synthesis work (combining results) is non-trivial

Worker design

Each worker is itself a small agent:

• Has its own system prompt tuned to its specialty
• Has access to a subset of tools relevant to its domain
• Has its own loop with its own budget
• Returns a structured result to the orchestrator

Handoff as a tool call

In practice: the orchestrator treats workers as tools. "Call research_worker with topic X." Clean interface.

Common failure modes

• Orchestrator over-delegates: spawns too many workers for small tasks
• Worker outputs don't combine: inconsistent schemas require orchestrator to do messy reconciliation
• No budget at worker level: each worker runs away independently
• Synthesis loss: important details from workers get dropped in final answer

Design checklist

• Clear schema for worker inputs and outputs
• Budget per worker
• Orchestrator's job is coordination, not re-doing worker work
• Synthesis step is carefully prompted to preserve key details