Parallel Fan-Out / Fan-In

// 60-second mental model

How to hold it in your head

Split independent work. Run it at the same time. Merge when every branch returns — or when your join rule says “enough.”

Fan-out/fan-in dispatches independent sub-tasks concurrently, then joins results with an explicit merge policy (wait-all, wait-k, or first-success).

// Mini architecture

Fan-out independent work · join with a rule

              ┌────────────┐
              │ Dispatcher │
              └─────┬──────┘
        ┌───────────┼───────────┐
        ▼           ▼           ▼
   ┌────────┐  ┌────────┐  ┌────────┐
   │ Branch │  │ Branch │  │ Branch │
   │   A    │  │   B    │  │   C    │
   └───┬────┘  └───┬────┘  └───┬────┘
       └───────────┼───────────┘
                   ▼
            ┌────────────┐
            │ Join/merge │ → Final
            └────────────┘

Branches must be independent. If B needs A’s output, you wanted a pipeline — not fan-out.

// Mini-project

Three-source brief, wait-all join (stub)

Dispatcher + three stub branches

Goal: Fan out research stubs for docs, blog, and changelog; merge only after all three return.

1. Dispatcher receives a product question.
2. Fan out `branch_docs`, `branch_blog`, `branch_changelog` stubs in parallel (Promise.all).
3. Join rule: wait-all; on any failure, mark that branch `null` and continue.
4. Merger builds a brief with one section per non-null branch.
5. Refuse a serial “call A then B then C” path in the stub runner.
6. Log wall-clock vs. sum-of-branch times to show the point.

Simulated delays are fine. The lesson is independence + join policy, not real crawlers.

// Common failure

What goes wrong

// Self-reflection

Sit with this

Which of your “parallel” agent runs still waits on a hidden shared file?