What you’ll be able to do
- Design explicit checkpoints a workflow must satisfy before advancing a stage
- Validate a handoff payload against a schema instead of assuming its shape
- Identify the classic silent-data-loss failure at a stage boundary
- Decide what happens when a handoff fails validation
What you need to know
A handoff boundary is where trust has to be earned, not assumed
Every multi-stage agent workflow has boundaries where one stage passes control and data to the next — triage to resolution, extraction to classification, draft to review. Each boundary is a place where a field can be missing, a value can be malformed, or a stage can advance on incomplete work. The architecture question is whether that boundary enforces its own contract, or just trusts whatever the previous stage happened to produce.
"Trusts" is the failure mode. A stage that reads ticket.category without checking it exists will happily process undefined as if it were a valid category — no exception, no alert, just a ticket silently misrouted.
Design explicit checkpoints, not implicit ones
A checkpoint is a condition that must be true before a stage is allowed to advance. Left implicit, a checkpoint is just "whatever the code happens to do next" — which usually means it advances regardless of whether the prior stage actually succeeded.
- Make the condition explicit — "category field is present and one of the five valid values," not "assume triage did its job."
- Check it in code, not in a prompt — a prompt instruction telling the model to "make sure the category is set" is advisory. A schema validation call either passes or raises.
- Fail loudly when it's not met — a checkpoint that silently defaults to a fallback value hides the failure instead of surfacing it.
The classic failure: silent data loss at the boundary
The "before" version doesn't crash when triage forgets to set a category — it just treats a missing field as falsy or defaults it somewhere downstream, and a ticket gets routed to "general" with nobody aware anything went wrong. That's the signature of a handoff bug: not an error message, but a quiet misrouting that shows up weeks later as "why do we have so many general tickets."
What to do when validation fails
Every enforced checkpoint needs a defined behavior for the failure path — not just a rejection, but a decision about what happens next. Options include escalating to a human, retrying the prior stage with feedback about what was missing, or halting the workflow with an audit trail. What's not an option, architecturally, is silently defaulting to a guessed value and proceeding as if nothing happened — that reintroduces the exact silent failure the checkpoint was built to prevent.
Key concept
A handoff boundary that isn’t validated isn’t a boundary — it’s a hope. Enforce the contract with a schema check, and give the failure path somewhere real to go.
When a scenario describes data quietly going missing or a workflow producing wrong results with no error, look at the stage boundary before you look at either stage's logic.
Practice scenario
Work it through, then open this
The approval stage trusted extraction’s output shape without validating it — a missing or zero amount should have been treated as an extraction failure, not a legitimate $0 invoice. The fix is a checkpoint between extraction and approval: validate that amount is present and greater than a sane minimum before the invoice is allowed to advance, and route anything that fails that check to manual review instead of silently letting it through.
Build exercise — Add a validated checkpoint to a two-stage workflow
Intermediate · 25 min
What you’ll learn
- Turning an implicit assumption at a boundary into an explicit, checked condition
- Designing a schema for a handoff payload
- Choosing a failure path instead of defaulting silently
-
Pick a two-stage workflow (real or hypothetical) and write down what the second stage currently assumes about the first stage’s output.
- Why: Assumptions at a boundary are usually invisible until you write them down.
- You should see: At least one assumption that isn’t actually enforced anywhere in code.
-
Write a schema for the handoff payload and add a validation call at the boundary.
- Why: A schema turns “we assume this field exists” into “we verify this field exists.”
- You should see: A validation step that would catch a missing or malformed field before the second stage runs.
-
Decide and implement a specific failure path for when validation fails — escalate, retry, or halt — rather than a silent default.
- Why: A checkpoint without a failure path just moves the silent failure one step later.
- You should see: A named, non-default behavior triggered on validation failure.
Exam traps
Assuming a handoff payload has the expected shape without checking
This is the single most common cause of silent misrouting in multi-stage workflows.
Treating a missing optional field as automatically safe to ignore
“Optional” in a schema doesn’t mean “irrelevant to this stage” — check whether the current stage actually needs it before treating its absence as fine.
Advancing a workflow stage before its checkpoint condition is actually verified
An implicit checkpoint is not a checkpoint. If nothing checks it in code, it isn’t enforced.
Building enforcement into a prompt instruction instead of a code-level check
A model instruction to “double check the data” is advisory and can be skipped under pressure or ambiguity. A schema validation cannot.
Having no defined behavior for what happens when a handoff fails validation
A validation check that has nowhere to send a failure just becomes a crash or a silent skip — neither is a design.