Why a 95%-Reliable Model Builds a 60%-Reliable System

Production AI failure stories tend to start with a phrase like "but the model was working fine in testing." This is almost always true, and almost always misleading. The model is one component of a system. The system is what fails. The arithmetic of multi-step reliability — which is not optional, just often ignored — explains most of why.

Here's the math: if every step in your AI workflow succeeds 95% of the time, and your workflow has ten steps, the end-to-end success rate is 0.95 raised to the 10th power. That's approximately 60%. Forty percent of your workflows fail not because the model failed, but because the chain failed.

This is not a flaw in any specific model. It is the structure of multi-step probabilistic systems. Once you internalize it, a lot of AI design decisions look different.

The Compounding Math

Reliability in chained systems multiplies. Each step succeeds with probability p. The chain succeeds with probability p raised to the number of steps. The relationship is not linear; small changes in per-step reliability produce large changes in end-to-end reliability when the chain is long.

Here's the table that nobody publishes but every agent designer should keep in their head:

| Per-step reliability | 3 steps | 5 steps | 10 steps | 20 steps | |----------------------|---------|---------|----------|----------| | 90% | 73% | 59% | 35% | 12% | | 95% | 86% | 77% | 60% | 36% | | 99% | 97% | 95% | 90% | 82% | | 99.5% | 99% | 98% | 95% | 90% | | 99.9% | 99.7% | 99.5% | 99% | 98% |

Two things jump out.

First, even small drops in per-step reliability are catastrophic at length. The difference between 99% and 95% per step looks small (4 percentage points). Across 10 steps it's the difference between 90% and 60% end-to-end (30 points). Across 20 steps it's 82% vs 36% (46 points).

Second, the only way to get to high end-to-end reliability is to keep the chain short or push per-step reliability very high. A workflow with 10 steps needs 99.9% per-step reliability to clear 99% end-to-end. Most LLM calls are not 99.9% reliable, and they don't become so by trying harder.

Why This Is Not a Model Problem

The natural response to seeing 60% end-to-end reliability is "we need a better model." This is wrong in almost every case.

Switching from one frontier model to another changes per-step reliability by maybe 1-2 percentage points on most tasks. A model upgrade from 95% to 96% per-step reliability on a 10-step chain moves end-to-end from 60% to 66%. The 6-point improvement is real, but it leaves you well short of the reliability bar most production systems need.

The model is bounded. The number of steps and the verification between them are not. If you want to move from 60% to 90% end-to-end on the same task, the model upgrade alone can't get you there. The chain has to change.

This is why the engineering teams that succeed with agents don't optimize the model. They optimize the chain. Specifically: they make it shorter and they verify between the steps that remain.

Reducing the Chain

The single highest-leverage move for reliability is reducing the number of steps. This sounds obvious. It is almost never done aggressively enough.

Consider a typical agent workflow: a customer service agent designed to handle refund requests. The agent's natural design might be:

1. Read the customer's message

2. Look up the customer's account

3. Look up the relevant order

4. Check the refund policy applicability

5. Look up the order's current status

6. Determine if a refund is warranted

7. Calculate the refund amount

8. Initiate the refund in the payment system

9. Send a confirmation email

10. Log the interaction in the CRM

Ten steps. At 95% per-step reliability, 60% end-to-end. Most teams build this and then can't understand why customer satisfaction with the agent is lower than with the human agents it replaced.

A reliability-focused redesign asks: which of these steps actually need to be made by the AI? Which can be deterministic?

Steps 2, 3, 5, 8, 9, 10 are all deterministic operations. They don't require intelligence. They require structured data access and traditional code. The AI's job is steps 1, 4, 6, 7 — read the message, determine if a refund applies under the policy, decide the amount.

After this redesign, the workflow has four AI steps embedded in a deterministic pipeline. End-to-end reliability is the product of just the AI steps' reliabilities. At 95% each, that's 81% — a 21-percentage-point improvement, achieved by recognizing that most of the original "steps" were not actually probabilistic decisions.

Verification Checkpoints

The second highest-leverage move is verification between the steps that remain.

A verification checkpoint is a deterministic check that confirms a step succeeded before the next step runs. The classic example: the agent says it created a Jira ticket. The verification step queries Jira to confirm the ticket exists with the expected content. If verification fails, the workflow stops and escalates rather than proceeding into garbage.

Verification turns silent failures into loud failures. This matters more than it sounds like it should — the failures that destroy production AI deployments are almost always silent failures that propagate through downstream steps and corrupt state. A loud failure at step 3 is annoying. A silent failure at step 3 that cascades through steps 4-10 is a postmortem.

The math: if each step has 95% reliability and verification catches all silent failures, the workflow either succeeds completely (with probability close to 95% per step × number of steps) or it fails cleanly at a known checkpoint (with the remaining probability). The end-to-end success rate is the same — you can't conjure reliability from verification — but the failure mode changes. Failed workflows are recoverable. Silent corruptions are not.

The pattern that combines step reduction and verification is dramatically more reliable than either alone:

• Reduce AI steps to the minimum

• Verify after each AI step against a system of record

• Treat verification failure as an escalation, not a retry

• Log every state transition so post-mortems are possible

This is not exotic engineering. It is standard distributed systems design applied to probabilistic components. The teams that succeed are the ones that recognize agents need it.

Where the Steps Actually Hide

When you start counting steps in your AI workflow, you find more than you expected. The official agent definition might say "5 steps." The actual chain of probabilistic operations is often much longer.

Hidden step types:

Retries. Every retry of a failed step is another probabilistic operation. If the original step failed, the retry has its own failure probability. Three retries of a 95%-reliable step give you about 0.95 + 0.05×0.95 + 0.05×0.05×0.95 ≈ 99.9% success on that one step — which is much better than no retries — but each retry is also a chance for the agent to misinterpret the failure and take a different (incorrect) path.

Tool selection. When the agent has access to multiple tools and chooses among them, the choice is a probabilistic step. The agent picks the right tool 95% of the time. The wrong tool produces a downstream failure that may or may not be recoverable.

Format coercion. When the agent's output has to match a specific format and sometimes doesn't, the parsing or coercion step is probabilistic. If your function calling occasionally fails to produce valid JSON, that's another step in the chain even though you didn't design it as one.

Sub-agent invocations. If your agent spawns sub-agents that spawn sub-agents, each invocation is a chain of its own. The reliability of the outer system is the product of the reliabilities of every nested chain. This is how you get to 5% end-to-end reliability when each individual step looks reliable.

Tool response interpretation. When a tool returns a response that the agent has to interpret, the interpretation is a probabilistic step. The agent might misread a 404 as success, or a partial response as complete, or an error message as a content response.

Counting steps honestly is the first move. Many "5-step" agent workflows are actually 15-step workflows once you count the hidden steps.

When Step Reduction Isn't Possible

There are workflows where the chain is genuinely irreducible — long-horizon tasks like "research this topic, synthesize findings, write a report, verify each claim." These tasks are not amenable to deterministic decomposition. The AI is doing real work at every step.

For genuinely irreducible long chains, the only path to reliability is per-step reliability — pushing each step to 99%+ — combined with aggressive verification of intermediate outputs. The math is unforgiving: at 99% per step over 20 steps, you're at 82% end-to-end. To get to 95% end-to-end on 20 steps you need each step at 99.74%, which is at the edge of what current models deliver on most tasks.

Practical implications:

• Long-chain workflows have a reliability ceiling. Be honest about what end-to-end reliability you can achieve.

• For workflows where high reliability is non-negotiable (regulated, irreversible, high-stakes), shorter is the only viable approach. Decompose tasks into deterministic checkpoints.

• For workflows where some failure is acceptable (creative generation, exploratory analysis, draft production), longer chains are fine — but make the failure visible and recoverable.

The mistake is treating every workflow as if reliability is non-negotiable when only some of them are. The other mistake is treating every workflow as if some failure is fine when high reliability is actually required.

The Engineering Investment That Pays

Companies that get this right invest in three things:

Step-level instrumentation. Every step is logged. Every step has measured reliability. Drift in step reliability is detected and alerted on. You cannot improve what you cannot measure.

Per-step evaluation suites. Each AI step has its own eval suite that runs on every change. A change to one step's prompt or model is tested in isolation before it's deployed. This prevents the situation where a "minor prompt tweak" silently drops per-step reliability from 96% to 94% and end-to-end reliability craters.

Verification tooling. Building the deterministic checks that verify intermediate state. This requires understanding which systems-of-record can confirm what the AI claims happened. Spending engineering time here pays back in production reliability.

Companies that don't get this right invest in:

• Bigger models (1-2% per-step improvement, often expensive)

• More elaborate prompts (variable impact, hard to debug)

• More retries (improves apparent reliability, masks underlying issues)

• More tools for the agent to use (adds steps, reduces reliability)

The investment pattern reveals the company's understanding of the problem.

The Takeaway

A 95%-reliable model in a 10-step chain produces a 60%-reliable system. This is not a model failure. It is the math of compounding probabilities. The only ways to improve it are reducing step count, increasing per-step reliability, and verifying between steps.

The natural temptation is to focus on the model. The model is the most visible part of the system and the most marketed. It is also the bounded part — you can't get more than the model is capable of by changing prompts or paying more.

The unbounded parts are the chain length and the verification. Both are engineering decisions. Both are within your control. Both have more impact on end-to-end reliability than any model upgrade.

Count your steps honestly. Reduce them aggressively. Verify what remains. The reliability your users experience is the system's reliability, not the model's.

Frequently Asked Questions

Why does AI reliability compound multiplicatively?

Because each step in a multi-step AI workflow has its own probability of success, and the workflow succeeds only if every step succeeds. The math is the same as for any chained system: P(all steps succeed) = product of P(each step succeeds). A 95%-reliable step run 10 times gives 0.95^10 ≈ 60% end-to-end success. The model is not failing 40% of the time — the system is, because the failures compound.

How do I improve reliability in multi-step AI systems?

Three levers, in order of impact: reduce the number of steps (every step you can remove reduces compounding loss), increase per-step reliability (better prompts, better tools, better error handling), and add verification checkpoints between steps. Most teams try to increase model capability when reducing step count and adding verification would have far higher impact for less cost.

What's a verification checkpoint in an AI workflow?

A deterministic check between AI steps that confirms the previous step actually produced a correct result before the next step runs. For example: the AI says it created a ticket — query the ticketing system to confirm. The AI says it transferred funds — query the bank API to confirm the balance changed. Checkpoints prevent error propagation: a failure stops at the checkpoint instead of cascading through the rest of the workflow.

Is this a problem only with AI agents, or with LLMs generally?

Most visible in agents because they explicitly chain many steps. But the compounding math applies anywhere you chain probabilistic operations — a RAG system has at least three steps (retrieve, augment, generate), each with their own failure modes. A pipeline with five LLM calls has the same math as an agent with five tool calls. The compounding is structural, not specific to agent architectures.

Can I get to 99%+ end-to-end reliability with AI systems?

Yes, but not by improving the model. You get there by reducing step count (often to one or two), by making each step deterministic where possible (only the parts that need probabilistic intelligence stay AI; the rest become traditional code), and by adding strong verification. A system with two AI steps each at 99% reliability and a verifying checkpoint between them gets close to 98% end-to-end. A system with ten AI steps at 99% gives 90%. Fewer steps wins.