Sequential chaining

Read these first

• Choosing an architecture

What you will know

• Chain prompts where each consumes the last

  The contract between stages determines whether later prompts receive stable, bounded, machine-usable input rather than drifting prose.

• Evaluate each link independently

  Per-stage fixtures and pass/fail metrics distinguish prompt regressions from upstream contamination.

• Compare a fixed chain with a single prompt and a loop on latency, cost, and quality

  A chain can improve controllability while losing on round trips and token spend, so the comparison needs fixed inputs and repeatable measurements.

• Show a task where chaining is entirely sufficient

  Deterministic workflows such as extraction followed by validation often gain little from adaptive orchestration.

• Find the link responsible for an end-to-end failure

  The visible downstream symptom can be misleading when malformed intermediate output is accepted without schema checks.

Chapters

1. 1

   The boundary between two stages is the thing you are designing

   Stage two writes prose, stage three parses it with a regular expression, and six months later a model update shifts the phrasing so 8% of runs break. Nothing regressed: nobody ever stated what stage two had to produce, so a phrasing habit was serving as the interface. Learn to declare a schema at each boundary, validate it before the next stage runs, and fail loudly there rather than downstream.

   Read chapter
2. 2

   A failed contract check needs a policy you wrote in advance

   Failing loudly at a boundary is half a design; the other half is what the run does next. The options are finite and chosen per stage: re-run the stage with the validation error appended, substitute a degraded output, abort the run, or dead-letter the record for a human — each with its own retry budget, and each demanding you know whether re-running that stage is safe once it has already written somewhere. Decide as well what a half-finished chain leaves behind. This is also the honest edge of the pattern: a chain can express any recovery you anticipated, while choosing a next action from the content of a failure nobody anticipated is what a loop adds.

   Read chapter
3. 3

   A fixed order of operations is what a chain is for

   Pull the fields out of a submitted form, then validate them against a schema and a reference table: the operations and their order are fixed, so an agent choosing its own next step has nothing to choose. This chapter shows how to recognise that shape and clears up a common confusion — retrying a stage is a control-flow decision you make in code at the boundary, not something only a loop can do.

   Read chapter
4. 4

   An end-to-end score says the chain failed, not which link did

   Per-stage fixtures look like duplicated effort next to a solid end-to-end set, right up to the day the chain quotes the wrong product tier and the score tells you only that something is broken. A dropped field and a bad prompt are repaired differently. Build pass/fail metrics and fixtures per link, so a prompt regression can be told apart from contamination arriving from upstream.

   Read chapter
5. 5

   Green fixtures certify only the properties someone asserted

   You edit stage one, its own fixtures still pass at 100%, and end-to-end drops from 88 to 71. That is exactly what you should expect: stage three depended on entities arriving in document order and nobody wrote that down. Walk the localisation — replay each stage on one failing input against the contract it promised — and settle who is at fault when the property was never asserted anywhere. Then close the class: the moment a consumer's hidden expectation is discovered, it becomes an executable assertion in the producing stage's fixtures, so ordering, defaults and field length are caught at the boundary instead of surfacing as an end-to-end drop.

   Read chapter
6. 6

   Three extra round trips need a reason the score cannot show

   Five stages score 84 against a single prompt's 82, at 4.6x the tokens and a p95 of nine seconds against two. Before that gap is a difference at all, you need the suite's run-to-run spread. This chapter runs the three-way comparison against a single prompt and a loop, then names the only honest reasons to keep a chain that ties: a stage you must audit, gate or version on its own. Whichever way you decide, write the decision down so it can be revisited — both scores with the measured spread beside them, the cost and p95 on the day, the condition that would flip the choice, and a trigger to re-measure when the model changes.

   Read chapter