The scene repeats at companies of every size. The demo works, the board approves, the project goes into the plan. Six months later it is still a demo. Nobody canceled it; it simply never became an operation. When somebody asks what happened, the answer tends to be vague, because there was no single mistake. There was a wrong order of questions.
A proof of concept answers whether the model can do it. Production depends on another question: whether the operation can do it. Sustaining the agent when the data arrives dirty, when the system is down, when the customer asks something nobody anticipated, when the person who built it has left. The PoC was not designed to answer that, and should not be blamed for it. The problem is deciding to invest on the strength of it alone.
The five causes that repeat
1. The PoC was optimized to impress, and production is optimized not to be wrong
Those are opposite goals. To impress, you pick the most visual case, the prettiest example, the most expensive model. Not to be wrong, you pick the case with the least variation, you define what the agent does not do, and you measure the accuracy rate in the worst scenario. A project born in the first mode has to be redone for the second, and redoing it looks like regression to whoever approved the demo.
2. The demo's data was clean
Every PoC runs on a set of examples prepared by whoever built it. Production runs on the customer who writes everything in capitals, the order with two items instead of one, the CRM field that has been empty since 2023. The demo's accuracy rate does not transfer, and the difference only shows up once there are real users complaining.
3. After the demo, nobody owns it
A PoC has an owner: the person who built it. Production needs an owner for the process, an owner for the data, an owner for the integration and an owner for running it after go-live. When the project leaves the demo stage, those four responsibilities usually end up with no names attached, and what has no name does not move.
4. Integration was left for later
In the PoC the agent answers with data copied into a spreadsheet. In production it has to read the real ERP, write to the real CRM and speak through the official channel. This is where most schedules blow up, and it is not because of the agent: it is because of access to the legacy system with no API, the credential nobody is allowed to grant, the channel approval that takes weeks. None of that showed up in the demo because the demo did not need it.
5. Governance arrived late
Security, privacy and audit enter the conversation once the pilot is ready and the date is set. The questions they ask (what leaves for the model, who approved this action, how do we reconstruct the decision) require a change of architecture, not of configuration. Rebuilding architecture under deadline pressure is where projects die without anyone declaring it.
None of the five is a technical failure of the model. All of them follow from treating the demo as the project, when it is only the first question.
The change of order that resolves most of them
Projects that reach production usually did one thing differently from the start: they began with the process, not with the demo. In practice that changes five decisions.
- Pick the case by the process, not by the effect. The best first case has volume, a clear owner, accessible data and a metric that already exists. It is rarely the most impressive one.
- Define the metric before building. Resolution rate without handoff, time to first response, conversion at one step. If the metric does not exist today, the first job is to measure it, because with no baseline no result is demonstrable.
- Integrate first, refine later. A simple agent connected to the real system is worth more than a sophisticated agent connected to a spreadsheet. Integration is where the risk lives; facing it early is what makes the rest predictable.
- Governance in the design, not in the review. Decide from day one what leaves for the model, where human approval comes in and what gets recorded. Done at the start, it costs hours. Done at the end, it costs the project.
- Name the owners before go-live. Who answers for the process, the data, the integration and the operation. If one of the four has no name, the project is not ready to ship, however good the agent is.
Signs your project is on the wrong track
- The demo has already happened and nobody can say which business number it will move.
- Access to the main system has not been requested yet, and the project is "almost ready".
- The person who built it is the only one who knows how it works.
- The conversation with security and privacy is scheduled for "after the pilot".
- The plan has a launch date, but no one assigned to watch the agent the following week.
Three of those five together are usually enough to predict the outcome, months in advance.
What production demands, and the PoC does not show
| Dimension | In the PoC | In production |
|---|---|---|
| Data | Prepared, clean, known. | Real, incomplete, in a format nobody anticipated. |
| Integration | A spreadsheet or a simulation. | ERP, CRM and the official channel, with credentials and approval. |
| Errors | Redo it and show it again. | An affected customer, a trail to explain it, a fix that does not stop the operation. |
| Who sustains it | Whoever built it. | An operations team, which has to understand it without having built it. |
| Cost | Irrelevant. | Per resolved case, compared with the previous process. |
| Governance | Nobody asked. | A condition of entry. |
Why Runflow works this way
Runflow's model exists because of this list. The platform solves the building, operating and measuring part; the Forward Deployed engineers solve the part the platform alone does not, which is the order of the questions. They join the discovery, pick the case by the process, integrate with what already exists, go to production alongside your team and stay after go-live. Whoever is going to operate the agent is trained during go-live, not in a handoff at the end.
The free assessment is the first step on that path: we look at the process you have today, with real data, and tell you plainly whether the case calls for an agent and where to start. When the answer is that the tool you already use solves it, we say so.
