Key takeaways
- Reliability starts with a narrow job contract: valid inputs, allowed decisions, permitted effects, finish state and named exception owner.
- Reduce the number of decisions made fresh on every run. Put stable rules in code and constrain genuine judgment to a small set of inspectable outputs.
- Evaluate ordinary cases, known failures and dangerous slices before release; then canary the change and compare destination state, not just model text.
- Track correction, abstention, duplicate-effect, recovery and latency rates by slice. A single overall success rate hides the failure that matters.
- Every corrected miss becomes a regression case and, where needed, a recovery drill. Reliability is an operating loop rather than a launch milestone.
Start with a job contract that can fail clearly
“Handle support” cannot be reliable because nobody can enumerate what success means. “Classify an inbound ticket into six labels, cite the evidence and route it unless identity evidence conflicts” can. Write the valid population, permitted sources, output schema, allowed actions, hard stops, finish condition and exception owner before changing a prompt or model.
The contract should define safe failure as an intended outcome. Abstaining on conflicting evidence may lower the automated-completion rate while improving reliability. A dashboard that counts every escalation as an error will teach the team to remove the control it needs.
| Outcome | Meaning | What it asks you to do |
|---|---|---|
| Clean completion | Correct result, permitted path, verified effect | Sample and monitor |
| Corrected completion | Human changed the proposal before effect | Add the case to evaluation; inspect the rule |
| Safe failure | Workflow stopped or escalated as designed | Measure service time and exception cause |
| Recovered failure | A fault occurred and repair restored the intended state | Test the recovery path and reduce recurrence |
| Harmful failure | Wrong, unauthorized or duplicate effect escaped | Contain, reconcile and block expansion |
Use a six-step reliability loop
- 01Inventory every variable decisionHuman approvalMark the steps whose output may differ on the same input. For each one, name the allowed answers, evidence, confidence boundary and escalation state.
- 02Make settled decisions deterministicCodeTranslate repeated accepted judgment into typed rules. Validate inputs and outputs, and keep the model only where the variety still changes the answer.
- 03Build production-shaped evaluation casesHuman approvalMix ordinary traffic, rare slices, corrected failures and adversarial inputs. Predeclare hard failures and minimum results by slice.
- 04Control authority and effectsCodeGrant the smallest tools and fields, require approval for consequential actions, add idempotency keys and verify the destination after each write.
- 05Canary and observe the complete runCodeRelease to a bounded population. Record state transitions, model decisions, tool attempts, approval waits, final effects, latency and cost under one run identity.
- 06Recover, learn and retestHuman approvalReconcile first, repair by effect state, preserve the failure as a regression case and prove the fix did not break accepted cases.
OpenAI's evaluation guidance recommends task-specific tests, production data, automated scoring where possible, human calibration and continuous evaluation. Google SRE's testing chapter makes a complementary point: a passing test does not prove reliability, but a failing test demonstrates its absence. Production evidence and pre-release tests need each other.
Measure the boundary where trust is lost
Track counts, denominators and time windows. “97% success” is useless if a retry counted as a new run, if escalations disappeared from the denominator or if the three harmful failures all affected the same high-consequence slice.
| Measure | Calculation | Why it matters |
|---|---|---|
| Clean-run rate | Clean completions / started runs | Shows how often no correction or recovery was needed |
| Correction rate | Human-changed proposals / reviewed proposals | Locates variable decisions that are not ready |
| Safe-failure rate | Designed stops / started runs | Separates healthy abstention from breakage |
| Harmful-effect rate | Escaped harmful effects / started runs | Hard safety boundary; report by consequence slice |
| Recovery coverage | Recovered failures / recoverable failures | Tests whether failure handling exists in practice |
| Duplicate-effect rate | Duplicate effects / intended effects | Exposes unsafe retries and missing business keys |
| p95 completion time | 95th percentile from trigger to terminal state | Shows tail delay hidden by an average |
Google's monitoring guidance centers latency, traffic, errors and saturation. An AI workflow needs those system signals plus decision quality, approvals and destination effects. Alert on a symptom an operator can act on: a growing unacknowledged queue, a harmful effect, or a hard-stop slice crossing its threshold.
One change at a time makes the cause legible
A team has 1,000 evaluation tickets. The current workflow has a 91.4% clean-run rate, a 6.8% corrected-completion rate and zero escaped effects on four hard-stop slices. A new prompt raises clean runs to 93.1%, but account-access abstention falls and one identity-conflict case routes automatically. The release fails its predeclared zero-tolerance gate.
The team moves the identity-conflict rule out of the prompt and into code. It reruns the same held-out set, then canaries 5% of eligible traffic for two days. The hard-stop slice remains clean, p95 completion time stays inside the budget and correction rate falls. Only then does the eligible population expand.
The reliability gain came from a smaller varying surface, not a more persuasive instruction. Use deterministic AI workflows to make that conversion explicit.
Limitations and when not to use this
- A reliability method cannot define the underlying policy or decide what consequence is acceptable. The accountable process owner must set those boundaries.
- Small samples produce unstable rates, especially for rare harmful events. Report raw counts and keep hard controls even when no incident appeared in the sample.
- Do not use aggregate reliability scores as automated performance measures for workers or as authorization for consequential customer decisions.
Sources
- Testing for Reliability — Google, Site Reliability Engineering Accessed 4 August 2026
- Monitoring Distributed Systems — Google, Site Reliability Engineering Accessed 4 August 2026
- Evaluation best practices — OpenAI Accessed 4 August 2026
- Artificial Intelligence Risk Management Framework 1.0 — NIST Accessed 4 August 2026
Score a workflow
Enter observed run counts and control coverage to expose the first reliability gap worth fixing.
Score a workflowUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.