A process that succeeds nine times out of ten sounds like a success. Chain five of those together and you are worse off than a coin toss. Here is the arithmetic behind most stalled AI projects, and the one design decision that fixes it.
The demo always works. That is the problem.
Someone shows you a process with a few moving parts. Read the document, pull out the figures, look up the right code, draft the entry, file it. The AI does the whole thing, start to finish, first time. It feels like magic, and not long ago it would have been. So the pilot gets signed off, the thing gets pointed at a hundred real cases instead of one, and everybody moves on to the next initiative.
Then the complaints start. Not a disaster. Something more corrosive than a disaster. Most of the output is fine. A stubborn minority is wrong in ways that take longer to find than the original job would have taken to do by hand. Nobody can say which part broke, because when you look, no part is broken. Every component did its job almost every time.
Almost turns out to be the whole story.
The arithmetic nobody runs before they build
Here is a number worth carrying into your next supplier meeting. Suppose one step in a process is ninety percent reliable. That is a good number. It is the kind of figure a vendor is happy to put on a slide, and the kind a sensible buyer would accept without argument.
Now suppose the process has five of those steps in a row, each one depending on the one before it. The chance of a clean run from end to end is not ninety percent.
It is 0.9 multiplied by itself five times. Which is 0.59.
Fifty-nine percent. Slightly worse than tossing a coin. Five confident, competent, individually impressive steps, and four runs in every ten come out wrong somewhere along the line. Push it to ten steps and you are down to thirty-five percent. The reliability did not accumulate the way intuition insists it should. It decayed.
That single calculation explains more stalled AI projects than any amount of discussion about model quality. The pilot looked fine because a pilot is usually one step, watched closely by the person who built it. The rollout is five steps running unattended, and nobody ran the multiplication.
This is not really an AI problem
It is worth being fair here. Nothing about that arithmetic is specific to artificial intelligence. It is what happens to any chain of steps where every link has to hold for the run to count, and it has been quietly spoiling manual processes since long before anyone had a language model. Any operations manager who has watched a five-stage handover degrade knows the feeling without necessarily knowing the formula.
What is new is how easily AI walks you into it.
Building a long chain of plausible-looking steps used to be expensive. Each link needed specifying, coding and testing, and the cost of that work forced you to ask whether the link deserved to exist. Now you can describe the whole sequence in a paragraph of plain English and have something that appears to work by the end of the afternoon. The friction that used to make you stop and count has gone. The arithmetic has not.
Look at what the steps actually are
Once you accept the maths, the fix stops being about better models and starts being about better architecture. You do not need every step to improve. You need most of the steps to stop being probabilistic at all.
Go back to those five steps and look honestly at each one.
Reading figures off a photographed receipt genuinely needs judgement. The image is skewed, the layout is unpredictable, the supplier name is a logo rather than text, and half the time somebody has folded it. That is a reasoning problem, and it is exactly what modern AI is extraordinarily good at.
Looking up the account code is a dictionary lookup. Writing the line to the ledger is an interface call with fixed rules. Attaching the document is a file operation. Filing it is another one.
One of those five needs a mind. The other four are things computers have done deterministically, correctly and boringly, billions of times a day, for decades. They only became unreliable at the moment somebody handed them to a system that reasons about them instead of simply doing them. We took four operations that were effectively certain and generously downgraded them to ninety percent by asking an intelligence to perform them.
A calculator does not get arithmetic right ninety percent of the time. It gets it right every time, because it is not thinking about it.
Let the AI decide. Let code execute.
That sentence is the whole method, and it is the principle underneath nearly everything I build. The shape of it is workflows, agents and tools.
The workflow is the plan, written in plain language. It reads like a standard operating procedure that a capable new starter could follow, because that is precisely what it is.
The agent is the AI. It reads the situation, weighs the ambiguous cases, and decides what should happen next. Judgement is its entire job.
The tools are small, dull, deterministic scripts that carry those decisions out. The agent decides which account code applies. A tool writes it to the ledger. The agent decides the receipt is a duplicate. A tool moves the file. Reasoning stays with the thing that reasons, and execution goes back to the thing that executes.
Run the numbers again under that split. The chain still has five steps, but only one of them is a weighted coin. The other four are back to being certainties. Your exposure falls from four hidden failure points, smeared across a process where you cannot tell which link snapped, to a single judgement call that is isolated, visible and cheap to check.
What determinism gives you back
There is a second benefit, and in practice it matters as much as the first.
When a deterministic tool fails, it fails honestly. It throws an error. It stops. It tells you the file was missing or the endpoint refused the request, and it does so in a log, with a line number.
An over-confident agent does something far more expensive. It improvises. It produces something shaped like the right answer and carries on, and the failure travels downstream wearing the costume of a success. By the time anyone notices, it is three steps away from where it started and the trail is cold.
A hard edge is a gift. It tells you exactly where you are.
This is why the systems that survive contact with real operations tend to look unglamorous. They are mostly ordinary code, with intelligence applied precisely where judgement is genuinely required, and firm boundaries everywhere else.
Where the human actually belongs
None of this makes AI infallible. That one genuinely probabilistic step is still probabilistic, and it will still be wrong occasionally.
The point is that you have cornered it. You know exactly where the uncertainty lives, which means you can put a person there. Not reviewing everything, which nobody sustains beyond the second week, but reviewing the single judgement that carries the risk.
That is why the systems I trust draft but do not approve. The AI reads the receipt and proposes the entry. A person clicks yes. The AI assembles the case and writes the recommendation. A person decides. The machine takes the ten minutes of tedium and hands back the ten seconds of decision.
That division is not timidity, and it is not a lack of ambition about what the technology can do. It is putting the fragile step in front of the one supervisor equipped to catch it, and leaving the robust steps alone.
The system that hardens itself
There is a final piece, and it is the one that turns a tidy diagram into something that improves with age.
Every time a tool fails in a new way, and it will, the fix does not simply get patched into the code and forgotten. It gets written back into the workflow in plain language, as a standing rule. When the batch endpoint rejects more than fifty records at once, split the request. When the supplier name is missing, do not guess, flag it.
So the process never breaks the same way twice. The failure becomes a sentence, the sentence becomes part of the standing instructions, and every future run inherits the lesson.
Notice what that does to the arithmetic we started with. A chain of probabilities decays as you extend it. A system that records its own failures moves in the opposite direction. It becomes more reliable the more it is used, which is precisely the outcome the opening calculation said you could not have.
Four questions worth asking
If you are buying, commissioning or approving something built on AI, the maths above turns into four fairly blunt questions. None of them require you to understand a model.
- How many steps are in this process, and how many genuinely need judgement?
- If most of the steps are mechanical, ask why an AI is performing them.
- What happens when a step fails?
- If the answer involves the system carrying on and doing its best, you have bought an improviser.
- Where does a person sit, and what exactly are they checking?
- If the answer is everything, then by month two nobody will be checking anything.
- What happens to a failure after it is fixed?
- If it is patched in code but never written into the process, you will meet it again.
Those are operational questions rather than technical ones, and they are the questions that decide whether the thing still works in a year.
The number that matters
Ninety percent is a wonderful figure for a demonstration and a dangerous one for a system. The instinct is to chase the missing ten percent across every step, which is expensive and largely futile.
The better move is to notice how few of the steps ever needed a mind at all, and to hand the rest back to the machines that were already perfect at them.
DCCO is an independent technology consultancy working across the UK and Europe. Founded in 2009, it covers AI adoption, rapid software development, and vendor-neutral advice on digital signage, DOOH, and IT and AV transformation.