Module 3: Sequential pipelines

Module 3: Sequential pipelines

Next →

Description

Module 2 built a supervisor that decides: it reads every request and chooses, among three specialists, which one should solve it. That "deciding" has a cost — a routing call, a point where something can go wrong — and that cost is justified when the request can ask for different things each time. This module builds the opposite pattern: what to do when the task always needs the same steps, in the same order, no matter exactly what the member said. There, nothing needs deciding — what's needed is chaining.

The case that opens the module is the same one Module 1's lesson 06 already flagged, without building it: booking a Reservo room isn't just quoting and booking — Module 1, lesson 05, already measured that two-step path. Reservo's real process adds a mandatory third step in the middle: before confirming any booking, the cancellation policy has to be validated with the member. That step always goes there, between quoting and confirming, never before, never after, never optional. You'll build the runner that chains three agents — booking_agent, policy_agent, booking_agent again — passing data from one stage to the next, run end to end, and measure, with real numbers, how much that fixed order saves over a supervisor that had to decide at each of the three steps.

Hard rule of this module (read it before continuing)

We keep the same line as Modules 1 and 2: each agent's decision — which tool to call, what to answer — is not executed. It's still a hand-written script, labeled as concept (claude-sonnet-5). What is actually executed, for real, with Python 3.14 and its standard library, is the pipeline's complete orchestration: each specialist's runner (reused unchanged from agent-fundamentals and from this same guide's Module 2), building each stage's task from what the previous stages left behind, extracting the real data the next stage needs, and counting the whole pipeline's coordination cost. This module's novelty, unlike Module 2's, is that none of those executed pieces includes a decision about who to delegate to — the order is already fixed before any request arrives.

Where we are in the ecosystem

agent-fundamentals-and-tool-calling-guide (already complete)
  -> built ONE agent: tools, protocol, the loop, multi-tool, memory, robustness

multi-agent-orchestration-guide (this guide)
├── Module 1: Why multi-agent (and when not to)  (complete)
│   → The decision criterion, measured with real numbers
├── Module 2: The supervisor/router pattern  (complete)
│   → Deterministic routing vs. model-decided routing
├── Module 3: Sequential pipelines  ← YOU ARE HERE
│   → The second pattern: fixed order, with no routing decision at all
├── Module 4: Parallel fan-out and aggregation
├── Module 5: Handoff and delegation
├── Module 6: Shared state and the blackboard pattern
├── Module 7: Orchestrating Reservo's full system
└── Module 8: Project — Reservo's multi-agent system

This module doesn't re-explain what a supervisor is, or how deterministic or model-decided routing works — those are assumed mastered. What's new here is a pattern that has no Step 2 (decide): the sequence of specialists is fixed from the system's design, not from a model call.

Analogy: the recipe, not the front desk

Module 2 used a building's front desk: someone — a sign or a person — had to read each visitor and decide which floor to send them to. This module uses a different analogy: a cooking recipe. To make a cake, you always chop, mix, bake — in that order, without exception, no matter which specific cake you're baking. Nobody "decides" to chop before mixing every time they cook; the order is fixed in the recipe itself, written once, before any actual cake exists.

The difference from the front desk is exactly the difference between supervisor and pipeline: the front desk reads each visitor to decide their floor — the visitor could, in theory, need any of the three; the recipe never reads anything to decide the next step — it's always the same, for whatever cake gets baked with it. Booking a room with Reservo, when the process requires validating the cancellation policy before confirming, is a recipe: quote, validate, confirm, always in that order, for any member and any room.

The case running through the module: Reservo's booking pipeline

Module 2 left three finished, proven specialists: booking_agent (quote, book, cancel), policy_agent (search_docs, the policy stub), and pricing_agent (compare prices). This module adds no new specialist — it reuses the exact same three, without touching a line of their tools or their runner. What it adds is a different way to chain them:

Stage 1: quote                        -> booking_agent
Stage 2: validate the cancellation policy -> policy_agent
Stage 3: confirm the booking          -> booking_agent (again)

Notice something important right away: booking_agent shows up twice in the pipeline — it quotes in stage 1 and confirms in stage 3 — with policy_agent in between. In Module 2, SPECIALISTS identified each specialist by its name — a dictionary, SPECIALISTS["booking_agent"] — because the supervisor only needed to know "who" to delegate to. That's not enough here: what identifies each stage isn't just the specialist solving it, it's the role it plays in the sequence — lesson 02 formalizes exactly that difference.

The data travels from stage to stage: the price stage 1 quotes has to reach stage 3, without being recalculated, so it books that exact room/tier/hours combination. The policy stage 2 validates has to confirm, before stage 3 runs, that there's no impediment to booking. That data transfer — one stage's output turned into the next one's input — is the central mechanism this module builds and runs, starting in lesson 03.

Boundary with what you've already seen (and with what's coming)

With Module 2's supervisor fresh in mind, the underlying distinction becomes concrete:

  • A supervisor decides. Every time a request arrives, someone — a rules function or the model — reads it and chooses who to delegate to. The decision can change from one request to the next: "quote and book" goes to booking_agent; "what's the policy?" goes to policy_agent. All of Module 2 measures the cost of that decision and when it's justified.
  • A pipeline decides nothing. The order of the stages is fixed in the system's design, written once, before any concrete request exists. Every booking that goes through this module's pipeline quotes, validates, and confirms, in that exact order — never backwards, never skipping a step.

And looking ahead, a distinction this module leaves open on purpose:

  • When the steps do NOT depend on each other and can run at the same time — for example, if validating the policy needed nothing from the quote, the two stages could be dispatched together, in parallel, instead of one after the other — that's fan-out, and Module 4 builds it. This module's lesson 07 comes back to this exact question, applied to Reservo's own pipeline, as the natural bridge into that module.

With this, the first three of the five patterns Module 1 previewed become distinguishable without confusing them: supervisor decides who works (M2); pipeline fixes the order, deciding nothing (M3, this module); fan-out splits simultaneous work across stages you already know are independent (M4).

Prerequisites

Required knowledge:

  • ✅ This guide's Module 1, complete: the definition of a multi-agent system, the measured cost of coordinating, and the map of the five patterns.
  • ✅ This guide's Module 2, complete: SPECIALISTS, run_specialist, and Reservo's three specialists — booking_agent, policy_agent, pricing_agent — finished and proven.
  • ✅ agent-fundamentals-and-tool-calling-guide: a tool's contract, the tool_use/tool_result protocol, run_agent_parallel, and dispatch_parallel.

Recommended:

  • ✅ Having run Module 2 lesson 06's dispatcher yourself — that dispatcher's numbers (routing calls, hops) are the baseline this module compares a pipeline's cost against.

NOT required:

  • ❌ You don't need an API key or an internet connection: each agent's decision is still concept, hand written.
  • ❌ You don't need LangChain, LangGraph, CrewAI, or any orchestration framework.

Environment:

  • ✅ Python 3.14.0 with its standard library. Nothing to install.

Module roadmap

Lesson 01 — Module introduction (this one)

The pipeline pattern, the recipe analogy, and the boundary with supervisor (M2) and fan-out (M4).

Lesson 02 — The anatomy of a stage

PipelineStage, PIPELINE_STAGES, and why a stage is identified by its role — not just by the specialist that solves it. A first executed step, with the payload built by hand.

Lesson 03 — Chaining data between stages

The central mechanism: build_stage_task and extract_payload, generalized into run_pipeline. A small two-stage pipeline, run, with the data traveling from one to the other without asking the member anything again.

Lesson 04 — Reservo's pipeline, executed end to end

The module's centerpiece: the three complete stages — quote, validate, confirm — running with run_pipeline, with each stage's complete history printed and the final payload cited.

Lesson 05 — Measuring a pipeline's coordination cost

The comparison the module promised since lesson 01: the SAME three-stage task, solved by this module's pipeline and by a supervisor that had to decide at each step — with each path's calls and hops counted and cited.

Lesson 06 — When a stage fails

A pipeline's own fragility: with no decision in the middle, what happens when a stage returns a result that isn't enough to continue? A guard that stops the pipeline, executed, before confirming over unvalidated data.

Lesson 07 — Choosing pipeline or supervisor

The complete criterion, with a final question you can no longer avoid: do all of this pipeline's stages genuinely depend on each other? The executed bridge into Module 4.

Lesson 08 — Mini-project: Reservo's pipeline

Three new scenarios — two that complete the whole pipeline, one that triggers lesson 06's guard — run end to end.

Progression map

Lesson 01 (this one) → The pattern, the analogy, the boundary with M2/M4
Lesson 02             → A stage's anatomy: PipelineStage, PIPELINE_STAGES
Lesson 03             → The chaining mechanism: build_stage_task, extract_payload
Lesson 04             → The complete pipeline, executed (the dense one)
Lesson 05             → Coordination cost measured, compared against M2
Lesson 06             → When a stage fails, and how to stop the pipeline in time
Lesson 07             → Pipeline vs. supervisor, bridge to fan-out (M4)
Lesson 08             → Project: Reservo's complete pipeline

Difficulty: ⭐⭐ ──────────────────▶ ⭐⭐⭐

What you'll achieve in this module

By completing the 8 lessons, you'll be able to:

  1. Precisely distinguish a pipeline from a supervisor: a pipeline never decides who to delegate to — the order is already fixed before the first request.
  2. Build PipelineStage and PIPELINE_STAGES, identifying each stage by its role, not just by the specialist that solves it.
  3. Chain N agents with run_pipeline, passing the real data — not the model's free text — from one stage to the next.
  4. Run Reservo's complete pipeline — quote, validate, confirm — end to end, and cite its complete history.
  5. Measure a pipeline's coordination cost against a supervisor's over the SAME task, with real numbers, not estimated.
  6. Recognize when a stage fails without raising an exception — a result that isn't enough to continue — and stop the pipeline before acting on unvalidated data.
  7. Recognize the pattern's limits: when the fixed order is a real data dependency, and when it's merely a process decision that could, in reality, run in parallel (M4).

Before and after

BEFORE the module:
→ "Chaining agents" is simply "calling one after the other"
→ A pipeline and a supervisor that always delegates the same way are the same thing
→ Data between stages gets passed "however" -- a hand-built string is enough
→ A pipeline can never fail halfway through, because it decides nothing

AFTER the module:
→ A pipeline is CHEAPER than a supervisor for the SAME N-stage task -- it saves
  exactly one routing call per stage, because it never decides
→ Pipeline and always-delegates-the-same-way-supervisor are DISTINGUISHED by design, not by
  result: one has a decision in the middle (even if it always ends up the same), the other has none
→ Data between stages is grounded in a tool's REAL result -- never in what the model's
  free text says it did
→ A pipeline CAN fail halfway through -- not because a decision went wrong, but because a
  stage doesn't find what it needs for the next one to safely continue

Traps to avoid while taking this module

1. "A pipeline is just a supervisor that always delegates in the same order"

No — lesson 07 develops this carefully: the difference isn't the final result (sometimes they match), it's that a supervisor evaluates a decision at each step, even if it always ends up the same; a pipeline never evaluates anything — the order lives in the code, not in any call.

2. "Fewer decisions means a pipeline can never go wrong"

The opposite: lesson 06 measures exactly the opposite risk. With no decision in the middle, a pipeline has no natural point where it notices that something isn't enough to continue — you have to build that on purpose, with an explicit guard.

3. "All of a pipeline's stages genuinely depend on each other"

Not always. Lesson 07 examines this very module's pipeline and confirms, by running the code, that two of the three stages do not need the other's result — a finding that directly motivates Module 4.

4. "The payload traveling between stages can be the model's free text"

No — lesson 03 builds the mechanism with a hard rule: the payload is grounded in the tool's real result (ast.literal_eval over the tool_result), never in the sentence the model wrote, because that sentence is concept, not reliable data for the next stage to act on.

How to work through this module

  1. Run lesson 04 yourself. It's the module's centerpiece: the three complete stages, with data traveling from one to the next and each specialist's history printed.
  2. Pay attention to lesson 06. It's not a decorative edge case — it's the most important property separating "chaining" from "blindly trusting": a pipeline needs its own guards, because it doesn't have the honest "I don't know" Module 2's router did.
  3. Lesson 07 closes the criterion. Practicing it before Module 4 makes fan-out feel like the natural continuation of a question you already asked yourself, not a new topic.

Estimated time:

Lesson 01 (this one) →  15 min reading
Lesson 02             →  20 min + running the demo
Lesson 03             →  25 min + running the demo
Lesson 04             →  30 min + running the demo (the densest one in the module)
Lesson 05             →  25 min + running the demo
Lesson 06             →  25 min + running the demo
Lesson 07             →  25 min + running the demo
Lesson 08             →  30 min + applying the complete pipeline

Total: ~3.3 hours

Evidence of success

Before moving on to Module 4 (Parallel fan-out and aggregation), you should be able to:

  • ✅ Explain, in your own words, why a pipeline has no Step 2 (decide) — unlike Module 2's supervisor.
  • ✅ Build PipelineStage/PIPELINE_STAGES and run_pipeline, chaining at least three agents with real data traveling between them.
  • ✅ Cite from memory lesson 05's result: how many model calls and how many hops this module's pipeline saves over a supervisor that decided at each of the three stages.
  • ✅ Recognize when a stage "failed" without raising any exception, and why that demands an explicit guard a pipeline doesn't get for free.
  • ✅ Identify, in a concrete pipeline, which stages genuinely depend on the previous one and which could, in reality, run in parallel.

Summary

  • This module builds the second pattern of the five Module 1 previewed: sequential pipeline — one stage's output is the next one's input, in a fixed order, with no routing decision in the middle.
  • Hard rule: each agent's decision is still concept (claude-sonnet-5); chaining the stages, passing data between them, and counting the coordination cost are actually executed with Python 3.14.
  • The case reuses, unchanged, Module 2's three specialists — booking_agent (twice), policy_agent — chained through Reservo's real booking process: quote, validate the cancellation policy, confirm.
  • Clear boundary with what you've seen and what's coming: the supervisor (M2) decides who works; the pipeline (this module) fixes the order, deciding nothing; fan-out (M4) splits simultaneous work across genuinely independent stages.

Next lesson: 02 — The anatomy of a stage. We build PipelineStage and PIPELINE_STAGES, and run Reservo's pipeline's first stage.

Additional resources

  1. Anthropic — Building effective agents — The "prompt chaining" pattern described there (one step feeds the next, in a fixed sequence) is, under different vocabulary, exactly this module's pipeline.
  2. Anthropic — Multi-agent research system — A real workflow with mandatory stages in a fixed order before a result is treated as confirmed.
  3. Anthropic — Tool use (function calling) overview — The protocol every specialist in this module keeps following, unchanged, inside its own loop.
  4. Python — ast.literal_eval — The function this module's chaining mechanism uses to ground the payload in a tool's real result, never in free text.
← PreviousMini-project: Reservo's supervisorNext →The anatomy of a stage