Agentic AI in Production: Beyond the Pilot
Agentic AI demos beautifully and ships rarely. Gartner expects over 40% of agentic AI projects to be cancelled by 2027. A practitioner's view of what production-grade agentic AI takes, where it pays off, and how to get one from demo to real users without it becoming an incident.

Agentic AI demos beautifully and ships rarely. That single sentence captures the state of the field in mid-2026 better than any forecast. The demos are everywhere: an agent that books the travel, triages the tickets, writes and runs the code, closes the books. The production systems are far fewer, and the gap between the two is where most agentic AI budgets quietly die. This piece is about crossing it. Not what an agent is, which is settled elsewhere, but the harder question of why agentic AI stalls before production, what production-grade actually requires, where an agent earns its keep versus where it just looks impressive, and how to get one from a slick demo to something real users depend on. We build and ship these systems for a living, so this is the practitioner's view, written for the person who has to decide whether the next phase is worth funding.
What "agentic AI in production" means
An AI agent is a language model placed in a loop, given tools it can call and a goal to work toward, deciding its own steps until the goal is met. That one sentence is the whole definition this article needs. The interesting part here is not what an agent is, but what changes when you ask one to leave the demo and do real work for real users.
Agentic AI in production means that loop is running against live systems, on inputs nobody hand-picked, with consequences attached. The production bar is steep and specific. The agent has to handle the inputs you did not anticipate, not just the ones from the demo. It has to stay inside a cost and latency budget, because at real volume token spend and response time stop being rounding errors. It has to log what it did, so a human can reconstruct any run. It has to fail safely, degrading to a sensible fallback instead of doing something destructive. And it has to keep a person able to step in on anything that matters.
A demo is graded on whether the agent can succeed once, on a path you chose, in front of a friendly audience. Production is graded on whether it succeeds acceptably every time, on paths it has never seen, in front of people who will be annoyed or harmed when it is wrong. Those are different things, and the second is a far larger piece of engineering than the first.
A demo proves an agent can do the task once. Production proves it does the task safely, at a cost you can live with, every single time. Almost all the work, and almost all the risk, lives in the distance between those two sentences.
This is the agentic version of a problem that runs through all applied AI. The general case, why pilots of every kind stall before production, is the subject of our pillar on AI implementation from pilot to production. Agentic AI is the hardest instance of it, because an agent acts. A model that only answers can be wrong on a screen. An agent that is wrong has already called the tool, sent the message, or changed the record. The autonomy that makes agentic AI valuable is exactly what raises the production bar.
Why most agentic AI stalls before production
Most agentic AI stalls for the same reason most software demos do not become products: the demo is the easy 20% and the team budgets as if it were the hard 80%. With agents the trap is sharper, because a working agent demo is genuinely dazzling, and dazzle is a poor proxy for done.
The numbers are blunt about it. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, driven by escalating costs, unclear business value, and inadequate risk controls. The same analysis is sharp about why: most current agentic projects are early-stage experiments and proofs of concept driven by hype and often misapplied, which blinds organizations to the real cost and complexity of running agents at scale. Gartner also flags how much of the market is "agent washing," existing chatbots, assistants, and robotic process automation rebranded as agentic, estimating that only about 130 of the thousands of self-described agentic AI vendors are real. A lot of what gets piloted was never genuinely agentic to begin with.
The pattern holds beyond agents specifically. McKinsey's 2025 State of AI survey found that while 88% of organizations now use AI in at least one function, only about 23% report scaling an agentic AI system anywhere in the enterprise, with most still experimenting or piloting. And MIT's NANDA initiative, in its GenAI Divide report, found that 95% of enterprise generative AI pilots delivered no measurable impact on the bottom line. Different researchers, different methods, one consistent shape: building an AI demo is now trivial, and getting AI to production is still genuinely hard.
When agentic projects die, they tend to die in recognizable ways, and almost none of them are about the model being insufficiently smart.
- An agent where a workflow would do. The single most expensive mistake. The task was a fixed sequence of steps, and a deterministic pipeline would have run it for a fraction of the cost with none of the surprises. Handing it to an agent bought unpredictability nobody needed. The more freedom you give a model over its own path, the more capable and the more unpredictable the system gets, and not every task wants that trade.
- No evaluation, so no idea if it works. The team judged the agent by watching it succeed in a meeting. There was no test set, no quality criteria, no way to tell whether a prompt change made it better or worse. You cannot ship what you cannot measure, and you cannot improve it either.
- Guardrails treated as a later phase. The agent had real tools and few limits on steps, spend, or permissions. Then it looped, overspent, or touched something it should not have, and the project halted to retrofit controls that should have been there from the start.
- Autonomy dialed past what the task tolerates. The team gave the agent maximum freedom because the demo looked better that way, and inherited maximum unpredictability. The most reliable production agents are rarely the most autonomous ones.
- Cost discovered late. A multi-step agent making many model calls per task is a different cost profile than a single prompt. At real volume the bill arrives, and a project justified on a demo's economics no longer pencils out.
Notice what is missing from that list. "The model could not do it" is rarely the binding constraint. Models have been capable enough for a wide range of agentic work for a while. Projects stall on the engineering and judgment around the model: whether an agent was even the right tool, whether anyone could measure it, and whether the guardrails were built before the incident rather than after.
What production-grade agentic AI requires
Production-grade agentic AI rests on four things that demos are designed to skip: evaluation, observability, guardrails, and human-in-the-loop control. Each one is the difference between a system you can trust at scale and a demo you can only trust in the room. None is optional once an agent can touch real systems.
| Requirement | What it covers | Why a demo skips it |
|---|---|---|
| Evaluation | A test set of real tasks, quality criteria, regression checks | A human watching it succeed once feels like proof |
| Observability | Tracing of every step, tool call, cost, latency, and outcome | The demo ran once and someone watched it happen |
| Guardrails | Limits on steps, spend, permissions; input and output validation | Nothing bad happened in the controlled run |
| Human-in-the-loop | Approval on high-stakes or irreversible actions | The stakes were fake, so no approval was needed |
Evaluation. A demo is judged by a person watching the agent win once. A production agent needs a way to answer "is this output good?" automatically, repeatedly, and at scale, because nobody can eyeball every run. That means a test set of real tasks, defined quality criteria, and a harness that flags regressions when you change a prompt, a model, or a tool. Evaluating agents is harder than evaluating a single model call, because the agent took a path, and the path can be wrong even when the final answer looks right. Teams that skip this are tuning by vibes and find out the system degraded when a customer complains. Evaluation is what lets an agent graduate from pilot to production at all.
Observability. When an agent runs ten steps and calls five tools to finish a task, "it gave a bad answer" is not a debuggable report. You need a trace: every step the model took, every tool it called with what arguments, what came back, what it cost, how long it took. Without that, a failure in production is a mystery and a slow quality drift is invisible until it is a crisis. Observability is also how you control cost, because the trace is where you see the agent taking eleven steps for a job that needed three. This is ordinary production discipline applied to a system whose control flow the model decides at runtime, which makes the tracing more important, not less.
Guardrails. The moment an agent has real tools, it can spend money, mutate data, and call external services in a loop you did not fully script. Guardrails bound that. You cap the number of steps so a confused agent cannot run forever. You cap spend. You scope every credential to the minimum the task needs. You validate the arguments going into a tool and sanity-check what comes back. You decide which actions an agent may take on its own and which it may not. An agent with powerful tools and no guardrails is not a feature, it's an incident waiting for a trigger.
Human-in-the-loop. The most reliable production agents keep a person on the high-stakes actions. Not every action, which would defeat the point, but the ones that are expensive or impossible to undo: moving money, deleting records, sending the irreversible message, changing a permission. The agent does the work and proposes the action; a human approves the ones that matter. This is the control that lets you deploy an agent into consequential work without betting the business on the model never being confidently wrong.
These four are not a maturity ladder you climb later. They are the design of a system that can be trusted in production, and the cheapest time to build them is alongside the agent, not after the first incident forces the issue. Standing each one up is most of what our AI agent development practice actually does, because the loop is the easy part and the four pillars around it are the job.
Where agentic AI earns its keep in production
Agentic AI earns its keep on tasks that are genuinely multi-step, tolerate some variance in how they get done, and have a clear definition of done the system can check itself against. It does not earn its keep where a fixed workflow is cheaper and more reliable, where one wrong move is catastrophic and irreversible, or where nothing can verify the output. That single distinction predicts most of the value and most of the wasted spend in the field.
Where agentic AI reliably pays off in production today:
- Support triage and resolution. Pulling account context, checking policy, drafting a reply, taking the routine action, and escalating when unsure. The task is multi-step, the variance is tolerable, and a wrong draft is cheap to catch because a human or a check sits before the customer. We go deeper on this in our look at how AI is reshaping customer support.
- Research and synthesis. Gathering from many sources, cross-checking, and producing a structured summary with citations. There is real intermediate structure, the cost of a wrong step is recoverable, and the output is checkable against the sources.
- Data pulls and reporting. Querying systems, joining results, and assembling a report a person would otherwise stitch by hand. The work is legible, repetitive, and verifiable, which is exactly where an agent is strong.
- Operations with a verification step. Reconciliation, monitoring with triage, the long-tail back-office work that has clear inputs, clear success criteria, and a check the agent can run. When "done" is expressible as a test, the loop has something to close on.
Where agentic AI does not pay off, and where reaching for it is the mistake:
- Fixed, deterministic sequences. If the task is always the same steps in the same order, a workflow runs it cheaper, faster, and without the unpredictability an agent adds. Using an agent here pays for autonomy you did not need and inherits failure modes you could have avoided.
- Single irreversible high-stakes actions. Where one wrong move cannot be undone and the cost is severe, the loop's tolerance for mistakes breaks the premise. These belong behind deterministic logic and human approval, not agent autonomy.
- Tasks with no checkable output. If you cannot express success as a test, a comparison, or a measurable outcome, the agent has nothing to verify against and you have no way to know it worked. No check means no safe production agent.
The thread is the same one that runs through all of applied AI: match the tool to the task. An agent is the right answer when the work is multi-step, the cost of a wrong step is recoverable, and you can verify the result. When those do not hold, a narrower and more deterministic system is usually safer, cheaper, and easier to defend. The teams getting value are not the ones putting an agent on everything. They are the ones who know which half of the work actually wants one.
From demo to production: a playbook
There is no sequence that guarantees an agentic system ships, but there is a shape that works far more often than the common alternative, which is to wire up an impressive demo and try to scale it. The teams who reach production tend to move through the same stages, treating each as a gate rather than a box to tick.
- Frame a narrow problem and confirm an agent is the right tool. Start from a specific, painful job and the measurable outcome that would count as success. Then ask the question most projects skip: does this actually need an agent, or would a fixed workflow do it better? Reserve agentic AI for the multi-step, variance-tolerant, verifiable work where autonomy earns its cost. Getting this gate wrong is how a project ends up cancelled with a slick demo and no value, which is precisely the outcome Gartner is forecasting for more than 40% of them.
- Build the pilot with evaluation attached from day one. Build the demo, but build it like you mean to keep it. Pick one narrow use case, and wire in a real test set and quality criteria from the start, judging the pilot on measured output quality rather than on whether it looked good in a meeting. A pilot with evaluation already attached can graduate. A pilot without it has to be half-rebuilt before it can ship.
- Add observability and guardrails in parallel with integration. As the approach proves out, connect the agent to the real systems and stand up the controls at the same time: tracing on every step and tool call, caps on steps and spend, scoped permissions, and approval gates on high-stakes actions. The same discipline as any AI integration into an existing product, with the extra weight an autonomous actor demands. Bolting these on after the fact is slow and usually forces rework.
- Launch to a limited slice with a human in the loop. Do not flip it on for everyone. Release to a small, real group of users, watch the traces closely, and keep a person on the actions that matter. A limited launch surfaces the failure modes the pilot could not, while the blast radius is still small and cheap to contain.
- Monitor traces, quality, and cost. Production is the start of the work, not the end. Track output quality, cost per task, latency, and where the agent is spending its steps. Feed real failures back into the evaluation set so the system improves instead of quietly drifting. The trace is where you catch the agent burning ten steps on a three-step job before the bill or a bad answer catches you.
- Expand from a base that works. Once one use case is genuinely in production and measured, widen the scope from there. The instinct to go broad early, to make the agent do everything in one move, is the instinct that produces the cancelled projects. Earn each increment of scope and autonomy from a working, instrumented base.
The thread through every stage is restraint. Confirm an agent is the right tool, prove value on one narrow thing, instrument it so you know whether it works, keep it only as autonomous as the task tolerates, and expand from there. This is the same judgment our engineers apply on the build side when they work with agents in the loop on real code: hand the agent the work where it is cheap to be wrong, keep the rigor exactly where being wrong is expensive, and never confuse a fast demo with a finished system.
Agentic AI in regulated production
In regulated work, the question is not whether you can run agentic AI in production. You can. The question is how, and the answer is that the guardrails get tighter, not looser, and the speed comes from the agent drafting while the compliance comes from a gate that does not move. This is where agentic AI stops being a marketing line and becomes something you can defend in an audit.
The principle is simple. The agent accelerates the work, and the controls that make the work compliant sit exactly where they always did. An agent operating near payments, personal data, or anything irreversible drafts and proposes; the consequential action still passes human approval, still runs through the checks the domain demands, and still leaves an auditable trail of what the agent did and why. The agent makes the first move faster. It does not get to be the thing that vouched for the outcome.
Three adjustments carry the weight when the stakes are regulatory rather than just functional. Scope the agent's permissions to the narrowest set of actions the task needs, so the blast radius is bounded by design rather than by hoping the model behaves. Keep irreversible and high-stakes actions behind a person, because the loop is safe precisely because it re-runs cheaply, and anything that cannot be cheaply undone needs a hand on the switch. And never let the agent be the only thing that signed off, because the trail of why, the logs, the approvals, the evaluation that pins the behavior, is what makes the system maintainable and auditable years later.
This is how we work. We have built production software where the bar is high: an eIDAS-qualified e-signature platform, a digital-banking platform, supply-chain systems carrying real money and real liability. Agentic methods hold up in that work because the gate holds up. The agent shortens the drafting and iterating; the controls at the boundary stay exactly as rigorous, which is the only version of AI-native delivery that survives contact with a regulated domain. It is also the operating model we are compounding toward 2028: AI-accelerated delivery clients can feel, with the discipline serious work demands kept fully intact.
The reason all of this matters beyond compliance is that it's the honest answer to the whole agentic AI question. The technology is real and the capability is not a lie, and the failures, the cancelled projects, the cost overruns, the agents that thrash or do something nobody intended, are just as real. The teams that come out ahead are not the ones who hand the most to agents or the least. They are the ones who put agents only where the work is multi-step and checkable, build the evaluation and observability and guardrails before the incident, and keep a person on anything that matters. That judgment is the entire difference between an agentic AI demo and agentic AI in production, and production is the only place it pays off. Where a single implementation fits a wider plan is the subject of building an enterprise AI strategy, and how you justify the spend is the subject of measuring AI ROI honestly; both apply with extra force to agents, because agents cost more to run and more to get wrong.
Frequently asked questions
Agentic AI in production means an AI agent, a language model running in a loop with tools and a goal, is doing real work for real users inside live systems, not impressing people in a demo. The production bar is high: it has to work reliably across inputs nobody scripted, stay inside cost and latency budgets, log what it did, fail safely, and keep a human able to intervene on anything that matters. A demo proves an agent can succeed once. Production requires it to succeed acceptably every time, which is a different and much larger piece of engineering.
Most stall because the demo is easy and the production system is hard, and teams budget as if the demo were nearly done. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. The usual causes are agentic AI applied where a fixed workflow would have been cheaper and safer, no evaluation to prove the agent works, weak guardrails, and a model handed more autonomy than the task can tolerate. The model is rarely the binding constraint.
Four things that demos skip. Evaluation: a test set of real tasks and quality criteria so you can prove the agent works and catch regressions, not just watch it succeed once. Observability: tracing of every step, tool call, cost, and outcome so you can debug a run and see quality drift before users do. Guardrails: limits on steps, spend, and permissions, plus validation on what the agent can touch and do. And human-in-the-loop control on high-stakes or irreversible actions. Without these an agent with real tools is a process that can spend money and change data in a loop you did not fully predict.
Agentic AI pays off on tasks that are genuinely multi-step, tolerate some variance in approach, and have a clear, checkable definition of done: support triage and resolution, research and synthesis, data pulls and reporting, and operations work with a verification step. It does not pay off where a fixed workflow does the job cheaper and more reliably, where one wrong move is catastrophic and irreversible, or where there is no way to check whether the output is right. Reaching for an agent when a deterministic pipeline would do is one of the most common and expensive mistakes.
Frame a real, narrow problem with a measurable outcome before choosing an agent. Build the pilot with evaluation attached from day one so it can graduate instead of needing a rebuild. Add observability and guardrails in parallel with integration, not after. Launch to a small slice of real users with a human in the loop, watch the traces, and expand from a base that works. Throughout, keep the agent only as autonomous as the task tolerates: more freedom means more capability and more unpredictability, so you earn each increment rather than starting at maximum.
Yes, with guardrails tightened, not loosened. The agent accelerates the work, but every consequential action still passes the controls the domain demands: scoped permissions, human approval on irreversible or high-stakes steps, full logging of what the agent did and why, and an auditable trail. In regulated work you constrain the agent to the narrowest set of actions the task needs, keep money-moving and data-changing steps behind a person, and never let the agent be the only thing that vouched for an outcome. The speed comes from the agent drafting and iterating; the compliance comes from a gate that does not move.
More from the journal

Model Context Protocol (MCP) for Developers
The Model Context Protocol is an open standard for connecting AI applications to your data and tools. A practitioner's guide to how MCP works, the host-client-server model, its tools, resources, and prompts, building an MCP server, and the security part most demos skip.

Agentic Coding: Building Software With AI Agents in the Loop
Agentic coding is directing an AI agent through real engineering work: it plans, acts, and checks itself in a loop while you set direction and review. A grounded guide to how the loop runs, where agents earn their keep, where they thrash, and the guardrails that keep it safe.

Vibe Coding: A Practitioner's Guide to Shipping With AI
Vibe coding is describing what you want in plain language and letting an AI write the code. A grounded guide to the workflow, where it breaks on security and maintainability, and how senior teams ship with it without shipping garbage.