Agent orchestration — composing the work.

Lessons in this module CORE + RECIPE

Work through these in order. Each lesson ends with a project checkpoint that adds to your pipeline blueprint draft, captures a trace, or advances the freeze; Lesson 8.5 runs the Runaway audit and freezes /capstone/pipeline-v1/ as the eighth capstone artifact of the course.

1. 8.1   The shape of orchestration.

   Mostly CORE

   The mental-model lesson of Module 8. The shift from directing one agent to composing several, the three orchestration shapes (sequential pipeline, parallel workers, hierarchical supervisor), the two-question test for picking the shape (order dependency? runtime-variable decomposition?), the one-agent-too-many test — four questions that tell you not to orchestrate — and the runaway failure mode named early so you see it coming. You stand up an Orchestration Posture block in my-first-loop.md, sort four scenarios, and pick a real personal goal that passes the one-agent-too-many test.

   Open Lesson 8.1 →

2. 8.2   Handoff is a contract.

   CORE + RECIPE · headline technical insight

   The module's headline technical insight. The four-field handoff contract (input shape, output shape, success criteria, failure mode); the one contract per handoff rule and how to count contracts by pattern (N−1 for sequential, one fan-out + one fan-in for parallel, one per supervisor edge for hierarchical); the schema-vs-prose decision (language-to-language handoffs use structured markdown; tool-consumed handoffs use a named schema); the six vague-contract signals ("the output should be good," "retry if something goes wrong," contract longer than a page …); and the seven-section blueprint file. You create /capstone/pipeline-v1-draft/blueprint.md, fill in one contract per handoff, and run the Handoff contract drill to calibrate your eye.

   Open Lesson 8.2 →

3. 8.3   Building a sequential pipeline in the Claude Code CLI.

   Mostly RECIPE

   The first pipeline actually runs. A subagent is a separate AI agent your main session can hand a small job to — set up as a folder with a description and a list of tools it’s allowed to use; the parent session is the conductor, doing five steps of bookkeeping per stage (read contract, verify upstream, dispatch, verify output, move on). You author two or three SUBAGENT.md files under .claude/subagents/, write a short procedural orchestrator prompt, invoke the research → draft → review reference pipeline against real input, and capture two full traces (parent transcript + each subagent's invocation + shared-state folder snapshot + pipeline summary + wall-clock and token cost). You apply the two-round tightening loop: read the trace, find the weakest handoff (almost always not the weakest agent), tighten the contract, re-invoke — and file a before-after.md that names exactly what changed.

   Open Lesson 8.3 →

4. 8.4   Building a scheduled pipeline in the Cowork tab.

   Mostly RECIPE

   The second path. Cowork has no live supervisor — the orchestration is the arrangement of chained scheduled tasks plus the shared folder convention. You replace the parent's check-before-dispatch with self-verifying stages: each downstream task's first action is to read the upstream output, check every success criterion, and write 00-status/<stage>-skipped.md if anything fails. You build the daily briefing reference pipeline (morning-research at 6:00 → morning-summarize at 6:08 → morning-briefing at 6:15), stagger generously, capture two traces (one a real scheduled run, not a manual fire), and then pick the frozen path by the goal's shape — on-demand → Claude Code, cadence → Cowork, ambiguous → Claude Code by default. The unpicked path stays as pipeline-v1-draft/<other>-sibling/, preserved as learning evidence.

   Open Lesson 8.4 →

5. 8.5   Runaway prevention and the freeze (capstone).

   Mostly CORE

   The discipline lesson and the capstone freeze. The three shapes of runaway (depth, fan-out, retry), each with one rail (depth ≤ 3, fan-out ≤ 4, bounded retries always); the pre-flight cost estimate (agents × expected tokens × price per token, run before every invocation and before every change that widens tokens); the three-field kill-switch section (command or clicks, observable confirmation, recovery) you write after practicing once; and the nine-check Runaway audit (three shape checks + three failure-mode checks + three budget/kill-switch checks). You freeze /capstone/pipeline-v1/ — the eighth capstone artifact of the course — with blueprint, Runaway audit (all nine Pass), pre-flight estimate inside budget, traces, a 90-day Next review date, and a Module 8 retrospective in my-first-loop.md.

   Open Lesson 8.5 →

---

Resources for this module RECIPE

Five printable companions and one interactive activity run alongside the lessons. Each printable is a print-to-PDF page that prints cleanly on letter paper. Use them in the order their lessons reference them.

• Orchestration shape picker — printable for Lesson 8.1. The two-question test (order dependency? runtime-variable decomposition?) and the four-question one-agent-too-many test, laid out as a decision tree you can walk from a goal description to one of four answers: sequential, parallel, hierarchical, or don't orchestrate — tighten the single agent. Includes four worked scenarios and a blank block for your own Module 8 goal.
• Handoff contract template — printable for Lesson 8.2. The four-field contract block (input shape, output shape, success criteria, failure mode) copied once per handoff, plus one fully worked example (research → draft) and the six vague-contract signals as a review checklist. You print one copy per handoff in your pipeline.
• Pipeline planner — printable for Lesson 8.2 (blueprint scaffold). The seven-section blueprint template (goal, shape, agents, handoffs, shared-state folder, budget & kill switch, next review) laid out as a printable so you can think on paper before you touch the markdown file. Use alongside the Handoff contract template.
• Handoff contract drill — interactive HTML activity for Lesson 8.2. Five vague handoff descriptions of the kind a student would write on a first draft; for each, you rewrite into a four-field contract and the drill scores your rewrite against a rubric (four fields present, each field testable, no unbounded retries, no "the output should be good"). Reveal-on-submit scoring. The rep that installs the contract-as-artifact muscle.
• Pre-flight cost estimate — printable for Lesson 8.5. The agent-by-agent arithmetic table (model, expected input tokens, expected output tokens, price per token, estimated $ per invocation) plus the pipeline total, the per-invocation dollar budget, the wall-clock budget, and the three-way decision (cut scope, raise budget with a written reason, or kill the pipeline) when the estimate lands outside budget. Re-run before every pipeline change that widens tokens.
• Runaway audit — printable for Lesson 8.5. The nine-check ritual grouped as three shape checks (depth, fan-out, four-field contracts), three failure-mode checks (no unbounded retries, stage verification covers every criterion, failure modes name where alerts go), and three budget / kill-switch checks (estimate inside dollar budget, estimate inside wall-clock budget, kill-switch section has all three fields). Every flag is fixed before freeze. Preserved as runaway-audit.md in the capstone folder.

---

What you should have when this module is done CORE

By the time you close out Module 8, you should be able to point to seven concrete things on your machine and in your capstone folder:

• A frozen /capstone/pipeline-v1/ folder that is the eighth capstone artifact of the course, containing, in order: blueprint.md (path-picking decision at the top; goal, shape, agents, handoffs, shared-state folder, budget, kill-switch, next review all complete), runaway-audit.md (nine checks, all Pass, with one-line notes), pre-flight-cost-estimate.md (agent-by-agent table with a pipeline total inside the per-invocation dollar budget), a subagents/ or scheduled-tasks/ folder (whichever path was frozen), a skills-referenced/ cross-reference to the Module 7 skills the pipeline depends on, and a traces/ folder with at least two successful invocations plus the before-after.md.
• A sibling learning trace at /capstone/pipeline-v1-draft/<other>-sibling/ — whichever path (Claude Code or Cowork) you did not pick as the frozen home. The sibling does not need a passing Runaway audit or a polished blueprint; it does need enough content that a reader can tell what it is, what stage of completeness it reached, and what it demonstrated about this pipeline that the picked path did not. A short notes.md captures that last sentence.
• Every handoff contract in the blueprint filled in with all four fields (input shape, output shape, success criteria, failure mode), each readable as half a page, each passing the six vague-contract signals (no "the output should be good," no unbounded retries, no JSON schemas that do not name their keys, and so on). No contract exceeds one page; no contract leaves the failure-mode field empty.
• A practiced kill switch — not merely a documented one. The blueprint's Kill switch section has all three fields (command or clicks, observable confirmation, recovery) filled in based on what actually happened the one time you stopped the pipeline mid-run. A kill switch you documented without practicing is not a kill switch you can use when you need it.
• A pipeline that has been invoked successfully at least twice, with both traces captured in the frozen traces/ folder. "Successful" means the pipeline completed and the output was usable for your actual goal — not just that the success criteria fired green. The before-after.md names exactly what changed between invocation 1 and invocation 2, and cites a specific, observable difference in the output.
• A Module 8 retrospective in my-first-loop.md with: a one-paragraph summary of the pipeline, what surprised you during the module (often about handoff contracts or the stage that turned out to be the weak one), what would break on the next-review date if nothing changes between now and then (the retirement trigger), and one honest sentence on whether you will actually use this pipeline after the module. Honest retrospectives are what let you notice in month three which pipelines survive into month four.
• The completed end-of-module check in your portfolio, scored at 11.5 / 15 or better with full credit on at least one applied question.

If any of these is missing, go back to the checkpoint that produced it and finish before moving on. Module 9 assumes the pipeline composition is already clean — the security surface it examines (prompt injection through intermediate artifacts, supply-chain risk in chained skills, credentials across agents) is the security posture of this pipeline, not a generic one. A messy Module 8 freeze makes Module 9 miserable.