Five agent steps at ninety percent each is a coin flip. Nobody writes that number down, because the demo only ran once and it worked. Every failure in my own system so far has been a seam between two steps, not the model doing the work.
The number nobody computes
Do the arithmetic before you read anything else.
Five steps, ninety percent success each. Multiply it out. Zero point nine to the fifth power is fifty nine percent. That is not "mostly works." That is a little better than a coin flip.
Tighten every step to ninety five percent and add one more, so six steps at ninety five. That lands at seventy three percent. Still a bet. Nobody would ship a payment flow that fails a quarter of the time, and yet six step agent chains ship at that rate every week and get called automations.
An observability vendor published numbers in the spring that keep resurfacing in the August agent coverage. It says agents fail somewhere between seventy and ninety five percent of the time in production depending on task complexity and how success gets measured, and that an estimated eighty eight percent of enterprise agents that work in a controlled demo fail once they hit real workflows. It cites research where a sixty percent single run success rate drops to twenty five percent when measured across eight consecutive runs. Its own worked example is a three step chain at seventy percent per step, which multiplies out to about thirty four percent end to end. That vendor sells observability tooling, so read the framing accordingly. The multiplication does not care who published it.
Here is why the number stays invisible. A chain gets demoed once. It works once. That single run becomes the reliability claim, and then it gets repeated in a standup, then in a deck, then on a landing page. Nobody reruns the demo fifty times, because rerunning it is boring and the first run already felt like proof.
My chain broke, and it was never the model
I hit this in my own content system, which is the only reason I trust the framing.
My posts move through a pipeline. A drafter writes, a critic annotates, I approve, a publisher ships, a watcher marks what actually went out. Five steps. Ordinary stuff.
The watcher matched exactly one status value and skipped every other one. Posts that shipped down the second path never got marked as shipped. So my own system reported a pile of work stuck at the gate while eleven of those posts were already live and had been for a while. After the fix, the posted count went from seven to eighteen in a single pass.
Nothing was wrong with the model. Nothing was wrong with the drafter, the critic, or the publisher. Every step did the job it was given. The failure lived in the handoff between two of them, inside an assumption about what one step would hand the next.
That is the pattern I keep hitting. The seams break, not the intelligence. And a seam is not a model problem. It is a design problem, which means it was already decided before anybody wrote code.
A checkpoint that can lie to you is not a checkpoint
Look at where the tool vendors are spending their fixes.
Claude Code shipped two releases in three days in early August. Read the two changelogs together and almost nothing in them is about making the agent smarter. Anthropic says it fixed isolated sessions and their subagents being able to run destructive commands against the main checkout. It says it fixed auto allow hooks that bypassed tool restrictions inside background tasks. It says it fixed a permission bypass where a crafted command could hide part of itself from the permission check, and a case where a command padded with tabs or invisible Unicode could hide part of itself from the approval dialog. Those are Anthropic's own changelog claims. I have not tested them.
Sit with that last one for a second.
The human was in the loop. The human was looking at the approval dialog. The dialog was showing a different command than the one about to run.
So the checkpoint existed, the person did their job, and it still failed. Which means "we have human approval" is not the answer people think it is. A gate whose display you cannot trust is decoration.
I made the full case a few weeks ago for the one gate in my own pipeline that I will not automate. This is the condition that gate depends on. Keeping a human at the door only buys you something when what the human sees is what is about to happen. Otherwise you bought a signature, not a check.
Silent success is the expensive failure mode
The dangerous state is not the loud error.
A loud error is a gift. It stops the chain, it names itself, and somebody goes and looks. Cheap.
The expensive state is the step that reports green while dropping work. My watcher looked healthy the entire time it was stranding posts. Statuses moved, counts added up, nothing threw. A watcher that matches the wrong status is worse than no watcher at all, because with no watcher you know you are blind and you go check by hand.
So here is the rule I now apply to every step in a chain. Every step needs a state it is allowed to fail loudly in. A step with no way to report failure has no way to report success either. It only has a way to report that it ran.
Without that, you are measuring the dashboard instead of the system.
Fewer steps between checks, not a better model
The instinct when a chain is unreliable is to go shopping. Better model, bigger context window, a framework with more orchestration in it.
I don't want a smarter agent sitting in the middle of a five step chain. I want fewer steps between the places where I can tell whether the work is still correct.
That is a design decision, and it gets made before implementation. Two questions do most of the work. Where can this chain be wrong without me knowing? And how expensive is being wrong at each point it could surface? Put the checks where a failure is still cheap to absorb, then shorten the distance between them until the compound number stops scaring you.
The infrastructure is arriving to support exactly that reading. Cloudflare closed its first Agents Week by grouping everything it shipped into compute, security, toolbox, and prototype to production. A persistent sandbox per agent. Versioned storage for what agents write. Scoped private networking into databases and APIs. An identity per agent instead of a shared service account. A browser with a live view and a human in the loop control. Those are Cloudflare's own claims about its own products.
Read the shape, not the product list. A vendor spending a whole week on filesystems, identity, and an interruptible browser is telling you that capability stopped being the constraint. From my perspective that is the clearest signal of the last month. The frontier moved from what the agent can do to whether you can see what it did and stop it in time.
What I would want to know before adding another agent
Here is the part I do not have.
I don't know where the per step success rate actually sits in most real systems, and neither does almost anybody running one, because almost nobody measures it. The numbers above are somebody else's benchmarks on somebody else's tasks. Your chain is not their chain.
So I would say the recommendation comes with a prerequisite attached. Before you add the next agent, run the chain you already have enough times to get a real per step number. Twenty runs on live inputs beats any published benchmark for your purposes. Then multiply your own numbers, look at what comes out, and decide whether the next step earns its slot, or whether the honest move is to collapse two steps into one and put a check between what is left.
I write these builds up as they happen, including the ones where my own system lied to me, in The Production Layer at timurtek.com.
Ninety percent is a good number for a step and a bad number for a chain. Multiply before you add.
