What counts as an AI agent use case in production?
An AI agent demos in days. It reaches production in quarters, and often never gets there: S&P Global found in 2025 that 46% of AI proofs of concept were abandoned before production. In large European enterprises, whether a project stays stuck at the pilot stage or reaches production is mostly decided early, when the use case is picked, long before any architecture question comes up.
An AI agent use case in production is a recurring business task an agent performs against real enterprise systems, with a named business owner, explicit human validation points and a readable trace of every action. Miss one of those conditions and the deployment is still a pilot, whatever volume it handles.
What changes when an agent goes live
The distinction is an operational one. It decides who signs off, who takes the call when the agent gets something wrong on a Friday evening, and which budget line pays for it next year. A pilot lives on innovation money. A production agent lives on the budget of the function it serves, and that transfer is where most projects stall.
In a large organisation, going live also triggers the checks a pilot usually sidestepped: a review by the CISO's team, identity and access management for the agent itself, a data protection impact assessment where the processing calls for one, and hand-over to IT support and change management. These are the checks that apply to any application writing to core systems, and an agent acting on an ERP or a CRM is one such application.
Which AI agent use cases actually reach production?
The ones that share a shape: a repetitive task with a known volume, an output a human checks faster than they could produce it, and data that is already accessible without a new integration programme. Across large enterprises, that shape shows up in the following families of work.
- High-volume document processing: contracts, supplier invoices, onboarding files, claims evidence. The agent reads, extracts, checks consistency and prepares the decision.
- Internal support and tier-one customer service: qualifying the request, searching procedures, drafting the reply, escalating as soon as the case leaves the expected pattern.
- Search and synthesis over internal corpora: legal, compliance, quality, R&D. The agent retrieves the relevant material and returns a sourced note the expert reviews.
- Software development and application maintenance support: reading legacy code, tests, documentation, preparing fixes on systems nobody remembers in full.
- Committee and case-file preparation: procurement, risk, credit, portfolio review. The agent assembles the material and surfaces the gaps, the human decides.
- Control and reconciliation: regulatory checks, reference data quality, discrepancies between two systems that should agree.
Tasks with that shape, in retail and in finance
In retail, for instance, an agent can handle delivery complaints from carrier tracking and customer history: it answers routine requests on its own, within the limits the company has set, and leaves an advisor to approve goodwill gestures beyond the rules or replies to unhappy customers. What makes this deployable is the structure of the work, and the same structure shows up in banking, manufacturing and public services.
Finance works the same way. An accounts payable reconciliation agent can clear on its own the invoices that match a purchase order and a goods receipt exactly, prepare a file for every exception and leave the finance team to rule on discrepancies above the threshold it has set. Volume is known in advance, and each proposed match takes a moment to check.
These families line up with what we see across AI agents in the enterprise. They are technically modest and, frankly, dull, which is what makes them industrialisable: volume is predictable, checking is quick and the scope barely moves from one month to the next.
Where development assistance and reconciliation need care
Development assistance scales fast but needs review discipline, or the agent quietly adds work downstream. Reconciliation looks trivial until you find that the two systems disagree by design, at which point the agent has surfaced an organisational argument. Someone then has to decide which system is the source of truth before the agent is allowed to correct anything.
What separates a use case that ships from one that stalls?
Sorting rests on criteria that can all be checked before the first line of code, in a workshop with the business and without a prototype.
Measured volume and output that is quick to check
The repetition is measured. If nobody knows how many times a month the task runs, or how many people run it, the agent runs on anecdotes. The investment committee, though, will ask for a denominator.
The output is faster to check than to produce. A synthesis note might be reviewed in a few minutes where writing it would take considerably longer. A cash-flow plan generated by an agent fails that test: checking it means redoing it. Use cases where control costs as much as production do not survive go-live.
Accessible data, reversible errors, a named owner
Data access is already settled. An agent that needs a reference dataset with no agreed owner triggers a data governance programme before it triggers an AI programme. That programme outlasts the sponsor's attention.
The cost of an error is bounded and reversible. A badly drafted proposal gets corrected. A payment already released is much harder to correct. Early production agents almost always work upstream of an irreversible action.
A business owner is named. A person, at the level where edge cases actually get decided. They approve the escalation rules and answer for the outcome. This is the criterion most often missing, and it cannot be retrofitted: at go-live, teams discover the use case belonged to the innovation group, which means to nobody.
Use the criteria as filters
A weighted grid, where each criterion is scored out of five, lets a spectacular use case offset a missing owner with a high estimated value, which is how ownerless projects make it all the way to the go-live committee and stall there. We recommend treating the criteria as knock-out filters: a criterion that is not met takes the use case off the shortlist until the business has fixed that point.
These filters are a first step the company can run on its own, before estimating the value of the remaining use cases. Prioritisation is a separate step: a flash audit such as Claude Ignite applies a six-criterion value/feasibility matrix to every opportunity identified, covering processed volume, data availability and governance risk among others, and keeps three to five for a roadmap with go/no-go decision points.
Why do the most impressive use cases fail to ship?
Because they were selected to convince a committee. The agent that negotiates and decides on its own, in place of an entire expertise, makes an excellent board demo. It then fails all five criteria at once: unknown volume, uncheckable output, scattered data, expensive errors, nobody accountable.
The MIT and Gartner figures, and how we read them
MIT put the share of generative AI pilots with no measurable P&L impact at 95% in 2025. Gartner, also in 2025, forecast that more than 40% of agentic AI projects would be cancelled by the end of 2027, because of escalating costs, unclear business value or inadequate risk controls. We read both figures as the same mechanism at work: a portfolio of impressive demos no business unit wants to carry on its own budget.
Start from a frequent, unglamorous task
The opposite approach is harder to sell to a committee, and it is the one we favour: start with the task nobody claims in meetings, the one that occupies several people for part of their week and whose output can be checked at a glance. A use case like that meets the criteria above more easily, and the measurements taken once it runs give a basis for choosing the next one.
Which selection mistakes stall a use case?
They come up from one steering committee to the next, and most are made before anyone writes code.
- Picking the use case from a vendor demo, run on clean data and a rehearsed script, without testing it against the work the function actually does.
- Confusing a task's value with its volume. A rare analysis done by an expert is worth a lot, yet it provides neither enough cases to evaluate the agent nor the repeated gain that will pay for running it.
- Underestimating review time. If the expert has to reread everything in detail because the output does not cite its sources, the gain disappears, and the team's buy-in goes with it.
- Handing ownership to the innovation team or to IT, who carry the project but cannot settle the business edge cases.
- Aiming for full automation on day one. An agent that starts by proposing, with systematic human approval, builds up the trace record that later justifies giving it more autonomy.
- Postponing the operating question: who monitors the agent, who updates its instructions, who answers when a user disputes a decision.
What has to be in place before an agent goes into production?
Oversight that exists before the incident. According to the 2026 edition of Deloitte's State of AI in the Enterprise report, only 21% of companies have mature governance of their AI agents. In our reading, that gap accounts for much of the time the last mile takes.
Trust zones, traceability and escalation rules
The starting kit is short. Trust zones, which define what the agent does alone, what it submits for approval and what it may never touch. Usable traceability, where every action can be traced back to its trigger, its context and its approver. Written escalation rules for the moment the agent leaves its perimeter. That is the purpose of our LOOP™ AI governance methodology. The EU AI Act, for its part, will require companies deploying high-risk systems to ensure human oversight and keep the logs those systems generate, which overlaps heavily with this kit. Regulation (EU) 2026/1744 (the Digital Omnibus on AI), in force since 27 July 2026, sets the deadlines at 2 December 2027 for stand-alone high-risk systems listed in Annex III, such as those used in recruitment or credit, and 2 August 2028 for AI embedded in regulated products under Annex I.
In LOOP™, classification happens action by action, so a single agent can sit in several zones depending on what it is about to do. In the green zone, above 90% confidence, the agent acts alone and everything is logged. The orange zone covers the 70 to 90% range: the agent proposes and a designated person approves before anything runs. Below 70%, the agent moves to the red zone, where it stops, documents what it is missing and alerts the designated owner, who must decide within four hours, with no automatic action in the meantime. The black zone holds everything outside the perimeter, with an immediate block and an alert to the CISO.
For the reconciliation agent described earlier, exact matches can sit in the green zone and exceptions above the threshold in the orange zone, while a suspicious payment, or a supplier whose bank details have just changed, belongs in the red zone. That split is written before development starts, because it sets the agent's technical permissions in the ERP.
Design oversight during scoping
All three components belong in the scoping phase. Adding traceability to an agent that is already running usually means rewriting it.
Written for one specific agent, they fit on a single page, with a name beside each. That is enough to start, and it spares the organisation a full governance programme ahead of the first agent.
Plan for operations after go-live
A production agent can change behaviour without anyone touching its code: a new model version, an updated business procedure, documents added to its knowledge base. Operating it means catching that drift before users do. In practice that takes a set of real cases replayed before every change, tracking of escalation rates and of the corrections approvers make, and a written procedure for suspending the agent without halting the business process.
This part is often missing from initial budgets. An agent industrialisation programme such as Claude Ops plans for it from the start, covering the path from technical audit to an agent in operation, application maintenance included.
How should you pick the first use case to industrialise?
Start from an inventory. List the recurring tasks in two or three functions, keep those with documented volume, drop those whose output cannot be checked quickly, then look at which ones already have a business owner willing to commit. The resulting list is short, and the first use case is chosen from those candidates.
Count the volume and question the future owner
Two habits help here. Write the volume down before anyone argues about technology, because a task nobody has counted will not survive an investment committee. Then ask the prospective owner what they would do on the day the agent gets it wrong. A vague answer means the use case is not ready, whatever the demo showed.
Run in shadow mode, then widen step by step
Once the use case is chosen, go-live works best in stages. The agent first runs in shadow mode: it handles real cases, its outputs are compared with the team's work without being used, and the gaps help tune its instructions. Part of the flow is then opened up, with human approval of every output, and the green zone is widened as the trace record builds. The success criterion is set before the first stage, otherwise each stakeholder ends up redefining it to suit their own view.
Place the organisation before scoping
Before that work, our AI maturity assessment places the organisation on the Koneetiv framework (2026 edition) in eight questions and about three minutes. It returns a score, a radar across the framework's six axes and a prioritised action plan, and its questions cover use-case identification, data and agent governance, among other topics. A low score on the data axis or the governance axis points to the use cases the organisation cannot yet operate.
The blog's AI agents in production category takes the choice further into architecture: computer use versus APIs, and lock-in to a single model.