Chapter 17 of 36 · ~1 min

Reliability

An agent that succeeds nine times in ten is impressive in a demo and unusable in a process that runs a thousand times a day. Reliability engineering for probabilistic components is its own discipline: retries under changed conditions, validation of outputs against a schema, structured outputs instead of free text, guardrails that reject unacceptable actions, fallbacks to simpler behaviour, human approval at the risky points, and graceful failure when none of that works.

The pattern to internalise: never let the model's output flow directly into a consequential action. Put a check between them. The check can be code, a second model, or a person. What matters is that it exists and that it is the thing you test.

A check between output and actionModel outputplausible, not verifiedCheckschema · second model · personActionthe consequential steppassesfails: retry with changed conditionsFallbacksimpler path or graceful failurestill failingTest the check. It is the partthat decides what happens whenthe model is wrong.
Never let model output flow straight into an action. Put a check between them.

Experiment

Live model

Ask for the same structured record ten times, validate each reply, and count how many would have broken the next step.

The model is asked for one product record as bare JSON with exactly four keys. The page then does what an application would do: parse it and check the shape, with no tolerance.

Runs against a live model through Chatterfly's server. Your text is sent to the model provider and not stored. Sampled at temperature 1 so that variation shows; a real system would add the check and the retry you see here.

Big question

What is your acceptable failure rate, and who decided?