There is a moment in almost every agent project where the room goes quiet in a good way. The agent reads the document, calls the system, writes the record, and everyone can see it work.
That moment is worth having. It is also the least representative run the agent will ever make. A demo is one case somebody chose, with a person watching. Production is every case that arrives, including the awkward ones, long after the room has emptied.
Building the agent has become easier because the tooling has improved. The difficulty moved. It did not disappear.
Why does a pilot succeed and a programme stall?
Gartner expects over 40 percent of agentic AI projects to be cancelled by the end of 2027. Its headline reasons are escalating costs, unclear business value, and inadequate risk controls. Capability and use-case fit still matter. The point is that capability alone does not carry a working agent into production.
The 2025 DORA research reached a similar conclusion in software delivery: AI amplifies the system around it. Strong workflows, platforms and feedback loops improve its effect. Weak ones become more visible.
A pilot answers one question: can the agent do this once? Production asks four others. Does the work still hold next month? What does it cost across the real case mix? Who is accountable when it is wrong? Can you reconstruct what it did and why?
We wrote about what an agent actually is and made the same point about its anatomy: the model is one component, and the layers around it make the work usable. This article is about the next layer. Not what an agent is made of, but what it takes to run AI agents in production.
What breaks after the demo?
Three things tend to surface after launch: work that is accepted and later undone, cost that changes with the way the agent is operated, and low-volume processes whose monthly economics are hard to predict.
The work gets quietly undone
Most systems can measure acceptance on the day: did the output pass a check, did a person approve it, did the record get written? Whether that work is still standing a month later can only be known later. The failure window is longer than the measurement window.
A credit note is raised and reversed a fortnight on. A supplier record is updated, then corrected by the person who owns it. Both runs may appear successful on the launch-day dashboard. Both created rework in the business.
If the correction never reaches the operating loop, the agent learns nothing from it. Worse, the team may keep updating instructions and evals from what was accepted on the day rather than what later held up. The system around the agent then optimises for the wrong signal.
Software delivery gives us a well-measured example of that risk because changes and reversals are logged. Bill Harding, CEO of the code-analytics company GitClear, described the incentive plainly.
AI strongly prefers to write code that won’t be labeled as a defect. Bill Harding, GitClear · LeadDev, July 2026
GitClear’s 2026 study of 623 million code changes found that work revised within two weeks rose 15 percent and error-masking constructs rose 47 percent across its 2023 to 2026 window. That is evidence about software, not proof that every business agent behaves the same way. It shows why immediate acceptance cannot stand in for durable quality.
| The demo | Production | |
|---|---|---|
| The case | Chosen and bounded | Whatever arrives |
| Watching | People are present | Monitoring has to be designed |
| Success is | The output looked right | The outcome still holds later |
| Measured | Immediately | Across the failure window |
| Cost per case | An initial observation | A distribution shaped by real cases |
| Ends when | The meeting ends | A named owner decides |
Context changes the cost curve
In a loop that resends a growing history on every step, input cost can rise faster than the number of steps. Instructions, examples, retrieved documents and tool descriptions all compete for the same context. Edge cases often add more material, and the additions accumulate unless somebody removes or restructures them.
Louis-François Bouchard measured this on a production tutoring agent. His diagnosis is the sentence worth remembering.
The model didn’t get dumber. Its context did. Louis-François Bouchard · Context engineering in 2026, August 2026
His results also show why this is not an inevitable one-way ratchet. In his workload, capping tool output cut cost per turn by 38 percent without a measured loss of memory. Prompt caching, retrieval, output limits, deliberate pruning and model routing can all change the curve.
The pilot cost is therefore not the lowest number the agent will ever produce. It is simply not a production forecast. Production economics have to be measured per case, against the real distribution of work.
Low volume makes the average less stable
Cost per case is often right-skewed. Most cases are ordinary and a small number run long. At low volume, those cases can move the monthly average cost per case sharply. At high volume, the average is normally more stable, even when the total bill is larger.
That distinction matters. A finance process handling thousands of similar cases may be expensive in total but predictable per case. An analyst process completing five deep investigations may be cheaper overall and still surprise you every month.
In our own work, the pattern was found in cost modelling rather than a universal production benchmark. That changed which processes we treat as economically uncertain and what evidence we require before approving them.
What is agreed before the build?
A process needs a business case before its agents need an architecture. Without one, there is no stable outcome, baseline or decision rule to hold the system to.
The distinction between process and agent matters. A business hands over a process outcome. One agent may carry it, or several smaller agents may work underneath it. That is an architectural decision and may change during the build. The business case and commercial unit remain the process, so splitting or combining agents does not quietly change what the customer bought.
For every process we put into production, the business case fits on one page. It records six things: the work, quality and risk, the baseline, investment and value, the performance target, and the named owner.
Two details decide whether the rest is useful.
The baseline is labelled. Where the organisation’s history supports it, the baseline is computed and labelled measured. Where it does not, it is modelled from a comparable process, an external benchmark or an explicit assumption and labelled modelled. A modelled baseline can be challenged and replaced. A hidden assumption cannot.
Capacity is not presented as value. The business case distinguishes capacity-equivalent time from realised value. Freed time only becomes value when a named owner converts it into higher throughput, better service, lower external spend or an actual staffing decision. Until that happens, it remains available capacity rather than a saving.
The case must be allowed to come back negative. Otherwise, it is a justification document rather than a decision instrument.
What does running an AI agent in production look like?
We use a four-phase method. The shape matters more than the names.
Scan establishes the desired outcome, current baseline and whether the work is suitable. Onboard defines the agent roles, system access, boundaries and accountable owner. Earn trust tests the agents on real cases before they act alone. Grow measures the process against its business case for as long as it runs.
The backwards arrow is important. Source systems are updated. Rules move. Models are replaced. A configuration that has not been reviewed for a year is not proven stable merely because it is still running.
Day to day, four operating signals sit together: utilisation, durable quality, effect on process capacity, and cost per case. They feed the three business-case measures used to judge the role: quality, capacity and value.
The quality measure has to outlast the failure window. First-time-right on the day is an early signal. First-time-right after the agreed period is the durable result. The distance between them is the work somebody reopened, corrected or reversed.
That number is the readout, not the fix. The fix is to catch each correction and return it to the operating loop: what the agent did, what a person changed, and why. A recurring correction becomes a candidate rule. It joins the agent’s standing context only after it passes that agent’s tests and evals.
The loop is the answer, not the dashboard. Close it and future changes are based on the outcome that proved true. Leave it open and a quality score can improve while the business keeps undoing the work.
We run code review, QA, security checks, documentation, infrastructure checks and internal reporting as agents at different autonomy levels inside Aitonomy. That is where several of the failure modes in this article first became visible to us.
What did we change?
We changed two parts of our own method.
We stopped treating the number of agents as the unit. We had already concluded that effort follows the complexity of the process rather than the number of agents. We had not carried that conclusion through to how we described and priced the work. A reader of our own document caught the inconsistency.
The process is now the business and commercial unit. The agents underneath it remain architectural roles. Their number can change without changing the promised outcome or quietly moving the price.
We changed how we treat low-volume cost risk. We initially assumed high-volume processes would be hardest to predict because that is where the total spend is largest. Our modelling showed that the monthly average cost per case is less stable at low volume, where a few long cases can move the result sharply.
We found that while modelling, before it affected a live business case. The useful part was not avoiding the mistake. It was finding a measure that forced us to change the method.
How do we keep one under control?
This is the work Aitonomy continues after an agent goes live. Aitonomy Control records the operating evidence. Our operating team runs the control loop and uses that evidence to investigate drift and change how the agent is operated. The customer’s process owner remains accountable for the outcome and signs the monthly decision to widen, hold, step back or retire.
Control starts before the build. We agree what will be measured, establish the baseline, define the agent’s boundaries and set the evidence it needs before it may act with more autonomy.
The failures in this article share that requirement. Immediate acceptance cannot replace durable quality. Pilot cost cannot replace production cost per case. A theoretical capacity estimate cannot replace realised value. An autonomy level cannot move in only one direction.
Where this does not apply
If work runs only a few times a month, or its rules change every time it runs, much of this operating system may be overhead you do not need. It is built for processes that repeat often enough to measure. Below that line, a person with a good checklist may be cheaper and better. A Scan that concludes that has done its job.
Aitonomy Control then keeps that evidence together: what each agent did, what a person approved, whether the work held up, and how quality, capacity, value and cost compare with the agreed baseline.
Quality, capacity and value
One agent, held to the baseline agreed before it was built. The figures are illustrative.
91%
≈374 h
≈7.5×
Illustrative, not a customer result. What it shows is the shape of a monthly review: one finance operations agent over twelve weeks, against a monthly baseline of 240 hours measured before it was built. Hours handed back are capacity returned to the team. They are not cash saved. What that capacity is worth depends on what the team does with it, and the return figure values it at the organisation’s own rate against the agent’s running cost. Replace every number here with your own baseline, rate and cost before using the shape in a case.
That evidence has to change decisions. We can adjust context, switch to a lighter model when it clears the same bar, narrow or widen autonomy, or retire the role. When an agent’s intended purpose, scope or use changes, the relevant classification, documentation, human controls and responsibilities have to be reviewed as well. The formal legal assessment remains separate from the technical evidence Aitonomy Control provides. This is also the operating principle behind showing what every agent did and who approved it.
Agents can prepare much of the monitoring work: read scoreboards, flag drift and collect the relevant runs. Our operating team reviews that material and brings the evidence to the process owner. The verdict itself remains human.
There is a simple test for whether that governance is real. Ask when an agent was last moved down an autonomy level. Ask when a monthly decision last retired an agent. Ask what changed because of the scoreboard last month.
If the answer to all three is never, the system is reporting rather than controlling. A control that never changes a decision is only a dashboard.
Getting an agent to do the work once is increasingly easy. Running it well is the part after that: a baseline agreed before the build, a named owner, evidence that can demote as well as promote, and a monthly decision that is allowed to retire the agent.
Common questions
Why do AI agent pilots succeed and then stall?+
What determines the cost of running an AI agent?+
What should you measure once an AI agent is live?+
Why can first-time-right be misleading?+
Who is accountable for an AI agent in production?+
Sources
- Gartner, Over 40% of agentic AI projects will be cancelled by the end of 2027
- DORA, State of AI-assisted software development 2025
- GitClear, The Maintainability Gap, and Bill Harding interviewed in LeadDev
- Louis-François Bouchard, Context engineering in 2026
- European Union, Regulation (EU) 2024/1689, the Artificial Intelligence Act
- Statements about Aitonomy’s own cost monitoring and modelling are identified as such in the article. They are not presented as external benchmarks.