--- title: "Why most enterprise AI agents never leave the demo" description: "Enterprise AI agents fail between demo and production for organisational reasons, not model reasons. The three gaps they die in, and what closes each one." type: Essay url: https://sunilkumar.ai/writing/why-most-enterprise-ai-agents-never-leave-the-demo/ author: Sunil Kumar (https://sunilkumar.ai/about/) datePublished: 2026-09-02 pillar: Architecture tags: [production, refusals, cost, audit, evaluation] license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) --- # Why most enterprise AI agents never leave the demo Enterprise AI agents fail between demo and production for organisational reasons, not model reasons. The three gaps they die in, and what closes each one. ## In short - A demo proves the model can do the task. Production proves the organisation can live with the agent doing it every day. - Agent projects die in three gaps, accountability, cost and audit, and none of them is a model problem. - The demo wins because it controls the input. Production loses because it does not, and nobody wrote down what the agent must refuse. - Close the gaps before the first line of orchestration code by writing the refusal list, the run budget and the name of the owner. Every enterprise I talk to has an agent demo. A model reads a claim, checks three systems, drafts a decision and a polite email, and the room goes quiet. Six months later most of those demos are still demos. Some became pilots. Very few are doing real work, unattended, with someone accountable for them. This essay is about the gap between the first meeting and the last one, and why the model is almost never the reason a project falls into it. ## Why do demos succeed? Because the demo controls the input. The presenter picked the claim. The three systems were reachable and the data in them was clean. The email went to a mailbox nobody reads. The model did the task, and doing the task is what a model is good at. Production controls nothing. The input is whatever arrives. One system is down for maintenance. The customer record has two addresses. The email goes to a real person who replies. Every one of those is an ordinary Tuesday for the software your company already runs, and your company has spent years building the habits that absorb them: on-call, runbooks, budgets, audit logs. An agent arrives without any of those habits attached, and the demo hides that, because in the demo nothing goes wrong. > **Demo-to-production gap**: The set of organisational decisions, about who owns an agent, what it may cost and how its runs are audited, that a working demo does not require and a production deployment cannot proceed without. ## The first gap: who owns the failure? Ask the room who gets paged when the agent sends the wrong email. In most demos nobody can answer, because the question was never in scope. The engineering team built it. The business sponsor wanted it. The vendor sold the model. None of them owns the outcome the way the head of payments owns the payments system. This is the gap most projects die in, and it dies quietly. An agent with no owner has nobody to argue for it when the first embarrassing output appears, and the first embarrassing output always appears. The pilot is paused "while we review", and the review never ends. The fix is unglamorous. Before the agent touches a real system, one named person accepts that they own it: they can switch it off in under a minute, they receive the alerts, and they sign the change that puts it live. If nobody will accept that, the project is not ready, and no amount of model improvement will make it ready. ## The second gap: what does a run cost? A demo runs once. Production runs ten thousand times a day, and every run has a price: model tokens, tool calls, retries, the human minutes spent on the cases it escalates. Almost no demo comes with a number for that, because a demo is priced in engineer weeks, not in runs. I have watched teams discover the number at the end of the first full month, when the bill arrives and the sponsor sees the invoice next to the value the agent produced. If the value is not obviously larger, the project ends there. The agent was working. It was just not worth it at that price, and nobody had asked. The fix is to price a run before you build the agent. Not precisely; a range is fine. Then write down the budget for the month and the action the system takes when the budget is hit. An agent that stops when it runs out of money is a production system. An agent that keeps going is a surprise waiting for a finance team. The design decisions follow from the number. If a run may cost a few cents, you route most cases to a small model and reserve the large one for the hard ten percent. If a run may cost a dollar, you can afford a second model to check the first. If a run may cost ten dollars, you are probably replacing a person, and the budget conversation becomes a hiring conversation. All of those are fine. Not having the conversation is not. ## The third gap: can anyone reconstruct what happened? The third question comes from compliance, risk or internal audit, and it is the simplest: show me why the agent did that. Not the prompt. The run. What came in, what the model saw, what it decided, which tools it called with what arguments, what came back, and what went out. Most demos cannot answer, because they log the output and nothing else. That is enough to debug a demo. It is not enough to defend a decision to a regulator, a customer or a court. If your industry is regulated, and healthcare, finance and government all are, this gap is not a delay, it is a wall. The fix is a trace per run, kept for as long as the decision matters, readable by a person who did not build the system. It is the least interesting engineering on the project, and it is the piece that turns a pilot into something the compliance team can say yes to. The regulators are explicit about this. The EU AI Act asks for logging and traceability for high-risk systems ([Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)), and the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) puts "measure" and "manage" alongside "map" for a reason: you cannot manage what you cannot reconstruct. If a run cannot be replayed from its trace, the trace is not an audit log. It is a diary. ## Why the model is rarely the problem Notice that none of the three gaps mentions the model. That is deliberate. The model is the part of the system that gets better every quarter without your help, and it is the easiest part to swap. Owner, budget and trace do not improve on their own, and they do not care which model you use. There is a version of this essay that blames hallucination, latency or cost per token. Those are real, and the architecture playbook deals with them. But in the post-mortems I have been part of, the model was blamed and one of the three gaps was the cause. The model produced a bad output; the project died because nobody owned the response to it. The model was expensive; the project died because nobody had agreed what it was worth. The model made a defensible decision; the project died because nobody could show the reasoning to the person who asked. ## What closes the gaps Write three things down before the first line of orchestration code. The refusal list. What the agent must never do, and what requests it must decline. Enforced in code, at the tool layer, not asked for in the prompt. This is what gives the owner the confidence to say yes, because it bounds what "wrong" can mean. The budget. Cost per run as a range, cost per month as a ceiling, and the behaviour at the ceiling. This is what gives the sponsor a number to compare against value. The owner. A name, a kill switch, an alert channel. This is what gives everyone else permission to stop arguing. At Ailoitte we do this in the first two weeks of an engagement, before we commit to a price, because the three documents are what make a fixed price possible. But the practice does not depend on how you buy the work. It depends on whether you are willing to decide these things early, when they are cheap, instead of late, when they are fatal. ## Two objections, answered "Our vendor handles all of this." Some do. Ask them to show you the trace, the budget ceiling and the name of the person on your side who can switch the agent off. If the answer to the third question is someone at the vendor, the agent is theirs and the accountability gap is still open; it has just moved to a contract. The [vendor evaluation playbook](/playbooks/how-to-evaluate-an-agentic-ai-vendor/) has the full list of questions, and a good vendor will welcome them, because the answers are what let them quote a fixed price. "We are not regulated, so the audit gap does not apply." Every company is regulated by its customers. The first time an agent gives a customer a wrong answer with money attached, someone will ask why, and "the model decided" will not satisfy them. The trace is not for the regulator. It is for the Tuesday afternoon when a good customer is angry and you need to know what happened in thirty seconds, not in a three-day investigation. There is a third objection I hear less often but take more seriously: "this is a lot of process for a pilot". It is. The answer is to make the pilot smaller, not the process. One task, one team, one owner, a real budget and a real trace, is a production system with a small blast radius. Twenty tasks with none of those is a demo with a large one. ## If you are doing this in your company Take your current agent pilot and ask the three questions in a meeting with the sponsor, the engineering lead and someone from risk. Who is paged? What does a run cost, and what happens at the monthly ceiling? Show me a run. If all three have answers, you have a production system that happens to be called a pilot; ship it. If any of them does not, you have found the real project. It is smaller than the one you thought you had, and it is the one that decides whether the agent ever does real work. The follow-up to this essay, [what "production-grade" actually means for an AI agent](/writing/what-production-grade-actually-means-for-an-ai-agent/), turns the three answers into tests you can run. The [reference architecture playbook](/playbooks/agentic-ai-reference-architecture-for-enterprise/) shows where each one lives in the system. --- Sunil Kumar, Co-founder and CEO, Ailoitte Technologies. https://sunilkumar.ai/about/