Runaway prevention and the freeze.

Three shapes of runaway, one rail per shape CORE

Runaway orchestration is when a pipeline consumes materially more tokens, time, or dollars than the student expected when writing the blueprint. Lessons 8.1 through 8.4 named the risk; this lesson installs the rails.

Three shapes of runaway appear predictably. Each has a matching rail.

Shape 1: Depth runaway. A supervisor spawns workers; the workers spawn sub-workers; the sub-workers spawn sub-sub-workers. Each layer is locally reasonable; the total is not. A tree of depth 4 with modest fan-out at each layer can have 50 or 100 leaf agents, each producing output, none of which the student has read. The first time this happens to a student, it is almost always a surprise.

The rail: depth ≤ 3. Three layers — workers at the bottom, one supervisor coordinating them, optionally one meta-supervisor above the supervisor — is the default ceiling. This is enough to express any orchestration pattern a Module 8 student needs, and tight enough to keep the tree walkable by eye. Exceeding depth 3 requires a written reason on the blueprint. The default answer is that the student does not exceed it.

Shape 2: Fan-out runaway. A supervisor (or a parallel fan-out step) spawns ten workers when four would have done. Each worker’s cost is modest; ten of them is not. Fan-out tends to sneak in when the student writes the supervisor’s prompt as “spawn as many workers as you need” without a cap, and the model takes that permission and runs with it.

The rail: fan-out ≤ 4. Four is enough for a parallel content pipeline (the blog post + three social posts + newsletter example in Lesson 8.1) and keeps the combiner’s job tractable. Exceeding fan-out 4 also requires a written reason. A pipeline that needs fan-out 8 probably wants to be reshaped into two rounds of fan-out 4 — four workers, combine, then four more workers if needed. Batching is almost always cheaper and more legible than a single wide fan-out.

Shape 3: Retry runaway. A stage fails verification; the stage retries; the retry fails too; the retry retries; and because no one told the retry loop when to stop, it keeps going. A flaky tool call plus an aggressive retry loop can multiply token usage by five or ten without anyone noticing until the bill arrives.

The rail: bounded retries, always. Every handoff contract’s failure mode names a specific number of retries allowed (usually zero or one) and what happens after that number is exhausted (stop, alert, write a failed-status file). No contract is allowed to say “retry until successful.” This is where the Module 7 phrase audience = only you carries forward most concretely: a runaway pipeline that silently spent forty dollars because of a retry loop is a pipeline the student owns, not a pipeline the model misunderstood.

The three rails are not independent. A pipeline that respects all three has a bounded worst case — you can compute, before any invocation, an upper bound on how many agent invocations the pipeline can possibly make, and therefore an upper bound on its cost and time. A pipeline that violates any one of them has an unbounded worst case, and unbounded worst cases are exactly where runaway hides.

The pre-flight cost estimate CORE

The pre-flight cost estimate is a short arithmetic worksheet you run before any pipeline invocation and before any change to the pipeline that widens context, adds an agent, or changes a model. The estimate is one line for each agent, plus totals. The canonical template lives in /resources/module-08/pre-flight-cost-estimate.md; the shape is:

Three observations to make the table honest:

• Token counts are estimates, not measurements. Use whatever your first invocation’s trace reported (Lesson 8.3 and 8.4 captured these). For a pipeline that has not yet been invoked, estimate generously — round up, not down — because cost-estimate errors should fail in the direction of “I budgeted more than I needed,” never “I ran over budget.”
• Prices change. The Recipe Book carries the canonical cost-estimation prices for the cloud models the course defaults to; the price cells in the template reference that file by version. Re-read it when you re-run the estimate after a pricing change.
• Retries multiply the estimate. A pipeline whose retry policy allows one retry at each stage has an estimated-plus-retry cost of up to 2× the base estimate. Include this in the budget calculation. A bounded retry policy is not a cost-free policy; it is a cost-bounded policy, and the bound needs to be in the estimate.

The per-pipeline budget on the blueprint has two fields: a dollar budget (per invocation) and a wall-clock budget (per invocation). The estimate must fit inside both.

A pipeline whose estimate is inside the budget is cleared to run. A pipeline whose estimate is outside the budget has three legitimate responses:

1. Cut scope. Tighten handoff contracts to reduce token volume, trim an agent’s responsibilities, use a cheaper model for a classification step.
2. Raise the budget, with a written reason. Acceptable if the goal justifies the cost (a pipeline you will run twice a month and that produces high-value output can afford to cost more than a pipeline that runs daily). The reason lives on the blueprint.
3. Kill the pipeline. Some pipelines, honestly estimated, are not worth building. This is a rarer outcome in Module 8 than it will be in Module 10, but the option should always be on the table.

Re-run the estimate any time you change the pipeline in a way that affects tokens. This is the half-sheet of arithmetic that prevents the most common Module 8 runaway — a pipeline that was cheap at blueprint time and became expensive after three rounds of “small” additions.

The kill switch, and why you practice it CORE

Every pipeline has a kill switch. On the Claude Code path it is Ctrl-C in the parent session (or, if the session is orchestrating across a long sequence of Task-tool invocations, closing the parent session terminal window). On the Cowork path it is the disable task action in the scheduled-tasks UI (via update_scheduled_task), applied to every task in the pipeline. Neither is exotic. Both are trivial in principle.

The reason the module treats the kill switch as a discrete discipline is that in practice, students who have never used the kill switch freeze when they need it. They read the runaway trace, watch the tokens climb, hunt for the disable button, misclick the wrong task, try to fire a manual stop, and burn another thirty dollars figuring out the right sequence. The kill switch is a motor habit, not a feature.

Lesson 8.5 asks you to practice the kill switch once, deliberately, under no pressure. You start the pipeline, watch it begin, and stop it. No cost to stopping it mid-run that you were not going to pay anyway; large benefit to knowing how. Write down, on the blueprint, the exact sequence of clicks or keystrokes you used, so future-you can repeat the motion without thinking.

The blueprint’s Kill switch section has three fields:

• Command or clicks. Exactly what you do. “In the parent Claude Code session: Ctrl-C. In Cowork: open Scheduled Tasks → find morning-research, morning-summarize, morning-briefing → disable each.”
• Observable confirmation. How you know it worked. “Parent session prompt returns. No new status files appear in /pipeline/<name>/<today>/00-status/ after the next expected firing time.”
• Recovery. How you get the pipeline running again when you want to. “Re-enable each task in Scheduled Tasks; next firing time resumes as scheduled. Parent session: re-paste the orchestrator prompt.”

A kill-switch section with one of the three fields missing is incomplete. A blueprint with an incomplete kill-switch section does not freeze.

The Runaway audit CORE

The Runaway audit is a checklist you run across the frozen pipeline’s blueprint, subagent or scheduled-task definitions, handoff contracts, and tool allowlists. The canonical checklist lives in /resources/module-08/runaway-audit.md. Nine checks, grouped:

Shape checks (three):

1. Pipeline depth is ≤ 3. (If > 3, a written reason is present on the blueprint.)
2. Every fan-out step has a named cap ≤ 4. (If > 4, a written reason is present.)
3. Every handoff contract has all four fields present (input shape, output shape, success criteria, failure mode).

Failure-mode checks (three):

4. No handoff contract has an unbounded retry. Every failure mode specifies a bounded action: zero retries, one retry with a tighter prompt, fall back, skip, or stop.
5. Every stage’s verification (parent-session step on Claude Code; self-verification block on Cowork) actually checks each success criterion from the handoff contract.
6. Every failure mode names where the alert goes — a status file, a notification, a log. No failure mode fails silently.

Budget and kill-switch checks (three):

7. Pre-flight cost estimate is complete for every agent, and the pipeline total is inside the per-pipeline dollar budget.
8. Wall-clock estimate is inside the per-pipeline time budget.
9. Kill-switch section has all three fields filled in (command/clicks, observable confirmation, recovery).

A pipeline passes the audit when all nine checks pass. A pipeline that fails any check does not freeze until the check passes. The audit is not paperwork; it is the single rehearsal of every rail the module has installed, against the actual pipeline the student is about to ship.

The audit is also the artifact that goes in /capstone/pipeline-v1/runaway-audit.md alongside the blueprint — evidence that each check was actually run and passed. A blueprint without a passing audit is a blueprint that might have passed the audit; the course is interested in pipelines that demonstrably did.

The freeze, the retrospective, and the next-review date CORE

Freezing the pipeline is mostly a renaming and a commitment. The work is already done; the freeze is the promise to stop changing it without a reason.

What freezing means in practice:

• /capstone/pipeline-v1/ is the canonical folder. It contains the blueprint (no -draft suffix), the subagent folders or scheduled-task definitions, any skills the pipeline directly relies on, the traces folder (both invocations), the before/after block, the Runaway audit results, and the pre-flight cost estimate.
• /capstone/pipeline-v1-draft/ is the sibling-path folder (the path not picked in Lesson 8.4). It is not the frozen artifact; it is preserved for learning. Name its subfolder claude-code-sibling/ or cowork-sibling/ so the role is clear.
• The blueprint’s Next review section has a date on it, ≤ 90 days from today. The blueprint’s Budget and Kill switch sections are filled in completely. The blueprint’s Path-picking decision block (from Lesson 8.4) is at the top.
• my-first-loop.md has a Module 8 retrospective added: a one-paragraph summary of the pipeline, what it does, what was surprising, what would break on the next review date if nothing changes, and one sentence on whether the frozen pipeline is the pipeline the student will actually use (not all Module 8 pipelines are used after the module; honest retrospectives help you notice which ones are).

What freezing does not mean:

• It does not mean the pipeline cannot change. It means a change that is not a small bug fix gets a new version — pipeline-v2/ or a new sibling — not an in-place rewrite of v1.
• It does not mean the pipeline will always work. Tools change, skills drift, prices change. The next review date is when you ask whether the pipeline is still earning its keep; until then, the pipeline runs with the rails it has.
• It does not mean the course is over. Module 9 will pull on the security posture of this pipeline (prompt injection through shared-state files, supply-chain risk in the skills it depends on, credentials shared across agents). Module 10 will ask whether this pipeline is one of the components of the capstone system. The frozen v1 is a stable object those later modules can build against.

Three things land in my-first-loop.md today:

1. The pipeline retrospective (5–8 sentences).
2. The next review date, which should also be in the blueprint and in the capstone register if you keep one across modules.
3. A single honest sentence on whether the frozen pipeline is the pipeline you will use after the module. If yes, say so. If no, say why — the learning is legitimate regardless of whether the pipeline survives into month two.

The frozen-capstone folder layout RECIPE

This is the lesson’s recipe block — what the frozen folder looks like on disk at end of Module 8.

/capstone/
├── pipeline-v1/
│   ├── blueprint.md                     # Path-picking decision at top; all sections filled;
│   │                                    # budget, kill switch, next review complete
│   ├── runaway-audit.md                 # Nine checks, with pass/notes for each
│   ├── pre-flight-cost-estimate.md      # Agent-by-agent table + pipeline total
│   ├── subagents/                       # If Claude Code was the frozen path
│   │   ├── <agent-1>/
│   │   │   ├── SUBAGENT.md
│   │   │   └── … supporting files …
│   │   ├── <agent-2>/
│   │   └── <agent-3>/
│   ├── scheduled-tasks/                 # If Cowork was the frozen path
│   │   ├── <task-a>.md                  # Task name, schedule, skill reference, prompt
│   │   ├── <task-b>.md
│   │   └── <task-c>.md
│   ├── skills-referenced/               # Copies or references to Module 7 skills
│   │   └── …                          # cross-linked to the extension register
│   └── traces/
│       ├── <path>/invocation-1/         # Parent transcript (CC) or run logs (Cowork),
│       │                                # plus shared-state folder snapshot, plus pipeline
│       │                                # summary file
│       ├── <path>/invocation-2/
│       └── before-after.md
└── pipeline-v1-draft/
    ├── <other-path>-sibling/            # The path not picked in Lesson 8.4
    │   └── … similar structure; not required to be audit-passing …
    └── notes.md                         # Short: what the sibling demonstrated, what is incomplete

Two notes on this layout:

• The sibling path is preserved, not audit-passing. The sibling is learning evidence. It does not need a passing Runaway audit, a full pre-flight estimate, or a practiced kill switch. It does need enough content that a reader can tell what it is and what stage of completeness it reached.
• skills-referenced/ is a cross-reference to Module 7, not a copy. If the frozen pipeline depends on the student’s Module 7 custom plugin skill, the skill still lives under /capstone/custom-plugin-v1/. The pipeline folder just refers to it. This keeps the skill as a single source of truth that multiple pipelines can use, which is the same discipline Module 7 installed for the extension register.