Module 7: Orchestrating The Full Reservo System

Module 7 Introduction: Combining the Patterns Over a Real Request

Description

The five previous modules built five pieces, each separately, each over its own example request: a supervisor that decides who to delegate to (Module 2), a pipeline of fixed stages where one result feeds the next (Module 3), a fan-out that distributes independent sub-tasks and runs them at once (Module 4), a handoff where an agent already in progress hands off the turn mid-way (Module 5), and a blackboard several agents read and write without passing direct messages (Module 6).

This module doesn't add a sixth pattern. It takes the five you already built, exactly as they are —same functions, same structures, not a single signature change— and makes them work together over a single Reservo request real enough to need more than one at once. The question this module answers isn't "how do I build a new pattern?" — it's "when do I combine which ones, and how do I decide which part of a request belongs to each?".

As in the whole guide, the hard execution rule doesn't change: the orchestration —the supervisor's plan translated into tracks, the pipeline, the fan-out, the handoff, the blackboard's reads and writes— is actually executed with Python 3.14, and its real output is cited in every lesson. Each agent's decision about what to answer is still concept, with realistic claude-sonnet-5 scripts — never a real API call.

Connection to the module

Every lesson in this module reuses code from an earlier module without modifying it: run_pipeline (03) is still the exact same three-line function you already know; run_agent_with_handoff (05) still stops exactly the same way when it recognizes handoff_to_specialist; Blackboard.write (06) still takes no recipient at all. The only genuinely new thing in the whole module is a thin composition layer —a way to annotate which pattern resolves each part of a request, and a mechanism to run those parts together— which you build in lessons 02 and 04. Module 8 comes back to this same composed run as the guide's capstone: a complete, delivered system, with a demo of at least two requests shaped differently.

Analogy: the restaurant's busiest shift, with all five roles working at once

This module doesn't need a new analogy — the five you already built, together in a single scene, are more than enough.

It's the busiest night at the restaurant from Module 1's lesson 01. The maître d' (supervisor) greets a large group and, looking at what they order, decides what each part of the order needs: a dish that needs to go through the full assembly line —cut, cook, plate, with a mandatory allergy check before serving— (pipeline); two loose questions from a customer that two different waiters can answer at the same time, without waiting on each other (fan-out); a waiter who, mid-way through taking an order, realizes a wine question isn't their thing and calls the sommelier right there, without going back to ask the maître d' (handoff); and, over all of it, the kitchen whiteboard, where any of them notes or checks the table's status —who ordered what, whether it's confirmed— without having to interrupt anyone to find out (blackboard).

No waiter, no cook, no sommelier changes jobs tonight. The only thing different is that, for the first time, everyone is on the same shift, resolving different parts of the same big order, at the same time.

The request that runs through the whole module

Every lesson in Modules 2 through 6 used its own isolated example request, to show one pattern at a time. This module uses a single, compound request, from lesson 02 through lesson 07 —each lesson adds one piece of the solution, without repeating what the previous one already resolved—:

Ana (design team): quote and book Focus pro 3h for the launch, validating the cancellation
policy before confirming. Also, compare Studio and Boardroom pro 3h in case we need more
space, and while you're at it, quote Boardroom pro 2h for the closing meeting -- also tell
me what happens if someone from the team doesn't make it to that meeting.

Read it slowly — you don't need to run anything yet, lesson 02 takes care of that. Notice that it contains, without you having looked for it on purpose, three completely different ways of working:

"quote and book Focus pro 3h... validating the policy before confirming" — a fixed, mandatory order, where step 2 (the policy) has to be resolved before step 3 (the confirmation). That's exactly what a pipeline (Module 3) resolves.
"compare Studio and Boardroom pro 3h" — a question that doesn't depend on anything else in the request: it can be answered without waiting for the Focus booking to be confirmed. That's what a fan-out (Module 4) resolves.
"quote Boardroom pro 2h... tell me what happens if someone doesn't make it" — a sub-task that starts in booking_agent's domain (quoting) but, mid-way, hits a question that lives in policy_agent's domain. That's what a handoff (Module 5) resolves.

And over all three, a shared blackboard (Module 6) keeps track of who the member is and which booking actually ended up confirmed — the one fact in this request another part of the system, in a larger run, might need later.

What this module does NOT do

It's worth being precise about the boundary, because it's easy to confuse "combining patterns" with "building something new":

It doesn't invent a sixth pattern. Every piece of the composed run is, without exception, supervisor, pipeline, fan-out, handoff, or blackboard — the five you already built. If at some point in this module you see a function you don't fully recognize, it's almost certainly a minimal generalization of one that already exists (lesson 04 builds exactly one of those, explained carefully), never a new coordination mechanism.
It doesn't measure coordination cost with numbers. Modules 2, 3, 4, and 5 already measured, each one, the cost of its own pattern (model calls, rounds, context bytes). This module doesn't repeat that count — it focuses on the criterion for when to combine which, not on quantifying how much doing so costs.
It doesn't deliver the complete system as a final project. That's Module 8: the capstone that builds Reservo's full multi-agent system —supervisor + the three specialists, over a shared blackboard, with a demo of at least two differently shaped requests and the cost count for each—. This module is the practice that makes that capstone possible; the capstone itself lives in Module 8.

The six lessons, in order

02 -- Anatomy of a compound request: which pattern resolves each part
      (the decision criterion, applied to the request above, WITHOUT running
      any agent yet -- just the decomposition).

03 -- The supervisor decides, the pipeline validates before booking
      (M2 + M3: the first sub-task, resolved with run_pipeline unchanged).

04 -- The independent questions run in fan-out while the pipeline resolves
      (M2 + M3 + M4: the second sub-task gets added, and both run AT THE SAME
      TIME with a ThreadPoolExecutor generalized to "any callable," not just agents).

05 -- An agent hands off mid-way through a fan-out branch
      (M5 gets added: the third sub-task starts in booking_agent and hands off the
      turn to policy_agent, WITHOUT the fan-out containing it noticing anything different).

06 -- A blackboard, shared by all three patterns at once
      (M6 gets added: the supervisor writes BEFORE the parallel tracks open,
      booking_agent writes AFTER the pool closes -- never during).

07 -- The full run, executed end to end
      (all five pieces together, at once: the full request resolved,
      with the composed final answer and a summary of which pattern resolved what).

Lesson 08 is the mini-project: you apply this exact same criterion to three new Reservo requests, shaped differently from each other —one that needs all three patterns, one that needs only two, and one that needs only one—, to confirm that lesson 02's criterion generalizes beyond Ana's request.

Common mistakes

Looking for a new pattern in this module. If a function feels unfamiliar, first check whether it's a minimal generalization of one you already know (lesson 04 has exactly one: run_tracks_parallel) before assuming this module introduces a coordination mechanism different from the five in M2-M6.
Thinking "compound request" means "always uses all five patterns." Ana's request uses three (pipeline, fan-out, handoff) plus the blackboard as shared substrate — there's no purely deterministic router nor any supervisor decision between several complete specialists, the way there was in Module 2 in isolation. Lesson 08's mini-project deliberately includes a scenario that needs only two patterns and another that needs only one.
Confusing "the supervisor decides the plan" with "the supervisor executes the plan." The supervisor (concept) decides WHICH pattern each part of the request belongs to — EXECUTING each part is done by the real mechanism (run_pipeline, run_tracks_parallel, run_with_handoff), not the supervisor itself.
Expecting this module to measure coordination cost with numbers, like Modules 2-5. It doesn't — that specific count for this composed run is Module 8's job, over the complete system delivered as the capstone.

Exercises

Exercise 1: Identify the three patterns in Ana's request, without running anything (Easy)

Read Ana's request from this lesson again, line by line, and for each of the three parts this lesson identifies (the Focus booking, the room comparison, the Boardroom for the closing meeting), write one sentence explaining why that specific part fits the pattern it was assigned and not one of the other four.

See solution

"Quote and book Focus pro 3h... validating the policy before confirming" → pipeline, not fan-out. It isn't fan-out because order matters: the policy has to be validated BEFORE confirming, not at the same time — if they ran in parallel, the booking could get confirmed before knowing whether there was any obstacle. It isn't a handoff because the full flow (quote, validate, confirm) is known in advance, it doesn't appear mid-way through a task that started out as something else.

"Compare Studio and Boardroom pro 3h" → fan-out, not pipeline. It isn't a pipeline because it doesn't depend on any other step — it doesn't need the Focus booking's result or anything else in the request. It isn't a handoff because it doesn't start in one agent's domain only to later discover it needs another — it's born, from the start, as a pricing_agent question.

"Quote Boardroom pro 2h... what happens if someone doesn't make it" → handoff, not plain fan-out. It starts out as a booking_agent task (quoting) and, mid-way, hits a question that lives in policy_agent (no-show) — the very agent already working recognizes the limit of its own expertise and hands off the turn, with nobody having anticipated it from the start of the plan.

Exercise 2: Build your own two-pattern compound request (Medium)

Write, in a single Reservo sentence, a request that combines ONLY two of the five patterns —you choose which— and explain, without running code, which part of your sentence belongs to each.

See solution

There's no single "code solution" for this exercise — it's a design exercise. One valid example: "Marta: book Studio pro 2h for the workshop, validating the cancellation policy before confirming. Also, what policy applies for groups of more than ten people?" — the first part is a pipeline (quote → validate → confirm, fixed order); the second is plain fan-out (a policy question born, from the start, in policy_agent, with no dependency on the booking and no handoff required). There's no handoff in this sentence because no agent hands off the turn mid-task — the supervisor already knows, from the start, that the second question belongs to policy_agent.

Exercise 3: Why isn't the blackboard "a sixth pattern tacked on at the end"? (Hard)

Without running code, explain why this module's Blackboard isn't one more sub-task of Ana's request —the way the pipeline, the fan-out, and the handoff are— but something of a different nature that runs through all three.

See solution

The pipeline, the fan-out, and the handoff are each a way of resolving a concrete part of Ana's request —they each have an input (a sub-task) and an output (an answer)—. The Blackboard, by contrast, doesn't resolve any part of the request on its own: it's the place where the facts those three parts produce (or need) become available for the rest of the run, with nobody having to hand them over directly. That's why Module 6 called it "shared state" and not "a resolution pattern" — it doesn't compete with the pipeline, the fan-out, or the handoff to resolve the same sub-task; it lives at a different layer, available to any of the three at the same time. This module's lesson 06 confirms it by executing: the supervisor writes to the Blackboard BEFORE any track exists, and booking_agent writes AFTER all three finish — the Blackboard isn't a sub-task with its own turn, it's the substrate that surrounds them.

Summary and next step

This module combines, without inventing any new one, the five patterns from Modules 2-6: supervisor (M2), pipeline (M3), fan-out (M4), handoff (M5), and blackboard (M6).
A single compound request from Ana runs through lessons 02 to 07 — each lesson adds one piece, without repeating the previous one, up to lesson 07's full run.
The module's central question isn't "how do I build X?" (you already know that) — it's "when do I combine which ones, and which part of a request belongs to each pattern?".
The capstone that delivers the complete system, with its own demo and its own cost count, is Module 8 — this module is the practice that makes it possible.

Next lesson: 02 — Anatomy of a compound request. We break down, without running any agent yet, Ana's request into the parts each pattern is going to resolve.

Additional resources

Anthropic — Building effective agents — The principle of composing simple mechanisms instead of designing a new one every time the task grows — the central idea of this whole module.
Anthropic — Multi-agent research system — A real system where several coordination mechanisms —not just one— coexist over the same task, exactly the kind of composition this module builds with Reservo.
Python — concurrent.futures — The module behind ThreadPoolExecutor, reused in lessons 04 to 07 to run sub-tasks differently (a loose call, a pipeline, a handoff chain) at the same time.
Anthropic — Agent SDK overview — What a production system that combines several of these patterns over the same task looks like in code — this guide's Module 8 final destination.

← PreviousMini-Project: Reservo's Blackboard Next →Anatomy of a Compound Request