Orchestrator-Worker Topology

In the orchestrator-worker pattern, a lead (orchestrator) agent breaks a goal into subtasks and spawns worker subagents to handle each, often in parallel. The orchestrator doesn't do the detailed work; it plans, delegates, and then synthesizes the workers' outputs into a coherent result.

The critical architectural fact: subagents don't inherit the coordinator's context. Each worker starts fresh, so the orchestrator must pass everything a worker needs explicitly in its instructions, and workers return only their findings — not their full working context. This isolation is a feature (clean context windows, parallelism) but a design burden (you must be deliberate about what crosses the boundary).

Use it when subtasks are separable and benefit from independent context — for example, researching several sub-questions at once. It adds token cost (many agents) and coordination complexity, so it's overkill for linear tasks a single agent handles well.