Why AI agents fail in production — and the architecture that prevents it

The pattern is consistent enough to be predictable. A team builds an agent demo in a fortnight, everyone is impressed, and then it spends six months not reaching production. Gartner's widely reported projection — that more than 40% of agentic AI projects will be cancelled by the end of 2027 — describes the aggregate version of the same story.

The diagnosis matters, because teams usually reach for the wrong fix. When an agent is unreliable the instinct is to tune the prompt. But AI agents fail in production for reasons that better prompting cannot address: they are given more autonomy than the process tolerates, they lose state halfway through long workflows, nobody can tell when they regress, and there is no way to undo what they did.

Those are architecture problems. Here is what the architecture looks like when it works.

Failure 1: autonomy the process does not tolerate

The demo works because a human is watching. Production is different: nobody is watching, and the agent's fifth decision is built on its first mistake.

The fix is not to make the model more careful. It is to bound what the agent can do without confirmation, and to widen those bounds only where production traces show it earns them.

A workable default:

Action type	Default posture
Read data, summarise, draft	Autonomous
Write to internal records	Autonomous with audit log and undo
Spend money, message a customer, change entitlements	Confirmation required
Anything irreversible	Confirmation plus a second check

Teams resist this because it feels like admitting the agent does not work. It is the opposite: it is what lets you ship the 80% that is safe while you gather evidence on the rest.

Failure 2: state that quietly disappears

Long-horizon workflows are where agents fall apart. The agent starts a five-step task, the context window fills, early instructions fall out, and it completes step five having forgotten the constraint from step one. Nothing errors. The output looks plausible. This is the most expensive failure mode because it is silent.

Treat conversation history as a cache, not as the source of truth. The task state — what we are doing, what has been done, what is still required — belongs in your database as structured data that you re-inject deliberately at each step. The model reasons about the current step; your system remembers the plan.

Failure 3: one agent doing everything

A single agent that handles intake, lookup, decision and action is the fastest thing to prototype and the hardest thing to debug. When it misbehaves you cannot tell which capability failed, and a change that fixes one path breaks another.

Splitting into narrow agents with explicit handoffs costs more up front and pays back the first time you have an incident. Each unit has a defined input, a defined output and its own success criteria, so a failure is localised and testable. The orchestration between them should be ordinary deterministic code — not another model deciding what to do next.

The general principle: the more of your workflow that is deterministic code, the more reliable the system. Use the model for the parts that genuinely need judgement — understanding messy input, drafting language, classifying ambiguity — and let normal software handle sequencing, permissions and validation.

Failure 4: no evaluation, so no way to know

Without an evaluation harness, every change is a guess and every release is a coin flip. Teams in this position develop a superstition about prompts, because they have no evidence about anything.

The minimum useful version: 30 to 50 representative tasks with expected outcomes, scored automatically, run in CI on every prompt or model change. For agents, score the trajectory as well as the answer — the right result reached by calling a payment API twice is not a pass.

This is also what makes model upgrades safe. When a new model ships, you want to answer "is it better for us?" in an afternoon, not with a vibe.

Failure 5: a broken process, now faster

The least technical failure and the most common. An agent laid over a workflow nobody understands produces the same confusion at higher speed. If your refund process has three undocumented exceptions that a senior agent handles from memory, the model will not infer them.

Map the workflow first, including the exceptions. Where the process is genuinely ambiguous, that is a business decision to make — not something to delegate to a model and hope.

The order to build in

1. Pick one workflow with a measurable outcome and a clear owner.
2. Write down the decision points, including how humans currently handle exceptions.
3. Build the state model first — what the system must remember, in your database.
4. Add the model for the judgement steps only, with deterministic code around them.
5. Build the evaluation set before you tune anything.
6. Ship read-only or confirm-first, with full tracing.
7. Widen autonomy where the traces earn it, one action at a time.

This sequence takes longer to demo and much less time to productionise. If you are weighing whether that scaffolding is worth it for your first build, what an AI MVP actually costs breaks down where the effort lands, and RAG or fine-tuning covers the model-side decision that usually comes next.

When it is time to build the workflow properly, that is what our AI automation work is.