The New For Loop
The for loop assumes the operation being applied is uniform — the same function, the same logic, applied identically to every element. This assumption breaks down when inputs are heterogeneous and unstructured: each element requiring different handling, the "operation" must adapt to what it finds.
The Parallel Sub-Agent pattern is the evolution of the for loop for intelligence-intensive work. Instead of applying the same function to each element, you dispatch an intelligent agent to handle each element — an agent that can reason about what it finds, adapt its approach, recover from failures, and produce a result appropriate for that specific input.
Where it shines — processing structured, homogeneous data: every order has the same structure, calculate_tax takes a known input type and returns a known output type. The loop is correct, efficient, and easy to reason about.
Where it strains — processing unstructured, heterogeneous data: 50 annual reports in various formats (PDF, HTML, Excel, or 404). Some in English, some in Japanese. Some are 20 pages, some are 300. The loop structure is there, but the loop body has exploded into conditional handling paths that only cover anticipated edge cases. Every unanticipated format is a potential failure.
This is the problem that Parallel Sub-Agents solve: not iteration, but intelligent delegation at scale.
A Parallel Sub-Agent pattern works as follows: a Manager Agent receives a collection of tasks and decomposes them into independent work items. For each work item, the Manager spawns a Sub-Agent with focused instructions. Sub-Agents execute concurrently. A Synthesizer Agent collects results and merges them into a coherent final output.
Fan-out parallelises independent sub-tasks; fan-in collects and synthesises results. The speed gain equals the sequential sum minus the longest individual task — only valid when tasks are genuinely independent.
| Feature | Traditional For Loop | Parallel Sub-Agents |
|---|---|---|
| Execution model | Sequential (or simple parallelism) | Concurrent with independent reasoning per item |
| Logic type | Static — same function for every item | Dynamic — each agent adapts to its specific input |
| Data requirements | Homogeneous, structured, typed | Heterogeneous, unstructured, variable |
| Failure mode | One unhandled exception can break the loop | Individual agents retry, skip, or escalate independently |
| Output type | Uniform — same type for every element | Diverse — each agent may produce different structure |
| Debugging | Identify the failing element; check the function | Identify the failing agent; read its reasoning trace |
Parallel Sub-Agents implement a Semantic Map-Reduce. In classic MapReduce (Google, 2004), the Map function is pure and deterministic. In Semantic Map-Reduce, the Map phase is a reasoning process and the Reduce phase (Synthesize) is also a reasoning process — resolving conflicts, identifying gaps, drawing cross-item inferences.
Semantic Map-Reduce replaces deterministic aggregation functions with an LLM reduce step that can deduplicate, synthesise, and rank natural language outputs — enabling analysis tasks that have no deterministic equivalent.
The Manager Agent's sole job is decomposition and delegation. It receives a complex task, identifies the independent sub-tasks, constructs the appropriate instruction for each sub-agent, and dispatches them. The Manager should not attempt to do the analysis itself — this adheres to the Single Responsibility Principle (Chapter 9).
When two or more sub-agents, given the same or equivalent inputs, produce different answers — this is divergent output. Unlike a traditional for loop (identical function calls always return identical values for identical inputs), parallel agents may reach different conclusions about the same document.
Three agents given the same prompt produce structurally different answers — not because any is wrong, but because the task under-specified the output format. The solution is a schema contract, not a prompt tweak.
The prerequisite for the parallel sub-agent pattern is independence: sub-agent A must be able to complete its work without requiring any output from sub-agent B.
Parallelism is only valid when tasks are independent. The dependency graph determines the architecture — not the other way around.
The practical design rule: decompose tasks into the largest possible units of independence. Run all independent tasks in parallel, then synthesize at the natural aggregation boundaries.
Sequential dependencies: When task B depends on the output of task A, parallelism is structurally impossible. Shared mutable state: Two agents writing conflicting updates to a shared scratchpad is just as problematic as two threads modifying shared memory without locks. Cost amplification: 50 sub-agents each consuming 2,000 input tokens is 100,000 input tokens — potentially orders of magnitude more expensive than a single sequential pass. Latency does not always improve: API rate limits can negate parallelism benefits entirely.
The for loop iterates. Parallel sub-agents delegate. Use parallel sub-agents when inputs are heterogeneous and require adaptive handling. Apply the Semantic Map-Reduce pattern: parallel reasoning (map) followed by intelligent synthesis (reduce). Design the Synthesizer to handle divergent outputs explicitly. Apply parallelism only where tasks are genuinely independent.
A for loop applies the same logic repeatedly. Parallel sub-agents apply judgment repeatedly. This is the difference between automation and delegation. The programmer who masters this becomes an architect of reasoning at scale.