AI in manufacturing: from PoC to real operation
Testing AI got easy; making AI work inside a live operation is still hard. Why most AI in manufacturing stalls at PoC, and how to get from PoC to production.
Anyone can open a chat, paste an order and get a reasonable answer back. That created the feeling that the hard part is over. It is not — it just moved. Testing AI became trivial; making AI in manufacturing work inside a real operation, with messy data, defined owners and consequences on the shop floor, is still the actual work.
This article is about that crossing: why most industrial AI pilots stall at PoC, which decision cycles are worth attacking first, and the concrete path from PoC to production without ripping out what already works.
Why AI in manufacturing stalls at PoC
A proof of concept dazzles in a meeting room and disappears the following week. The pattern repeats across factories, distributors and industrial service providers. The causes are rarely the model — they are four duller things:
- Unreliable data. The PoC runs on a hand-curated spreadsheet. The real operation has mismatched records, wrong units, incomplete history. The AI inherits the mess and loses trust on the first visible error.
- No owner. The pilot belonged to "the innovation folks". Nobody in the operation answered for it. With no owner, there is no one to tune it, push it and defend it when something breaks.
- No workflow integration. The AI's answer lived in a separate tab. To use it, the operator had to leave the ERP, copy, paste, double-check. Extra work never becomes a habit.
- No measurement. Nobody defined, before starting, what would improve and how it would be measured. With no baseline, the result becomes opinion — and opinion does not hold a budget.
The right question is never "did the AI get it right?". It is "did this decision cycle get faster, cheaper or more reliable — and can you prove it?".
AI use cases in industry: think in cycles, not features
The useful unit is not "a chatbot" or "a model". It is a decision cycle that today costs time, money or rework. Four concrete examples, by area:
- Engineer-to-order quoting stuck between sales and engineering. The request arrives, sales needs a number, engineering needs to interpret the spec. The cycle dies in an email queue and the customer waits days for a price.
- Procurement decided too late. The buyer discovers the need when stock is already tight, fires off panic quotes and closes on worse terms. The buying cycle reaches the market late.
- Production reprioritization. An urgent order lands, a machine breaks, a material is missing. Resequencing depends on who is on the floor and on their memory. The reprioritization cycle is slow and personal.
- Quality non-conformities that recur. The same deviation comes back because the root cause was never closed. The quality cycle records but never learns.
Notice: none of these is "a lack of AI". They are decision cycles that are slow, late or never close. AI enters as a tool to close the cycle — not as the goal.
Two real examples of ours
This is not hypothetical. Two of our systems run on exactly these cycles.
Maestro coordinates production. It cut time spent on coordination by roughly 50 to 60% in the operations where it measures that, and has 5 of 7 modules in production. It is not a pretty demo pilot: these are modules in the flow, used by the people who operate.
Cotador solves the procurement quoting cycle over WhatsApp. What took days of back-and-forth now closes in minutes, in the channel where supplier and buyer already talk. The AI did not replace the buyer — it shortened the buyer's cycle.
These are honest examples of what to expect: a concrete, measured gain on a specific cycle, in operation. More real cases and the logic behind them in our method.
From PoC to production: the path
The industrial AI that survives follows roughly this sequence. Nothing glamorous — it is what works.
- Map the real flow. Not the org chart, the flow. Who decides what, with which information, in which system, and where it stalls. You will find that half the pain is process, not technology.
- Pick one valuable, narrow cycle. One. The one that hurts, is frequent and can be measured. Stuck quoting, late procurement, reprioritization — pick the one that pays back fast.
- Integrate with the ERP/CRM you already have. No rip-and-replace. The AI has to live inside the system the operation already uses, reading and writing where the work already happens. A separate tab dies.
- Add human approval where it matters. On consequential decisions — a price sent, an order reprioritized — the AI proposes and a person approves. Trust is built with the human in control early, not with full autonomy on day one.
- Measure against the baseline. Define the number first: cycle time, cost, rework rate. Compare. Without it you do not know whether you won, and you cannot defend the next step.
- Expand from what you proved. With one measured, reliable cycle, the second comes easier. That is how Maestro reached 5 modules — one cycle at a time, not a big bang.
The right tech for the right cycle
A common temptation: put an AI agent on everything. Expensive mistake. The tool follows the cycle, not the trend.
- An LLM agent when the cycle requires interpreting ambiguous language — reading a loose spec, understanding a request sent as a message, reconciling descriptions that do not match.
- Simple automation when the rule is clear and stable. Firing a quote when stock crosses a reorder point does not need a language model; it needs a reliable trigger.
- Fixing the process first when the bottleneck is a wrong record, diffuse responsibility or a step that should not exist. No AI fixes a broken flow — it only speeds up the error.
The AI in manufacturing that delivers value is almost always a mix: a bit of agent where there is ambiguity, automation where there is a rule, and the humility to fix the process where it is crooked.
Where to start
Do not start with the tool. Start with the most expensive decision cycle you can describe in one sentence and measure with one number. If that is clear, the rest of the path — integrate, approve, measure, expand — becomes concrete.
If you want help seeing which cycle to attack first, we do that directly with you: map your first cycle.
Frequently asked questions
- Why do AI projects in manufacturing stall at the PoC stage?
- Almost always for four reasons outside the model: messy real-world data, no owner inside the operation, no integration with the actual workflow, and no measurement defined before starting. The PoC impresses on a curated demo but does not survive mismatched records and the real routine.
- What are good AI use cases in industry to start with?
- Decision cycles that are slow, frequent and measurable: engineer-to-order quoting stuck between sales and engineering, procurement decided too late, production reprioritization, and recurring quality non-conformities. Pick one narrow cycle that hurts and can be measured.
- Do I need to replace my ERP to use AI in operations?
- No. The path that works is integrating with the ERP and CRM you already have, reading and writing where the work happens, rather than ripping and replacing. AI that lives in a separate tab becomes extra work and never becomes a habit.
- Do I always need an LLM agent?
- No. Use an LLM agent when the cycle requires interpreting ambiguous language; simple automation when the rule is clear and stable; and often fix the process first when the bottleneck is a wrong record or diffuse responsibility. The tool follows the cycle, not the trend.