Orchestrator-Worker Multi-Agent Pattern for the CCDV-F Developer Exam

What the orchestrator-worker pattern is

Once a task is large enough that a single agent labours through it step by step, the tempting move is to split the work across several agents running at the same time. The orchestrator-worker pattern is the structured form of that move, and the Claude Certified Developer - Foundations (CCDV-F) exam expects you to treat it as a deliberate cost tradeoff rather than a default. It is one of the agent patterns under Task Statement 1.3, assessed at apply level.

In the pattern, a lead agent decomposes the task into subtasks, delegates each to a subagent that runs in parallel with its own context window, and then synthesizes the subagents' returns into a final answer. It is the same manager-and-subagent shape as hub-and-spoke architecture, applied here specifically to buy parallel computation. The subagents do not share a context; each one reads its own slice of the problem and reports back a distilled result.

The cost is the whole point of the decision

The reason the exam frames this as a tradeoff is the token cost. Every subagent spends its own tokens against its own context window, so the bill scales with the number of subagents, not with the size of the answer. Anthropic has reported that its own multi-agent research system uses roughly 15 times the tokens of a normal single-agent chat interaction, because a lead plus several subagents plus a synthesis pass each carry their own input and output tokens.

A rough estimate makes it concrete. Suppose a single agent answers a research question in about ten thousand tokens. The orchestrator-worker version spins up a lead and four subagents, each reading its own slice of sources in its own context, and the lead then synthesizes the returns. At the reported multiplier, that same question costs on the order of a hundred and fifty thousand tokens. The number is neither good nor bad on its own; its value depends entirely on whether the task actually needed the extra agents.

When it pays off, and when it does not

The multiplier only buys something when the work genuinely decomposes into independent parts that can be explored in parallel. Research across many separate sources is the textbook fit: the subagents can read different sources at the same time instead of one after another, so the parallel computation shortens wall-clock time and improves the answer enough to justify the spend. Anthropic's own analysis found that token usage accounts for most of the performance variance, which is another way of saying the architecture works primarily because it buys more parallel computation.

The pattern is a poor fit for tightly coupled work such as coding, where each step depends on the previous one and cannot be explored in parallel. There the subagents mostly wait on each other, so you pay the fan-out cost without getting the fan-out benefit. For that kind of work a single agent with good context handling does the job at a fraction of the cost. This is the same Domain 1 instinct that runs through the workflow-versus-agent decision: reach for the more elaborate structure only when the task's shape actually requires it.

Two levers that keep the pattern honest

Even when the pattern fits, two details from the course keep it from becoming a runaway cost. The first is model choice: use a more capable model as the lead agent and cheaper models for the subagents, so you are not paying top-tier rates across every parallel context. That preserves coordination quality where it matters while lowering the blended cost of the workers.

The second is failure handling. Spreading work across agents multiplies the places a failure can occur, so each subagent still needs its own retriable-versus-terminal handling, backoff, and fallback. A single subagent that hits a rate limit with no backoff can stall the whole synthesis step while the lead waits for a return that never arrives. The orchestration pattern does not replace the failure-handling work; it multiplies it, which is one more reason to use it only when the parallel exploration is worth the added surface area.

Worked example

How this shows up on the exam

Domain 1 questions on this knowledge point describe a task and ask whether an orchestrator-worker setup is warranted, or present a multi-agent system whose cost has ballooned and ask why. The reliable reading names the ~15x token multiplier, ties it to each subagent spending its own tokens, and gates the pattern on whether the work splits into independent parallel parts. A tightly coupled task, especially coding, is the signal to stay with a single agent.

This pattern sits alongside agent memory and context-window management and context isolation through subagents as the Domain 1 tools for handling large tasks, and it rests on the same workflow-versus-agent decision that governs when any agentic structure is justified in the first place.