Why your AI pilot never shipped
By Anthony Odole · September 3, 2026 · 10 min read
Somewhere between eleven and fourteen percent of enterprise AI agent pilots reached production at scale this year. MIT's work on the same question puts the share of generative AI pilots delivering measurable profit-and-loss impact at around five percent.
Those numbers get quoted as evidence that the technology isn't ready. I think that reading is wrong, and I think it's wrong in a way that costs organisations another year each time they believe it.
The research that actually diagnoses the failures doesn't blame the models. It blames "organisational bottlenecks, governance breakdowns, inadequate evaluation infrastructure, and integration complexity." One study of six hundred and fifty enterprise technology leaders put data integration complexity at the top of the list. The most quoted line in that literature describes the core problem as a governance and sequencing problem disguised as a technical one.
Governance and sequencing. That's not a machine learning phrase. That's an architecture phrase, and it describes the gap I keep finding when I'm called in after a pilot has stalled.
The instruction that could never have worked
Here's the cleanest example I have, from my own system.
Early on we had an AI employee that was supposed to record a summary of each conversation into long-term memory. The implementation was the obvious one: we wrote it into the agent's instructions. At the end of the conversation, call the memory tool and log what happened.
In every demo, it worked. Of course it did. In a demo, the conversation ends when you stop typing, and you can see it end, and the agent — prompted immediately afterward — does the thing.
In production it never fired. Not rarely. Never.
The reason is structural and it took us longer to see than it should have. An agent has no signal that a conversation has ended. Every turn might be the last one. There is no event, no boundary, nothing that distinguishes "the customer is thinking" from "the customer has gone to lunch" from "the customer will never write again." So an agent instructed to act at the end rationally defers on every single turn, forever, and the work never happens.
The instruction was not badly written. It was addressed to a moment that does not exist outside a demo.
We replaced it with something unglamorous: a scheduled worker that scans for conversations idle beyond a threshold, synthesises the summary itself, writes it, and stamps the record so it can't be written twice. No agent judgment involved. The agent was never the right actor for that job, because the job is triggered by an absence, and agents cannot perceive absences.
That's the shape of most pilot-to-production failures I see. Not "the model wasn't good enough." The demo validated a capability, and production required a system, and nobody sequenced the work of turning one into the other.
What a demo tests, and what it structurally cannot
A demo answers exactly one question: can the model do the task when the conditions are favourable and a human is watching?
That's a real question and worth answering. But four things are true in production that cannot be true in a demo, and each one kills pilots.
One: nobody is watching
In a demo, a human supplies the boundaries. They start the interaction, they recognise when it's finished, they notice when something looks wrong, and they quietly retry the two attempts that didn't work before showing anyone the third.
Production removes all four of those. The system needs its own answers for when work starts, when it's complete, what "wrong" looks like, and what happens on failure. Every one of those is engineering, none of it is model capability, and none of it appears on the pilot's success criteria.
Two: capability is resolved, not declared
In our platform, the set of tools an agent can actually use is the output of a chain: the capabilities attached to the agent, the skills those imply, the tools those require, a filter for whether the tool is platform-native or needs a connected integration, a registry on the execution side that has or hasn't got an implementation, and finally a lookup at call time.
Each layer can independently drop a tool.
We learned this the hard way. After a migration that moved one of those checks from a hardcoded list to a database-driven query, a family of tools stopped reaching agents entirely — because the migration never seeded the corresponding rows. The tools existed. The implementations existed. The agents had been granted them. But the layer in the middle now said no, and the symptom was that the agent would confidently attempt the call and get rejected in about a millisecond by a lookup that had never heard of it.
Nothing errored loudly. The agent simply became quietly less capable than the database said it was.
In a demo, capability is whatever you connected this morning. In production, capability is an emergent property of several systems agreeing, and you need a way to ask what it currently is. Most teams have no such way. Ask them what a given agent can do right now, today, and you'll get an answer derived from intent rather than from resolution.
Three: failure is silent
We once lost every background job in the platform for three days.
The worker process crashed on startup. The web server in the same container kept running perfectly. Health checks passed, because the health check was answering from the half that was alive. Every scheduled job — follow-ups, digests, scanners, sequence ticks — was dead, and nothing anywhere reported a problem. We found it by noticing something downstream that should have happened and hadn't.
The lesson isn't "add monitoring." The lesson is that agent systems fail in a specific and nasty way: they degrade into doing nothing, while continuing to look exactly like a system that is doing something. There is no exception thrown when an agent doesn't act. There is no stack trace for work that wasn't attempted. A pilot never surfaces this because a pilot is watched continuously by the person who built it.
If your production plan doesn't include a way to detect absence of work, you have a system whose most likely failure mode is invisible.
Four: state outlives the session
In a demo, the agent starts empty every time. In production it has history, and where that history lives is a decision most teams make accidentally.
We had a period where the chat interface displayed conversation history from one store while the agent's next turn was assembled from a different one. Both were working. Both were correct. But writing to the first made a message visible to the human and invisible to the agent — so a human could read a message on screen, watch the agent behave as though it had never been said, and reasonably conclude the model was broken.
It wasn't. Two stores, one of them load-bearing for the agent's context, and no document anywhere saying which.
Why "we'll productionise it later" inverts the sequence
The standard plan is: prove value in a pilot, then harden it for production. It sounds like risk management. It's actually the sequencing error that produces the eighty-six percent.
Everything I've described — the trigger that doesn't exist, the capability that can't be enumerated, the failure that can't be seen, the state that lives in two places — is invisible to a pilot by construction. The pilot's conditions are precisely the conditions under which these problems are hidden. So a successful pilot generates confidence about the one dimension that was never in doubt, and no information at all about the four that will actually decide whether it ships.
Then the pilot succeeds, and the organisation commits to production on the strength of it, and the engineering team discovers that "hardening" means building a system that was never scoped, budgeted, or sequenced — because the thing that was approved was a demo that worked.
This is the same failure I write about in the staging-to-production gap: an environment that structurally cannot exhibit the problems the next environment will, being used as evidence about the next environment. The word "pilot" has replaced the word "staging" and the error is identical.
What the governed pathway actually is
The phrase from the research — the absence of a governed pathway from pilot to production — is abstract enough to be ignored. Concretely, it's a small number of things that must exist before you cross, and they are architecture, not machine learning.
A resolved capability inventory. For any agent, a way to ask the running system what it can currently do — answered by the system, not by a person reading a design document. If you can't produce that on demand, you cannot govern the agent and you certainly cannot audit it.
A defined trigger for every piece of work. For each thing the agent is supposed to do, name what causes it. If the answer is "when it decides to," and the decision depends on perceiving something an agent can't perceive, redesign it now rather than discovering it in month four.
Detection of absence. A signal that fires when expected work doesn't happen. This is the single highest-value thing on the list and the one most consistently missing, because every instinct we have from ordinary software monitoring is oriented toward catching errors, and the characteristic agent failure produces no error.
One authoritative location for state. Whatever the agent reads to decide its next action is the system of record. Everything else is a view. Write that down, because when it's ambiguous the symptom is indistinguishable from the model being unreliable.
Human approval as a gradient, not a switch. The distance between "a person approves everything" and "the agent acts alone" is where most of the risk lives, and it should be traversed deliberately, per action class, with the ability to move back. Treating autonomy as a binary is how organisations end up choosing between an agent nobody trusts and one nobody is checking.
The uncomfortable implication
If this is right, then the failure rate is not evidence that the technology is immature. It's evidence that organisations are commissioning capability demonstrations and then acting surprised when they don't constitute systems.
That's a more expensive conclusion than "the tech isn't ready," because "not ready" lets you wait. This one doesn't. It says the work you skipped is still sitting there, it's architectural, and the next pilot will die of exactly the same thing unless someone does it.
The good news, if you want it: none of the five things above requires a better model. They require someone to sit down and decide how the system is supposed to work before granting it the authority to work unsupervised.
Architecture first. Technology second.
If your pilot stalled and nobody can say precisely which of the five was missing, that's the conversation I have most often.
Book an Enterprise AI Strategy Briefing →
— Anthony Odole · ex-IBM Senior Managing Consultant · 18 years in enterprise architecture · now building and running a multi-agent platform