The demo worked. The agent responds well, the interface is clean, the steering committee gave its sign-off. Six months later, the project is «on pause». This scenario is recurring in many organisations that have launched an AI POC over the last two years: a convincing pilot, genuine enthusiasm from the business side, followed by a gradual bogging down when faced with real-world cases. No one explicitly says the project is abandoned. It slips down the priority list, replaced by other urgent matters, until it becomes a topic people avoid bringing up at committee meetings.
For organisations already familiar with AI projects, this finding is nothing new. What is less so is the real reason for this blockage. It is often attributed to the model, its reliability, or its ability to generalise. The real problem lies elsewhere, upstream of the code.
These silent failures are costly, not just in terms of budget consumed. They undermine AI credibility internally. After one or two POCs that end up this way, the next project starts with a reputation for fragility it hasn't yet earned.
An agent designed for an AI POC operates within a defined scope. The use cases tested are those that have been anticipated, those that appear in the specifications or the demonstration scenario. The agent handles them well, sometimes very well. The problem arises at the point of scaling up.
Production is about unforeseen cases. A customer who phrases their request differently than expected. A business exception that no one documented because it happens once a month. A poorly filled-in document. A sequence of rules that two departments apply differently depending on their history. Each of these situations becomes a ticket. Every ticket calls for a patch. And every patch further complicates a system that, originally, was meant to simplify things.
This mechanism is nothing out of the ordinary. Feedback from teams deploying agents into production converges on this point: the gap between the behaviour observed in testing and the behaviour required in real-world conditions widens as the volume of cases handled increases. The more situations the agent touches, the more it encounters scenarios that have never been formalised anywhere—neither in documentation, nor in the minds of the teams who used to perform the task before it.
After a few months, the agent resembles a pile of rules added as they go along. Each fix addresses the issue that has just occurred, without ever questioning why that case hadn't been anticipated. The system grows, its logic becomes harder to follow, and the team maintaining it spends more time patching things up than improving it. It is often at this stage that the business sponsor starts to doubt, not AI in general, but this specific project.
The most common response then consists in hardening the agent: more rules, more safeguards, a more detailed prompt. This treats the symptoms, rarely the cause. The real issue remains upstream, in understanding the work that the agent must reproduce, with its detours and informal adjustments.
That is where the misunderstanding lies. People think they have automated a business process. In reality, they have automated a procedure, that is to say a simplified, documented version of that process. Asking an operator how they handle a file often reveals this discrepancy: what they describe in three steps conceals a dozen micro-decisions made without a second thought.
| Documented procedure | Actual process | |
|---|---|---|
| What is written | The nominal case, the standard steps | The nominative case, plus the never-formalised exceptions |
| Who knows him | The author of the specifications | The person who handles the files on a daily basis |
| What the POC sees | This case, often brilliantly | Rarely tested before going live |
We see too many agent projects judged on model quality, whereas the variable that
deciding their fate happens upstream. A well-tooled model on a poorly understood process fails in production, regardless of its version. This conviction does not call into question the value of current models, it simply changes where the effort should be focused. The time saved by choosing the right model never compensates for a process that remains poorly understood.
The problem is not the model. What we see failing, project after project, is the automation of a procedure where a process needed to be framed. Cognitive framing is not a luxury step to be added if time permits. It is the condition for an agent to survive its first contact with reality.
An AI POC that remains stuck six months after a successful demo is not a technical failure. It is a sign that a step has been skipped, which is that of understanding actual work before automating it. This step cannot be caught up once the agent is built, it must be thought about beforehand.
After seeing why so many POCs fail for reasons that have nothing to do with technology, the question that follows is one of method: how to frame an agent project so that it lasts beyond the demo.
A POC stuck in a drawer? We can look together at what was missing from the scoping before relaunching it.
