Orchestrator-Subagent Fan-Out and Fan-In (CCAR-P)

The shape of a multi-agent system

The basic multi-agent shape is fan-out and fan-in: an orchestrator breaks a large job into pieces, dispatches those pieces to subagents that run in parallel, and then combines their results. The Claude Certified Architect - Professional (CCAR-P) exam treats understanding this shape as an understand-level skill because every later multi-agent judgement, failure handling, work assignment, observability, assumes you know who does what. The orchestrator decomposes and synthesises; the subagents execute independent units. Getting that division of responsibility right is the foundation the rest of the task statement builds on.

An orchestrator decomposes a large job into independent units and dispatches them to subagents running in parallel. Each subagent works its unit and returns a verdict or result. A synthesis step, owned by the orchestrator, aggregates those fanned-out results into a single output. The independence of the units is what makes the parallel dispatch valid, and the orchestrator's ownership of decomposition and aggregation is what keeps the system coherent.

Fan-out: dispatch independent work in parallel

Fan-out is the dispatch half. The orchestrator splits the job into units that do not depend on one another, classifying each document in a large corpus, researching each company in a list, checking each item against a rule, and sends them to subagents that run concurrently. The payoff is latency: independent units processed in parallel finish far faster than the same units processed one after another. This is why fan-out is the natural shape for large, decomposable jobs whose pieces do not need to talk to each other while they run.

Fan-in: the orchestrator synthesises

Fan-in is the aggregation half, and the key point is who owns it. Each subagent returns its own verdict or result, but the subagents do not coordinate the combining; the orchestrator does. Synthesis is the orchestrator's responsibility because only the orchestrator has the whole picture, it dispatched all the units and receives all the results, so only it can aggregate them into one coherent output. Expecting subagents to synthesise among themselves misplaces the responsibility: a subagent sees only its own unit and cannot combine what it never saw.

Synthesis must reconcile coverage, not just combine whatever came back. The most dangerous fan-in failure is silent: a subagent times out or returns an empty result, the orchestrator aggregates the results it happened to receive, and the fan-in produces a fluent, complete-looking answer built over work that was never finished. A run that dispatched fifty units and reports on forty-eight reads as "48 reviewed" instead of "two are missing" unless something checks. The guard is a coverage check at synthesis: the count of results returned must equal the count of units dispatched, or the run flags the gap before anyone reads the output. A timed-out or empty subagent is a recoverable failure only when the synthesis step is watching for it; completeness has to be verified, never assumed.

Independence is the precondition

Fan-out is valid only when the units are genuinely independent. If two units actually depend on each other, verifying a fact before acting on it, or two research threads that overlap, running them in parallel produces subagents that duplicate work or contradict each other, because none of them can see what the others are doing while they run. The orchestrator's decomposition has to produce units that can safely run without knowledge of each other. When the work is not independent, the pieces must be sequenced, not fanned out, which is a decomposition and dependency-ordering concern rather than a fan-out one.

The cost multiplier: fan out only when the payoff earns it

Latency is the reason to fan out, but it is not free. Every subagent carries its own context, and the orchestrator pays again to synthesise what they return, so dispatching N workers in parallel multiplies token spend rather than adding to it. A fan-out over fifty units is not one job's worth of tokens; it is fifty scoped contexts plus the aggregation pass on top. That multiplier is why multi-agent design is never the default shape. Reach for it when the work genuinely exceeds what a single context can hold or when the units are numerous enough that serial processing blows the latency budget, and only when the speed or quality gain is worth the extra spend. If a single agent, or a plain parallelisation workflow, can do the job inside one context, the fan-out is paying for coordination it does not need. The exam rewards the reading that treats the token multiplier as a real cost weighed against the latency payoff, not a detail to wave through.

What the CCAR-P exam trips candidates on

The exam tests two traps. The first is assuming subagents coordinate the aggregation themselves instead of the orchestrator owning synthesis. A scenario will describe subagents combining their own results, and the credited answer relocates synthesis to the orchestrator, since only it sees all the fanned-out results and can aggregate them coherently.

The second is fanning out units of work that are not actually independent, causing subagents to duplicate or contradict each other's findings. A scenario will parallelize interdependent work, and the reliable reading notices the hidden dependency, recognises that parallel subagents cannot see each other, and sequences the dependent pieces rather than fanning them out.

Common misreadings to avoid

How this shows up on the exam

Domain 1 questions on this knowledge point present a multi-agent design and ask who owns which responsibility or whether the fan-out is valid. The reliable reading places decomposition and synthesis with the orchestrator, treats subagents as executing independent units in parallel, and checks that the fanned-out units are genuinely independent rather than hiding a dependency that requires sequencing.

This shape is the foundation of the multi-agent task statement. It builds on the autonomy spectrum and feeds failure-boundary design in orchestration and coordinator task decomposition quality. The independence precondition connects to dependency ordering in decomposition, and fan-out mirrors the parallelization workflow sub-pattern.