9 min read
The commercial promise that reaches AI buyers is simple. With the tools available today, anyone can build an autonomous agent that automates a complex workflow. It's a promise with a true half. Access to building has been democratised in a way that three years ago seemed distant. Frameworks, language models, orchestration platforms, and visual interfaces let a small team or a single person assemble in a few hours something that receives a natural language instruction, plans three or four steps, queries external systems, drafts a response, and sends an email. That demo is honest, in the limited sense that it genuinely executes the flow.
What the demo doesn't show is the distance between that one successful execution and reliable execution at volume, with real data, in an organisation that already has processes and systems the agent must respect. In the demo everything converges: the instruction is clear, system state is predictable, tools respond as expected, and someone is watching. In production, any of those conditions can fail at any moment, and nobody will be watching when it happens.
What did get cheaper
Building an agent prototype today requires, operationally, very little. A language model accessible by API, an orchestration layer that chains calls, a couple of connected tools (email, calendar, a CRM, a document base), and an interface that lets you watch it run. In an afternoon you can arrive at something that receives a natural language instruction, plans three or four steps, queries data, drafts a response, and sends an email. That demo is honest, in the limited sense that it genuinely executes the flow.
What the demo doesn't show is the distance between that successful execution and reliable execution at volume, with real data, in an organisation that already has processes and systems the agent must respect. In the demo everything converges: the instruction is clear, system state is predictable, tools respond as expected, and someone is watching. In production, any of those conditions can fail at any moment, and nobody will be watching when it happens.
This ease of starting is real and valuable. It lets a company that previously couldn't even prototype an idea now have it running in a week. The problem is that same ease generates a flat expectation. If building the agent was simple, getting it to production should be a natural continuation of the same effort. That expectation is what then produces the 40% cancellation rate.
The first gap is architectural
An agent's architecture goes beyond a diagram of what components it has. It is the set of decisions about what it can do, what it cannot do, what information it can see, when it must stop, and what it should hand off to a person. Those decisions are not suggested by the framework. They are made by whoever designs the system, with technical judgement that comes from having seen similar systems fail before.
A simple concrete example. An agent that handles commercial queries about contracts must decide, on each turn, whether to respond with information retrieved from the documentation or to escalate to the human team. That decision is part of the system's architecture. If the agent responds when it shouldn't, the customer receives incorrect information about a current contract. If it escalates when it should respond, the agent loses its purpose and the human team remains just as overloaded as before. The boundary between the two cases requires defining precisely what type of query tolerates an automatic response and what doesn't, and that definition is built in conversation between whoever knows the business process and whoever knows the system's failure modes.
There is a second architectural front the ease of the demo conceals. Agents that chain several steps accumulate error at each link. An agent that plans five actions and fails with 10% probability at each one has a roughly 59% probability of a clean execution. The arithmetic is trivial; the design that accounts for it is not. You have to decide at which points in the flow to check state before continuing, which steps are reversible, which steps require confirmation, and which steps can execute optimistically with a rollback plan. For the full analysis of when multi-agent architecture complicates more than it helps, see multi-agent systems explained.
Architecture also defines guardrails. Which sensitive data stays out of context, which actions require explicit authorisation, which responses get blocked before reaching the user. An agent without explicit guardrails operates with limits defined by accident — by the model's training data and the framework's default configuration. That is a position no buyer who understands their own business should be comfortable with.
The second gap is engineering
If architecture decides what the system does, engineering decides how it behaves when things go wrong. And in systems with probabilistic components like agents, things go wrong regularly. A production agent must recover from malformed model responses, timeouts in external tools, corrupted input data, and instructions users phrased in ways the agent didn't anticipate. Each of those scenarios is a chapter of code, monitoring, and tests that the demo never required.
There are four pieces a production agent needs that a demo can omit without consequences. Fault-tolerant orchestration, with selective retries, backoff, and compensation mechanisms for actions that can't be undone. Observability, which allows you to understand what the agent did on any given case when a user reports a problem three days later. Tests, including adversarial cases and edge cases that don't appear in the happy path. And human oversight at the points where the action's risk exceeds the system's confidence — a pattern developed in more detail in automating fixed processes.
None of those four pieces gets built in an afternoon. Each requires decisions specific to the client's domain and tests against their real infrastructure. The work is, in large part, what software engineers have been doing for twenty years in mission-critical systems. What's new is that one of the system's components now returns non-deterministic responses, and that changes what can be guaranteed and what can be tested. The need to do the work is still there.
Engineering also has a chapter that is not technical but that belongs in its territory nonetheless. A production agent needs a business metric that someone tracks, a human owner who signs off when something irreversible happens, and an explicit agreement about what happens when the agent makes a mistake. Companies that managed to put agents to work building value built those boring parts first: clean data, a clear job per agent, correct tools and permissions, a human who signs, a number the business tracks. The impressive parts came after, once those conditions were in place.
The result is a pilot that doesn't close
The failure pattern of agent projects that don't reach production repeats itself. The prototype works under controlled conditions, impresses in a presentation, and then gets asked to operate with the company's real data, real permissions, real volumes, real users. That's when the costs the ease of starting had hidden appear: the data cleanup work nobody had quantified, the internal systems integration nobody had negotiated, the human responsibility nobody had assigned, and the oversight nobody had designed.
That cost describes what it is worth to build a system that works inside an organisation. What the wave of agent washing does is conceal it for the first weeks of the project, until the demo stops being enough and the serious work has to start. At that point the team that built it understands that what it lacks is not more model power but architectural judgement the framework didn't provide and engineering discipline the demo didn't demand.
That 40% cancellation projection says less about the technology than about the organisations buying it. Those that build agents starting from the boring parts — in the right order — will reach production with systems that solve verifiable problems. The difference from the rest does not depend on which model is chosen or which platform is contracted. It depends on the technical judgement brought to the project from day zero, and that judgement still requires something the democratisation of tools does not provide: knowledge built through iteration. It is possible to get an agent running without robustness in an afternoon, but the consequences emerge after the demo in multiple forms. Building an agent system that is genuinely ready for production — robust and effective at scale — requires accumulated experience that no framework ships with. The tools got cheaper; the craft did not.