When Not to Build an AI Agent: The Reliability Arithmetic

Step reliability multiplies. A component that is right 95% of the time produces a system that is right 60% of the time over ten steps. Most things being built as agents would be more reliable as workflows, and the test for which is one question.

Published 2026-09-04 · By Shahzad Asghar

Most systems being built as agents would work better as workflows. The reason is arithmetic, and it is worth doing before the architecture is chosen rather than after the pilot disappoints.

This is the question that comes before governance. Once you have an agent, authority, oversight and audit are the right concerns. This is about whether to have one.

The arithmetic nobody runs

An agent completes a task by taking a sequence of steps, each of which can go wrong. The probability of the whole task succeeding is the probability of every step succeeding, multiplied together.

Take a system where each step is right 95% of the time. That sounds strong. Over a ten-step task:

A 95% component produces a 60% system over ten steps. That is the gap between a demonstration that works and a deployment that does not.

Two things follow. Step count is the dominant variable — halving the steps does more for reliability than a marginal improvement in the model. And the reliability you need per step is higher than intuition suggests: for a ten-step task to succeed 90% of the time, every step has to be right 99% of the time.

These numbers are illustrative rather than measured. The point is the shape of the curve, not the specific figures, and the shape is unforgiving.

Where agents fail, and why it is hard to see

A workflow that fails usually fails visibly: a step errors, the process stops, someone is notified.

An agent that fails often does not stop. It takes a wrong step, treats the result as input, and continues reasoning from a false premise. The output arrives looking complete and confident, and the error sits in the middle where nobody looks. Detecting it requires reconstructing the whole path, which is exactly the evidence problem I have written about in AI agents and the future of internal audit.

Compounding failure that announces itself is a reliability problem. Compounding failure that does not is a trust problem, and it is worse.

The workflow alternative

A workflow is a fixed sequence written in code, where a model does the parts that need language and code does everything else: control flow, error handling, retries, validation.

Consider classifying an incoming support ticket, looking up the customer record, drafting a reply, and routing it for approval. As an agent, the model decides at each turn what to do next, and there are perhaps a dozen decision points where it could go wrong. As a workflow, the sequence is fixed. The model classifies. Code does the lookup. The model drafts. Code routes.

The model still does the parts only a model can do. What it no longer does is decide the order of operations — and the order of operations was never in doubt.

The gain is not only reliability. A workflow can be tested with ordinary methods, because the same input follows the same path. Failures land in known places. Any engineer can read the sequence without inferring it from logs.

The test

Can you draw the steps in advance?

If you can sketch the sequence on paper before building it, you have a workflow. Implementing it as an agent means paying for flexibility you have already established you do not need, in the currency of compounded unreliability.

If you genuinely cannot enumerate the path — because it depends on what is discovered along the way, and the branching is too wide to specify — that is where an agent earns its keep.

Most business processes fail this test. They were documented as procedures long before anyone considered automating them, which is itself the evidence that the steps are knowable.

When an agent is the right answer

Three conditions, and the case is strongest when all three hold.

The path cannot be enumerated. Open-ended investigation and research tasks qualify: the next step depends on what the previous one turned up, and the useful branching is too wide to hard-code.

A wrong path is cheap and recoverable. If a wrong step means wasted computation and a retry, exploration is affordable. If it means a payment sent, a message delivered, or a record altered, it is not.

A human reviews the output before it matters. An agent producing a draft for someone to check is in a fundamentally different risk class from one acting directly on a system of record.

Drafting, research, code exploration and triage proposals often meet all three. Anything that touches money, entitlements, personal records, or communication with a member of the public rarely meets the second.

The middle ground worth knowing about

The choice is not binary. Most of the value attributed to agents can be had from a workflow with narrow agentic sections.

Bound the tool set: an agent with four tools fails in ways you can enumerate; one with forty does not. Cap the iterations, and make hitting the cap an escalation rather than a silent stop. Put checkpoints between phases so the sequence is fixed at the top level even where individual phases are open-ended. And separate proposing from doing — an agent may draft any action it likes, provided execution passes through code that validates it.

That last one is the highest-value control available, and it costs almost nothing to implement.

What changes in an institutional setting

The arithmetic is the same everywhere. What differs is the cost of the failures it predicts.

In a consumer product, a 60% task success rate is a bad experience and a retry. In an organisation deciding eligibility, allocating assistance, or handling personal data, the same rate is a queue of wrong decisions about people who cannot easily contest them — and the compounding error is buried in a chain nobody can reconstruct.

Recoverability is the variable that should drive the design. Ask what happens if step six is wrong and nobody notices for a week. If the answer is a wasted afternoon, exploration is affordable. If it is a family removed from an assistance list, the sequence should be fixed, the actions gated, and the agent confined to proposing.

That is the same reasoning behind the Last-Mile AI Framework: the constraint is not what the technology can do, it is what happens when it is wrong in a place where being wrong is expensive.

A sequence that works

Write the steps down first. If you can, build the workflow — you are finished, and it will be more reliable than the agent would have been.

If you cannot, identify precisely which step is unenumerable. It is usually one, not the whole task. Make that step agentic and leave the rest as code.

Then bound it: fixed tools, capped iterations, and a validation layer between proposal and execution.

Measure per-step reliability before extending the chain, because the table above tells you what adding steps costs. And keep the fixed skeleton even after it works. The temptation once an agent performs well is to hand it more autonomy, which is precisely the move that takes a 90% system back to 60%.

For the controls that apply once an agent is running, see agentic AI governance. For the deployed examples, agentic AI in humanitarian work. And if you want to build the underlying skills, the free Learn Agentic AI course covers the ground in twenty-three modules.

Frequently asked questions

What is the difference between an AI agent and a workflow?

A workflow follows a fixed sequence written in code, calling a model for the steps that need language. An agent decides for itself what to do next at each turn. Workflows are more reliable and easier to test; agents are more flexible where the path genuinely cannot be specified in advance.

Why do AI agents become unreliable on long tasks?

Because step reliability multiplies. A system that is right 95% of the time per step succeeds on a ten-step task about 60% of the time, and on a twenty-step task about 36%. Reducing the number of steps improves reliability more than most model improvements do.

When should I use an AI agent instead of a workflow?

When the path cannot be enumerated in advance, a wrong step is cheap and recoverable, and a human reviews the output before it has consequences. If you can draw the steps on paper beforehand, build a workflow.

Are AI agents safe for high-stakes decisions?

Not acting on their own. For decisions affecting money, entitlements, personal records or public communication, the safer pattern is an agent that proposes and code that validates and executes, with a human reviewing anything that cannot be reversed.

How do I make an AI agent more reliable?

Reduce the number of steps, restrict the tool set, cap iterations with escalation rather than silent failure, insert checkpoints between phases, and separate proposing an action from executing it. Structural constraints usually do more than prompt engineering.

Is it worth building agents at all?

Yes, for the tasks that genuinely need them: open-ended research, exploration, and drafting where a person reviews the result. The mistake is applying that architecture to processes whose steps were already written down, which describes most of the work inside an organisation.

← All articles