May 8, 20269 min read

Manufacturing AI readiness — the 6 questions that decide v1

Multi-agent ops, predictive maintenance, document automation, AI-native ERP. Which one you build first depends on six honest answers about your plant.

manufacturing
agents
strategy

Manufacturing is where AI gets real

Manufacturing AI is unforgiving. You're shipping into physical processes with human safety implications, contractual SLAs, and ERPs that have been working fine for years. The wins are huge — our Multi-Agent Manufacturing case study delivered 31% downtime reduction in 90 days — but only if you pick the right v1.

These six questions, answered honestly, point at which v1 fits your plant.

1. Is your data accessible without IT tickets?

SCADA, MES, ERP, operator logs — each speaks its own dialect. If pulling production data for analysis requires a Friday-afternoon IT ticket, that's your bottleneck. Fix data accessibility before the agent.

If yes: predictive maintenance and multi-agent ops are on the table. If no: start with document automation (POs, QC reports, invoices), which doesn't need real-time data plumbing.

What "accessible" actually means. Not that the data exists — that a named person can extract it this week without a project. Test it concretely: ask for six months of production data for one line, and time how long it takes to arrive. If the answer is days, you are in good shape. If nobody is sure who would run the query, that is your v1, and it is a data-access project rather than an AI one.

The vendor lock question sits underneath this. Plenty of plants find their SCADA or MES data is technically present but contractually or practically fenced by the vendor who installed it. Finding that out in week one costs an email. Finding it out in week six costs the timeline.

2. Is downtime the #1 measurable cost?

Most plants either know their hourly downtime cost or feel it in their P&L. If you can ballpark it within 20%, predictive maintenance has clean ROI math. If you can't, that's worth fixing before any AI investment.

How to ballpark it in an afternoon. Take the last twelve months of unplanned stoppages, multiply the hours lost by contribution margin per hour on the affected line, and add the downstream costs you can name — expedited freight, overtime, a missed delivery penalty. It does not need to be exact. It needs to be defensible to the person approving the spend, and a number within 20% is enough for that.

If you genuinely cannot produce it, that is a finding rather than a failure. It means downtime is not currently measured well enough to prove any improvement, which makes predictive maintenance a poor first project — you would be unable to demonstrate the result even if it worked.

3. Do shifts hand off well?

If supervisors are spending 20-30 minutes per shift change recapping, a Shift Briefing Agent is a strong v1. Low risk, immediate quality-of-life lift, almost no integration work. Often the entry-point engagement in our multi-agent builds.

Why this is the safest v1 on the list. A shift briefing agent reads what already exists — production logs, maintenance notes, quality flags — and writes a summary. It takes no action, touches no control system, and cannot cause a physical outcome. That makes the approval conversation short and the failure mode mild: a bad briefing is ignored, not dangerous.

It is also the best trust-builder. Supervisors can verify a briefing against their own knowledge of the shift immediately, which is exactly how confidence in the technology gets established before you ask for it on something consequential. Plants that start here approve their second agent much faster than plants that start with something clever.

4. Is your ERP under-used by leadership?

ERPs accumulate power that stays locked behind menus. If your CFO can't query cost drift without an analyst, an AI-native ERP layer is high-leverage. We built this for Alian Infinity — 4× leadership-tier usage in the first quarter.

The tell is who runs the report. If leadership questions consistently route through one analyst who builds the same views each month, that analyst is a human query layer, and their queue is the constraint on how often anyone asks a question. The value here is not saved analyst time; it is the questions that never got asked because the round trip was three days.

The prerequisite is a clean data model, not a clever interface. If the same metric is defined differently in three modules, a natural-language layer will confidently return whichever definition it found first, and leadership will lose trust in it within a fortnight. Reconciling those definitions is the real project, and it has value whether or not the AI layer is built.

5. Do you have a quality engineer who hates running QC?

Vision QC is a great wedge. YOLO-based defect detection with active-learning loops. Routes uncertain cases to your QC engineer rather than asking them to look at every part. Most pay back in under 6 months on a high-volume line.

Volume decides this more than enthusiasm. Vision QC pays back on high-volume lines with a defect rate high enough to matter and low enough that humans get bored looking for it. On a low-volume line with complex, varied parts, the labelling effort per unit of value is much worse, and a person is genuinely the right answer.

Plan for the labelling. Active learning reduces how many examples you need; it does not remove the need. Expect your quality engineer to spend real hours labelling in the first weeks — that is the project working as intended, and it is the single most common surprise in the schedule.

6. Is on-prem a hard requirement?

If yes, plan on edge gateway deployments + cloud reasoning over scoped channels, or fully on-prem with open-source models. Slower iteration, but doable. We've shipped both.

If no, you can default to multi-region cloud, which iterates much faster.

What "on-prem" usually turns out to mean. In practice the requirement is rarely "no data leaves the building." It is more often "no customer or contractual data leaves the jurisdiction," or "the line keeps running if the internet drops." Those are different constraints with much cheaper answers — regional inference for the first, local buffering with edge inference for the second.

Ask the question precisely before you architect for it. A fully on-prem build with open-source models is achievable and meaningfully slower to iterate on. Committing to it because nobody interrogated the requirement is the most expensive avoidable decision on this list.

What to skip in v1

Full multi-agent system as your first build. Start with 1-2 agents max. The org chart pattern is right, but build it incrementally.
A "central plant AI". Specialized agents per role beat one general model every time.
Replacing supervisors. AI watches. Humans decide. Always.

What a realistic first year looks like

The six questions pick a v1. What follows is the part that determines whether there is a v2, and the shape is consistent enough across plants to be worth setting out.

Months one to three: one thing, working. A single agent or model in production on one line or one workflow, with the measurement in place to prove what it did. The temptation at this stage is always to add a second capability because the first went well; resisting it is what keeps the evidence clean.

Months four to six: the number gets argued about. This is when someone senior asks whether the improvement was the system or the attention, and the answer depends entirely on whether a baseline was captured before the project started. Plants that took the baseline have a short conversation. Plants that did not have a long one, and frequently lose it.

Months seven to nine: the second capability, and the first maintenance. The v1 now needs eval review and occasional retraining, and that cost becomes visible for the first time. Budgeting it explicitly at this point — a few hours a month, named to a person — is what stops the second project being funded by quietly starving the first.

Months ten to twelve: the integration question. Two working systems raise the question of whether they should share infrastructure, data models, and observability. This is the right moment to build the shared layer, and the wrong moment to have built it is twelve months earlier, before anyone knew which parts would be shared.

What a good first year is not. It is not six agents. A plant with two systems in production, an owner for each, honest numbers, and an appetite for a third is in a far stronger position than one with a broad deployment nobody trusts. The second year is where breadth is cheap; the first year is where credibility is bought.

Typical first-build cost

A scoped 2-agent v1 (e.g., shift briefing + maintenance scheduler) on a single plant: $50-80K loaded over 8-10 weeks. Full multi-agent system: $90-150K over 12-16 weeks. Predictive maintenance only: $40-70K over 6-8 weeks.

ROI on downtime-reduction builds is usually 6-9 months. Document automation typically pays back in 4-6.

The question that isn't on the list

Six questions about the plant, and none of them about the people who will run the result. That omission is deliberate here, because it deserves its own answer: it is the question that decides whether the v1 survives its first year.

Who owns this after we leave? Not the sponsor who approved it — the person who reviews the alerts, notices when quality drifts, and adds the case when something goes wrong. In our engagements this is usually a systems lead or a senior supervisor, and it is a few hours a month rather than a role. Where that person exists and is named before the build starts, the system is still working two years later. Where they do not, it degrades quietly and gets blamed for being AI.

Who explains it to the floor? Every agent on this list changes what somebody sees on their shift. The plants where adoption goes smoothly are the ones where a supervisor the operators already trust introduces the change, and where the headcount question gets answered plainly and early. Left unanswered, it produces the quietest and most damaging failure mode available: alerts that get acknowledged and ignored.

Who decides when to stop? Some v1s should be turned off. A predictive maintenance model that never beat the existing inspection schedule, a vision system whose false-positive rate outweighs the catches — these are legitimate outcomes, and having named in advance who is allowed to call it is what keeps a plant willing to try the second thing.

If you cannot answer these three, the honest recommendation is to fix that before picking from the six above. The technology is the easy half.