# Orchestrator-Worker Topology

A coordinator agent decomposes a task, delegates subtasks to worker subagents, and synthesizes their results into a final answer.

## Why the CCAR-P exam tests this

CCAR-P tests understanding context boundaries between coordinator and workers and how results flow back for synthesis.

## Definition

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.

## Exam trap

Assuming subagents can 'see' what the coordinator already knows — they don't inherit its context, so anything not passed explicitly is invisible to the worker.

## Commonly confused with

- **single-vs-multi-agent** — Orchestrator-worker is one specific multi-agent topology; single-vs-multi is the prior decision of whether to have multiple agents at all.

## Related

- single-vs-multi-agent
- workflow-vs-agent
- agentic-loop
- batch-vs-synchronous
- context-management

---

Source: Claude Cert Prep — an independent, unofficial CCAR-P study resource (domain P1). Not affiliated with Anthropic.