Pilot purgatory is the state of a company that keeps running AI proofs of concept without moving any of them into production. The demos win over the executive committee, then nothing follows, because no one has named a sponsor, costed the business case, prepared the data or set the decision criteria before launch.
Several studies measure the problem. According to S&P Global (2025), 46% of AI proofs of concept are abandoned before they reach production, and MIT (2025) observes that 95% of generative AI pilots have no measurable impact on the P&L. Turning a pilot into an AI agent in production means settling, in the right order, the questions of sponsorship, budget, data and risk.
Where the widely quoted 87% figure comes from
A figure often quoted about failed AI projects says that 87% of them never reach production. The earliest written trace found is a VentureBeat partner article published on 19 July 2019, which revisited a panel from the Transform conference, held in San Francisco on 10 and 11 July, with IBM's CTO for data science and AI among the speakers. The article puts the figure forward without tying it to any study, and it was about data science projects, years before agents and generative AI.
Recent studies look at other things. Deloitte's State of AI in the Enterprise (2026 edition) finds that only 21% of companies have a mature governance model for their agents, and Gartner (2025) expects more than 40% of agentic AI projects to be cancelled by the end of 2027. These measurements cover governance and the cancellation of agentic projects, and none of them repeats or validates the 87% figure.
Foundation models such as Claude, GPT and Gemini are mature enough to deliver operational results, agentic frameworks exist and the APIs hold up under load, so the gap between POC and production comes down to the organisation. The shift from chatbot to AI agent makes that gap more visible, because an agent acts directly inside your systems and commits the company with every action.
Why AI projects stay stuck at the pilot stage
No governance framework to make the call
Without a formal framework that says which AI use cases to deploy, which ones to block and how much risk is acceptable, each POC becomes an isolated debate: IT holds back out of caution, the business pushes without guardrails, and the project dies in committee. An enterprise AI governance framework written before the first pilots saves you from replaying that debate on every project.
Vague sponsorship and diffuse accountability
Who owns the project? Who decides when it goes to production? Who answers for a mistake made by the agent? As long as these roles stay implicit, the executive team gets excited, IT experiments, the business watches, and nobody carries the move to production with a mandate and a budget.
A business case with no measured starting cost
"We're testing AI" states an intention with no target attached. A business case is built from a measured, documented operating cost: the time an analyst spends on a repetitive task, the cost of a support ticket, the processing time of an invoice. Without that baseline no ROI can be calculated, and without demonstrated ROI nobody signs off the investment that production requires.
Poorly prepared data
When a POC runs on a clean sample chosen for the demo, production then exposes the agent to the reality of your data: heterogeneous sources, badly scanned documents, business rules nobody ever wrote down. An agent that looked highly reliable on the sample can lose a good deal of accuracy on real cases, which is why that measurement should be planned from the start.
What to put in place before the first POC
To get out of pilot purgatory, it pays to settle before the first POC the questions that would otherwise surface at the end. On top of the conditions detailed further down, the following framework is put in place from day one:
- A governance framework with use case classification by risk level
- Continuous monitoring of deployed agents, on dashboards that track performance and cost
The POC as a controlled test on the way to production
A POC exists to validate a hypothesis under controlled conditions. If it is tied to no production plan, with a budget and a decision committee, it will remain a demonstration, however successful.
The path to production: scoping, governance, deployment, monitoring
The method Koneetiv applies runs through these steps in this order, and each one ends with a written decision taken by the person who holds the mandate.
Scope the use cases and the business case
Scoping starts from business processes and available data, security constraints included. With Claude Ignite, a flash audit leads to a matrix that scores every use case on value, feasibility and estimated ROI, then keeps the three to five priority cases, each with a quantified business case and a roadmap punctuated by go/no-go milestones.
The best candidates are high-volume tasks with known rules and a measurable cost. Our overview of AI agent use cases that actually reach production helps you spot them, and the starting cost is later used to judge the pilot.
Classify every agent action in the trust zones
Before the POC starts, each action the agent will be able to take is placed in one of the 4 LOOP™ trust zones: green for autonomous execution, orange when a human validates before the action, red when escalation is mandatory, black for anything out of bounds. Done at this stage, the classification avoids discovering at the end of the process that a key action falls in the red zone and cannot be automated as it stands.
The Koneetiv method also uses this step to name the sponsor, set service levels and open the agent's registry, where LOOP™ records the people responsible, the authorised actions and the escalation rules.
Deploy on a controlled scope
The agent is built, tested on real data, integrated with your systems and put into production on a narrow scope: one ticket type, one supplier or one channel. During the first days a human validates every decision, and the gap between what the agent proposes and what the business would have decided is measured case by case. Expansion then happens in stages, with a measurement at each stage and a committee decision before the next one opens.
The test set is prepared alongside the agent. It is built with the business, mixes routine cases with difficult ones (unreadable documents, ambiguous requests, attempts to get around the rules) and then serves as the benchmark for every change to the prompt or the model. The Claude Ops programme covers this deployment from the technical audit through to the maintenance of the agent in production.
Monitor decisions continuously
Once the agent is live, supervision tracks its decisions, exceptions and drift, and the registry stays up to date. The classification then evolves with the results: LOOP™ thresholds are versioned in the registry, escalation rules are validated by the CISO, and the zones are adjusted at the monthly governance review, for instance to give autonomy back to an action that has stayed reliable or to put another one back under human validation after an incident, and every modification is traced.
How Koneetiv helps companies leave pilot purgatory
The engagement relies on a team and a tooled method, with a committed business sponsor on the client side. Koneetiv, an official Anthropic partner, builds on standardised agent modules and applies LOOP™ governance from the scoping stage, so the integration and supervision components do not have to be rebuilt for each project.
The agent library shows what a narrow scope looks like through concrete demos: accounts payable and receivable automation in finance, clause analysis in legal, onboarding and employee questions in HR, ticketing and incident handling for IT. Each demo starts from one precise task, which makes it a useful starting point for discussing your own first use case.
Other articles in our AI agents in production section cover agent architecture and use case selection.
The conditions to check before launching a POC
Before a POC is launched, the conditions below should be in place, and all of them can be checked during scoping, before the first line of code is written.
A named executive sponsor
A sponsor is designated by name, with a dated mandate. "Finance" describes a department, whereas "the CFO, mandated by the executive committee on 12 March to own the project" designates a person who will settle trade-offs and answer for them to senior management.
A measured baseline
Before deployment, you need to know how long the task takes, how many errors it produces and what it costs per unit. These numbers are the benchmark for the pilot and the basis for the go-live decision. The baseline is built on a representative sample of cases, measuring the work as it is actually done, exceptions included.
A success threshold set before the POC
The performance level that triggers go-live is decided at the start: a minimum accuracy rate, a processing time, a maximum share of escalated cases or a target unit cost. That threshold is written down before the POC, otherwise the debate turns subjective when it is time to conclude and the decision drifts from one committee to the next.
A go/no-go committee
You need an identified body that meets on fixed dates and decides. It reviews results on the test set, the escalation rate, the incidents raised and the CISO's opinion, then chooses between go, no-go and a reduced scope. Without this committee, a POC risks drifting from meeting to meeting for months.
An integration budget committed upfront
The integration budget is identified and reserved before the pilot starts, just like the POC budget. Without that reserve, a successful pilot may stall just when it should go live, for lack of a budget line covering systems integration, security and monitoring.
Traps to anticipate at the production transition
Even with sound scoping, the move to production can fail at the last moment, and these traps are worth anticipating from the start:
- The production data trap: the POC ran on a clean sample and reality is messier. The fix is to test on real data from the first weeks of the POC.
- The exceptions trap: the agent handles the vast majority of cases correctly, while the remaining minority becomes unmanageable because no route was planned for it. The fix is a human escalation strategy designed from the start.
- The security trap: the CISO discovers the project at the end and blocks it. Bring security in from scoping, together with the EU AI Act obligations that apply to the use case.
- The business resistance trap: users reject an agent they were never consulted about. Involve them from the first iteration, especially in building the test set.
- The missing monitoring trap: the agent is live and nobody watches its decisions. Supervision and the registry must be in place before go-live.
Koneetiv adds one last check before go-live: a team deliberately tries to derail the agent with trapped documents, out-of-scope requests and prompt injection attempts, and each weakness found becomes a blocking rule recorded in the registry before users get access.
The principles behind the Koneetiv method
These working principles apply from the very first meeting.
Start with the cost of the task
The first meeting is about costing the task as it runs today, before any architecture question. That number becomes the reference for everything that follows, from the choice of scope to the success threshold the committee will review.
Narrow the scope before widening it
A first agent takes on a single, well-defined task. Aim for "an agent that pre-qualifies level-1 billing tickets" rather than "an agent that manages the entire customer relationship": the first can be measured, corrected and then repeated in other categories, whereas the second offers no verifiable success criterion.
To see where your organisation stands before your next committee, the free AI maturity assessment gives you, in a few minutes, a score out of 100, a six-axis radar and an action plan to move from POC to production.