Handoff Contract Template
Copy each filled sheet into: /capstone/pipeline-v1-draft/blueprint.md under the Handoffs section.
How many to print: one sheet per handoff. Count first (see Part 2). A three-agent sequential pipeline uses two sheets; a four-worker parallel fan-out uses two (one fan-out, one fan-in); a hierarchical supervisor with four worker types uses four.
Arrows do not carry meaning. Contracts carry meaning.
A contract with three of the four fields is not a contract — it is a wish. The most common omission is field 4 (failure mode), and that omission is exactly the opening through which retry runaway enters.
Part 1 — The four-field contract, copy-paste markdown
Paste this block once per handoff into blueprint.md. Then fill every field; do not leave any blank. "Whatever the upstream agent produces" is not an acceptable answer — if you write it, you have not thought about the handoff yet.
Part 2 — Contract-counting sanity check
Count the handoffs before you start filling sheets. If the count surprises you, revisit the shape picker (Lesson 8.1) before you go further.
| Shape | Handoff count | Rule |
|---|---|---|
| Sequential, N agents | N − 1 | One contract per arrow. Two agents = 1. Three = 2. Four = 3. |
| Parallel, N workers | 2 (always) | One fan-out contract (all workers share it) + one fan-in contract (governs the combiner). Worker count does not multiply. |
| Hierarchical, K worker types | K (plus upstream/downstream edges) | One contract per supervisor-worker edge. Multiple instances of the same worker type share one contract. |
My pipeline shape: ☐ Sequential ☐ Parallel ☐ Hierarchical
My handoff count: — print that many sheets.
Part 3 — Sheet template (fill one per handoff)
- Condition 1:
- Condition 2:
- Condition 3:
- Condition 4 (optional):
☐ Stop the pipeline and alert the student. Alert =
☐ Retry once with a tighter prompt, then stop. Retry prompt lives at
☐ Fall back to degraded output at
☐ Skip this stage and pass empty to the next. Downstream impact:
Part 4 — Schema or prose? (three-part test)
A contract is always written as prose in the blueprint. The question is whether the output shape the sender produces should be a machine-parseable schema or a prose format the next stage reads as natural language. Answer for each handoff.
- Is the output consumed by logic or by language? Logic (script, tool, calendar) → schema. Language (next agent reasons about it) → prose is usually fine.
- Is the output's structure stable enough to write down? Fixed fields every time → schema. Variable-length, variable-emphasis → prose.
- Is the pipeline running often enough to reward the ceremony? Daily + downstream script → schema earns its keep. Once a week, one-off → prose.
My answer for this handoff: ☐ Prose with markdown structure ☐ Named-field schema (JSON / YAML / table)
Part 5 — Six vague-contract signals (read every draft with this list)
If any of the following appears in a contract field, the draft is not ready. Tick the ones you caught — the iteration is the learning.
- "The output should be good." — Or "high-quality," "well-organized," "clear." Replace with word counts, required sections, required fields.
- "The receiver reads the output and uses it." — Not specified what shape, not specified what happens on malformed input.
- "Retry if something goes wrong." — Unbounded retries are the fastest path to token runaway. Specify cap and conditions.
- "The output is a JSON object." — Not specified which keys, which types, which are required. A JSON contract without named keys is a prose contract with an extra step.
- "The input is whatever the upstream agent produces." — The absence of a contract. Write the actual shape.
- Contract longer than a page. — Usually the student doing the agent's job inside the contract. Pull the work back into the agent's system prompt.
Part 6 — Output-matches-next-input cross-check
After you have filled every sheet, read them in order. For a sequential pipeline: the output shape of contract N should match the input shape of contract N+1 nearly verbatim. Any mismatch is a silent-corruption risk.
- Output shape of contract 1 matches input shape of contract 2.
- Output shape of contract 2 matches input shape of contract 3.
- Output shape of contract 3 matches input shape of contract 4 (if applicable).
- Every contract's failure mode names a bounded action (no unbounded retries).
- Every contract is readable in under a minute (roughly half a page).
- No contract contains any of the six vague signals from Part 5.
Part 7 — Worked example (reference)
From Lesson 8.2, for comparison against your own drafts.
This worksheet accompanies Lesson 8.2 of AI Architect Academy. The four-field contract, the contract-counting rule, the schema-or-prose test, and the six vague-contract signals are all concept. File layout and exact frontmatter are recipe and live in /recipe-book/writing-a-handoff-contract.md.