Let's start with arithmetic, because the arithmetic is the entire post.
Single step accuracy: 0.95
Chain of 8 steps: 0.95 ^ 8 = 0.663
A model call that is right 95% of the time is a genuinely good component. Chain eight of them, each consuming the previous output, and your end-to-end success rate is about 66%.
That is a coin flip with extra latency. And it gets worse, because the failures are silent — every individual step returned something structurally valid and semantically plausible. Nothing threw. Your logs look clean.
This is the failure mode that caught a lot of teams in the middle of 2026, after agentic scaffolding matured enough that people started shipping chains rather than single calls.
Why the failures are silent
In deterministic software, a broken step throws. You get a stack trace pointing at the line.
In an agent chain, step 3 misidentifies which customer record is relevant. It returns a perfectly well-formed record. Steps 4 through 8 then execute flawlessly against the wrong record. The output is coherent, confident, correctly formatted, and about a different customer.
There is no exception anywhere in that trace. Everything succeeded. The system is simply wrong, and it will be wrong at scale until a human notices something odd about a specific case.
Four things that actually help
1. Shorten the chain
The single most effective intervention, and the least fashionable, because "we replaced the agent with three deterministic steps and one model call" does not make a good demo.
Every step you can make deterministic is a step that cannot compound error. If step 4 is "look up the customer by ID", that is a database query, not a model call. A surprising proportion of agent chains in the wild contain model calls doing work a function could do — usually because the agent framework made it easy.
0.95 ^ 8 = 0.663
0.95 ^ 3 = 0.857 ← same task, 5 steps made deterministic
2. Validate between steps
Not "did it return JSON" — schema validation is table stakes and catches almost none of the real failures. Validate the semantics at each boundary:
- Does the returned ID exist in the source system?
- Is the amount within the range this account can produce?
- Does the retrieved record's owner match the requesting user?
- Is the classification one of the fourteen permitted values, or did the model invent a fifteenth?
Each check is a few lines and converts a silent wrong answer into a loud failure you can handle.
3. Constrain the action space hard
The instinct when building an agent is to give it every tool it might need. This is backwards.
Fewer tools, tighter schemas, narrower parameter ranges. Every tool you expose is a branch the agent can take incorrectly, and the failure rate scales with the branching factor rather than with model quality. The teams that succeeded with agents this year all did the same unglamorous thing: they cut the tool list down and made the remaining schemas strict.
4. Human checkpoint at the irreversible step
Find the point in the chain where an action becomes hard to undo — money moves, an email sends, a record is deleted, a customer-visible state changes — and put a human there.
This is not a failure of ambition. It is the same design principle as a payments system, and it is the correct mental model for agents generally: closer to how you design a transaction boundary than how you design a chatbot.
The heuristic for whether to build an agent at all
An agent is a good fit where the task has a verifiable output and a bounded set of actions.
- Reconciling invoices against a ledger — verifiable. The numbers either match or they do not.
- Triaging support tickets into a fixed taxonomy — verifiable. There are fourteen categories and a right answer.
- "Managing" a process with no definition of correct — not a project. An aspiration.
If you cannot state, in one sentence, how a program would check the output was right, you do not have an agent task. You have a demo.
What to instrument from day one
- Per-step success rate, not just end-to-end. You cannot fix a chain you cannot see inside.
- Where chains terminate, and why. Distinguish "completed" from "gave up" from "hit the retry ceiling".
- Cost per resolved task, not per token. A chain that retries three times is expensive regardless of how cheap the model is.
- Divergence between validation failures and user complaints. If users complain about cases your validators pass, your validators are checking the wrong things.
Frequently Asked Questions
Does a better model fix compounding error?
Only marginally. Going from 95% to 97% per step takes an eight-step chain from 66% to 78% — better, still not shippable for most purposes. Shortening the chain from eight steps to three does more than any model upgrade available.
How do I know how accurate each step is?
Build an evaluation set per step: 200 or so real inputs with known correct outputs at that boundary. Most teams evaluate only end-to-end, which tells you that something is broken but not where.
Are agent frameworks the problem?
Not inherently, but they make adding steps and tools frictionless, and friction was doing useful work. Whatever framework you use, treat every additional model call and every additional exposed tool as a cost that must be justified.
Where exactly should the human checkpoint go?
At the last reversible point before an irreversible action. Not at the start (you gain nothing) and not after the action (too late). If the chain has several irreversible actions, that is itself a design smell — batch them.
What about multi-agent systems?
The same arithmetic applies, usually worse, because inter-agent communication adds boundaries where meaning degrades. Multi-agent architectures are justified when subtasks are genuinely independent, not when a single chain felt too long.
How do we validate outputs without a ground truth?
Use constraint checks rather than correctness checks: does the ID exist, is the value in range, does the referenced entity belong to this user, is the category in the permitted set. These catch most real failures without needing a known right answer.
The wider 2026 picture — cost curves, evaluation, retrieval, regulation, org structure — is here: Top AI Developments for Business in 2026: What Actually Changed.
We build agentic workflows and LLM integrations for production use. Get in touch.
Top comments (0)