Lesson 4 - Parallel Loops and Handoffs

Welcome to Parallel Loops and Handoffs#

The last three patterns each used a single loop. This lesson scales up to more than one: running several loops in parallel for work with independent parts, and chaining specialized loops with handoffs for work that moves through distinct stages. These are the patterns behind “multi-agent” systems, but you don’t need to build anything elaborate to use the ideas — even by hand, recognizing when a task wants parallel loops or a handoff chain changes how you approach it. The goal here is the judgment, not the machinery.

By the end of this lesson, you will be able to:

• Recognize work that fits parallel loops versus a handoff chain
• Use an orchestrator to split independent parts across loops
• Chain specialized loops so each stage does one job well
• Weigh the costs — coordination, context loss, and checking the whole

Let’s start with running loops side by side.

Two Ways to Use More Than One Loop#

When one loop isn’t the right shape, there are two ways to bring in more, and they fit different kinds of work.

Parallel loops are for work with independent parts — pieces that don’t depend on each other and can be done at the same time. Researching three competitors is the classic case: shop A’s research doesn’t need shop B’s, so an orchestrator (a coordinator, which can be you or an agent) splits the task into three loops that run side by side, then collects the results and checks the assembled whole. The win is speed and focus: each loop does one clean piece, and they don’t wait on each other.

Handoff chains are for work that moves through distinct stages, each needing a different role. A report might flow: a research loop finds the facts, hands them to a drafting loop that writes it up, which hands off to an editing loop that polishes and checks. Each loop is a specialist doing one job well, and the output of one becomes the input of the next — like an assembly line where each station has a focused task and its own check.

The Costs of More Loops#

More loops aren’t automatically better — they add real costs, and the discipline is using them only when the work genuinely calls for it.

Coordination overhead. Splitting work and reassembling it is itself effort. For a small task, the coordination costs more than running one loop would have — so parallel loops and handoffs earn their keep on big tasks with clear seams, not on everyday jobs. If a task doesn’t naturally break into independent parts or distinct stages, one loop is simpler and better.

Context can get lost at the seams. When work hands off from one loop to the next, or gets split and reassembled, information can fall through the cracks — the drafting loop doesn’t know a caveat the research loop noticed, or a parallel piece assumes something another piece contradicts. Each handoff is a place for context to leak, so what you pass between loops has to be complete enough to stand on its own.

Every sub-loop still needs its own goal and check — and so does the whole. This is the point people most often miss. Breaking a task into parallel or chained loops doesn’t remove the need for goals and checks; it multiplies it. Each sub-loop needs its own finishable goal (Module 2) and honest check (Module 3), and someone has to check the assembled result — because three individually-fine pieces can still contradict each other or miss the overall goal. More loops mean more checks, not fewer.

Because of these costs, the honest default is to reach for more loops only when a single loop genuinely can’t do the job — when the task has clearly independent parts (parallelize) or genuinely distinct stages (chain). If you find yourself designing an elaborate multi-loop system for a task that a single draft-critique-revise or a plan-then-execute would handle, that’s usually a sign you’ve over-engineered it. The most common mistake here isn’t using too few loops; it’s using too many, adding coordination and seams to a task that never needed them. Start with the simplest shape that fits, and add loops only where the work forces you to.

A Harborlight Example#

The owner builds the full “local market report” from Lesson 2, and its plan has a natural mixed shape. The three competitor researches are independent — none needs the others — so they run as parallel loops: three research loops (Module 4), each sourcing one shop, kicked off together and collected. That’s faster and keeps each focused.

Then the report moves through stages as a handoff chain: the collected research hands off to a drafting loop that writes the sections, which hands off to an editing loop that tightens it and checks every claim is sourced and it fits two pages. At each handoff, the owner makes sure the passed material is self-contained — the drafting loop gets the sourced facts and the note about unverified event dates the research flagged, so that caveat doesn’t leak. Finally, they check the assembled whole, catching one place where two parallel research pieces gave slightly different numbers for the same competitor — a whole-level problem no single sub-loop could have seen. The report gets done well because the work was matched to the right multi-loop shape, with a check at every seam.

Practice Exercises#

Exercise 1: Parallel or handoff?#

Which fits: (a) summarizing five unrelated documents into five separate summaries, (b) turning raw research into a polished article through writing then editing, (c) fact-checking three independent claims?

Exercise 2: The multiplied check#

You split a report into three parallel research loops, each of which passes its own check. Why might the assembled report still be wrong?

Exercise 3: When not to split#

A colleague wants to build a five-agent handoff chain to write a single short social post. What would you tell them?

Summary#

For work too big or varied for a single loop, there are two ways to use more than one. Parallel loops handle independent parts — an orchestrator splits the work (like researching three competitors) into loops that run side by side, then collects and checks the whole. Handoff chains handle distinct stages — specialized loops (research, then draft, then edit) pass work down the line, each doing one job well. But more loops carry real costs: coordination overhead (so they earn their keep only on big tasks with clear seams), context loss at the seams (so what you pass between loops must stand on its own), and multiplied checks — each sub-loop needs its own goal and check and the assembled whole needs one too, since individually-fine pieces can still contradict each other. The judgment is the skill: decide which parts are independent (parallelize) and which are stages (chain), use more loops only when the work truly has seams, and put a check at each one.

Key Concepts#

• Parallel loops — independent parts run side by side under an orchestrator, then collected.
• Handoff chain — specialized loops passing work through distinct stages, each with one job.
• Coordination cost — splitting and reassembling is effort; multi-loop shapes fit big, seamed tasks.
• Multiplied checks — each sub-loop needs a goal and check, and so does the assembled whole.

Why This Matters#

Parallel loops and handoffs are how loop engineering handles the largest, most valuable work — full reports, multi-stage projects, anything with independent pieces or distinct phases. But the same lesson that makes them powerful is the one that keeps them honest: more loops multiply the need for goals and checks rather than removing it, and the assembled whole needs its own check. Recognizing which shape a big task wants — and resisting the urge to over-engineer a small one — is mature loop judgment. You now have four patterns for building loops well. The final lesson turns them over: the anti-patterns — the shapes that look productive but quietly go wrong — and a project to match the right pattern to real scenarios.

Continue Building Your Skills#

You can now scale beyond one loop — parallel loops for independent parts, handoff chains for distinct stages — while remembering that every sub-loop and the whole each need a check, and that more loops only help on genuinely seamed work. Match the shape to the task, and put a check at each seam. Next, you’ll close the module by studying the anti-patterns — infinite polish, goal drift, verifier collusion, and over-automation — and then prove your pattern judgment on four real scenarios.