An agent that works in demo mode is immediately obvious. The professions applaud. They want the version that *really* runs, the one that handles day-to-day cases, not just the ten scenarios chosen for the presentation.
And that's where everything grinds to a halt. The IT department arrives with its questions, normal, predictable, but never asked before: who handles the prompts when the process changes? Who validates what the agent decides? How can we retrace, six months later, the logic behind a specific action?
Silence from the project owner. The POC was designed to convince a committee, not to survive an audit. This gap is not uncommon. As agents multiply within companies, it almost systematically reappears and it proves costly for those who discover it too late.
The data manager who championed the project knows the follow-up by heart. He demonstrated the agent, the business departments validated it, everyone left convinced. Then comes the meeting with the IT department, and the list of questions that had never been asked until then.
Here's the paradox: an agent can succeed at almost anything it's shown in a demo and remain unusable in production, when scaling agentic AI. Not because it's technically bad. Because the POC never looked in the right direction.
A POC, by its nature, proves a capability in an open environment. It follows the nominal path, the well-trodden road, where everything happens as expected. The side aspects of the job remain outside its scope: exceptions handled manually, decisions an employee makes without even thinking about them, checks that exist without being written down anywhere.
No one documented them. Why would they? They never needed to exist on paper; they lived in heads and habits. A POC built for a demo has no reason to be interested in that.
The real problem arises when it comes to industrialisation. Copying what an agent does during a demo is simple. Copying what an entire organisation does, with its detours, adjustments and special cases, is far less so.
And that is why the IT department’s questions so often fall flat: they are not aimed at the technology, but at a process that has never been put into words. Industrialisation then becomes a complete overhaul of the project – a redesign that nobody had anticipated or budgeted for.
The project lead finds themselves in a bind. On the one hand, there are the business units, who are fully on board and want to move quickly. On the other, an IT department that rightly refuses to put a system into production that it can neither guarantee nor audit. This deadlock is by no means an administrative one. It simply highlights the fact that, until now, the project had never had to address these issues.
Some organisations have taken the initiative. Before deploying an agent into production, they set out in black and white the questions that would otherwise be raised too late. They aren’t reinventing the wheel: these are, almost word for word, the questions that an IT department asks instinctively as soon as a project reaches the production stage.
Answering these questions requires stepping outside the nominal path.
The following table summarises the gap between what a POC typically covers and what a full deployment requires:
Dimension | Demonstration POC | Production deployment |
Cases handled | Controlled scenarios, nominal path | All cases, including exceptions |
Validation | Implicitly, judged on the final outcome | Explain, with thresholds and checkpoints |
Traceability | Not required | Necessary for audit and compliance |
Governance | Absent or informal | Defined roles and responsibilities |
Mapping out every exception one by one would be a never-ending task, and pointless. The aim is more modest: to identify the main categories of exceptions, to pinpoint the roles that are currently involved informally, and to establish the control points that will need to become explicit. A file that is blocked due to missing data is not handled in the same way as a file that deviates from a business rule; both are exceptions, but they involve neither the same people nor the same decision-making levels.
Concretely, this means sitting down with the teams who run the process day-to-day. Asking them not what the procedure says, but what they actually do: the known workarounds, the verbal approvals, the moments where only experience makes a difference. The nature of the question changes. We no longer ask if the agent can do the task. We ask if we have truly understood what the person they are assisting actually does today.
This work, done before writing the first production prompt, weighs more heavily on the success of the project than any model tuning.
We have seen this pattern repeat itself, particularly with an industrial player in the automotive sector facing the same shift between POC and production. Our conviction was built on this: an agent is successful in production when the groundwork has been done before the demo, not after.
Modelling the cognitive components of a process, its exceptions, its controls and the points at which human intervention remains necessary, right from the scoping stage, changes the very nature of the project. The aim is no longer to prove that an agent can automate an isolated task. From the outset, a system is built to handle the actual load., the variability of the job, the control requirements of an environment that never quite resembles the demo.
It is this shift in perspective, from the nominal path to the entire process, that separates a prototype that remains a prototype from a project that truly scales. This isn’t a methodological detail reserved for large corporations: it’s the difference between an agent you showcase and an agent you actually use.
An impressive agent in a demo is not an agent ready for production, let alone for scaling agentic AI. The gap doesn't come from the model's power, but from what the project chose to look at before building.
Organisations that cross this threshold treat exceptions, controls, and governance as design choices, not afterthoughts.
At JEMS, it's the approach we call Cognitive architecture It structures our support for companies on their AI projects, right from the initial scoping. Your POC is working and the question of industrialisation has already arisen? Let's discuss it with your teams, before a complete overhaul becomes the only option.
