Prompt chaining with quality gates

What you'll learn

• Explain the difference between a workflow and an agent by who chooses the next step.
• Map each of the five T7.3 patterns to the one decision it hands the model.
• Trace a gated chain through its pass path and its retry-limit path, call by call.
• Diagnose why a gate leaks, loops or lets an unusable result through.

T7.2 ended with an agent that picks its own tools. This module goes the other way: five patterns where your code draws the path and the model fills in one kind of decision.

A Larkspur customer writes I want my money back for last month. A useful reply needs the plan and the purchase date before it can apply the refund-window policy. A chain that drafts straight away turns those missing inputs into a polished guess. This lesson builds the guard against that, and first separates two kinds of system.

Who picks the next step

The distinction comes from Anthropic's Building Effective Agents (December 2024). In a workflow, LLM calls and tools run along code paths you defined in advance. In an agent, the model directs its own process: it picks the next tool, reads the result and decides when to stop. The ReAct agent of T7.2 is an agent. All five T7.3 patterns are workflows.

The two differ in what you can know before a request runs:

Table 1: Workflow and agent, side by side.

A Larkspur refund reply has a shape you can draw: pull out the plan and the date, check them, draft, polish. Investigating why one customer's servers keep rebooting has no such shape, and that is where an agent earns its extra calls.

One decision per pattern

Each workflow pattern hands the model exactly one kind of decision and keeps the rest in code:

Table 2: The five patterns by who decides what.

The gated chain in this lesson shows how little the model controls. Its compiled graph has five nodes and eight edges, and only three edges are conditional:

Table 3: The recorded edge list of the gated chain. All three conditional edges leave the gate.

Everything the model decides happens inside a node. Where the run goes next is decided by code you can read, which is what the next section relies on.

Prompt chaining splits one task into a fixed sequence of focused calls, each reading the previous step's output. The lesson's chain turns a topic into an email in three steps: extract the key points, draft, polish. A quality gate sits between two steps and decides whether the intermediate result may go on.

Where the gate sits

The gate checks the cheapest artefact that can already be wrong. Failing after extraction costs one check. Failing at the end costs a draft and a polish written from nothing:

Figure 1: The gated chain. The gate can pass the key points on, send extraction round again, or stop the run with a reason.

We call the failure this prevents writing from nothing: later steps spend calls polishing a result whose input was never usable.

The three parts of a gate

A gate is three separate pieces, and keeping them apart is what makes each one testable:

Table 4: Check, router and bound.

The counter uses a reducer, a rule for combining a node's update with the value already in state. Here the rule is addition, so each extraction's 1 accumulates into an attempt count.

Two recorded runs

The two recorded runs take the two exits of Figure 1:

Table 5: Both exit paths, from the notebook's recorded output.

The second run spent three judge calls to avoid writing and polishing an email with no purpose. It also ended with a message a caller can show or log, which a crash or an empty email would not give.

Planted failures

Each piece of the gate exists because something specific goes wrong without it:

Table 6: One planted case per guard.

Pitfall: the repeating regenerator. A retry only helps when the next attempt can differ. At temperature 0 the extractor may return the same points, and lower temperature does not guarantee identical output either. Check that retries actually change the result, and that the judge grades the same text consistently.

Gates in other frameworks

The same gate appears in the two alternative builds of this lesson:

• LCEL (LangChain Expression Language, which composes runnable steps with |): the gate is a step that passes the payload through or raises a rejection error. A retry wrapper re-runs extraction and gate together, playing the reject edge, and a fallback plays fail_validation.
• Structured output at every hop: each step returns a validated object, so shape errors are caught without an extra judge call. Shape is all it checks.

The refund reply follows the same chain:

1. Extract the plan, the purchase date and the request from the ticket.
2. Gate: check that the ticket names a plan and a purchase date. Without them the refund-window chunk cannot be applied.
3. On pass, draft from the refund policy and polish.
4. On the third reject, end at a terminal node whose reason asks the customer for the missing date.

I want my money back for last month fails the gate before any drafting, and the customer is asked one precise question. In lesson 2 of T7.3 the same ticket meets a different decision: which queue, and which model, should handle it.

• Two runs. Table 5 comes from one recorded run per topic; a new run can extract different points and the judge can word its reasons differently.
• One judge. The gate's verdicts were not compared against human labels, so its false-pass rate is unmeasured.
• Left out: a gate per step. Add one after drafting when the draft itself can fail a check you can state, such as a missing policy citation.

The code for this lesson is in these notebooks. Colab runs one in your browser: install the packages its first cell imports and set the API keys it reads. To run every notebook as written, clone the repository and use its uv environment.

• In a workflow your code fixes the path and the model makes one kind of decision; in an agent the model picks every step. Use a workflow for any task you can draw before it runs.
• Put the gate after the cheapest step that can already be wrong. Check with an LLM judge that returns a structured verdict, and route in a pure function you can test without a model.
• Bound retries with a counter and a terminal node that records why the chain stopped. A schema checks shape, never usefulness, so typed output still needs a gate.