CLAUDE CODE AGENTS: ADVANCED ORCHESTRATION - Chapter 3, Exercise 3
An Original Fan-Out/Fan-In Workflow
====================================================================================

QUESTION:
Describe a fan-out/fan-in workflow of your own (different from this
chapter's own research-agent example), naming which steps fan out and
which single step they fan into, and why that structure is appropriate.

SOLUTION / EXPLANATION:

Example workflow: reviewing a large pull request that touches three
genuinely separate, unrelated modules of a codebase - say, the payments
module, the notifications module, and the user-settings module - before
writing one combined review summary for the whole pull request.

THE FAN-OUT:
Three separate code-review agents are launched in parallel, one per
module. Each agent's review task is genuinely independent of the other
two - reviewing the payments module's own changes doesn't require knowing
anything about what changed in notifications or user-settings, and vice
versa for each of the other two. Applying this chapter's own deciding
question to any pair of these three review tasks: does one need another's
actual result before starting? No - each can begin and finish entirely on
its own. This is exactly the profile that makes parallel execution
appropriate: genuinely independent tasks, each free to start immediately
without waiting on anything else.

THE FAN-IN:
Once all three review agents have finished, their three separate sets of
findings are combined into a single follow-up step: one summary agent
that reads all three reviews and writes one combined, prioritized summary
for whoever is deciding whether to approve the pull request. This step
genuinely cannot start until all three parallel reviews are actually
complete, since it needs their real findings as its own input - exactly
the dependency that requires this step to run sequentially, after the
fan-out finishes, rather than at the same time as it.

This structure is appropriate because it captures both real properties of
the underlying task correctly: the three reviews are genuinely independent
of each other (justifying parallel execution, and saving real wall-clock
time versus reviewing each module one after another), while the final
summary genuinely depends on all three results existing first (justifying
why it must wait and run sequentially afterward, not alongside them).

--------------------------------------------------------------------------
WHY THIS WORKS AS AN ANSWER:
It presents a workflow genuinely different from the chapter's own example,
correctly applies the chapter's deciding question to identify true
independence among the fanned-out steps, and explains precisely why the
fan-in step's genuine dependency on all three prior results is what forces
it to run afterward rather than alongside them.