Article

The Smart Factory Bottleneck Is the Interfaces, Not the Model

Industrial AI succeeds or fails on whether equipment, sensor, control, operator, and business systems can hand each other a fact they agree on. A smarter model does nothing for a plant where they can't — and the fix is a vocabulary you own, not a license you rent.

Your smart factory is failing at the interfaces, not the model. I keep seeing the same shape of failure in industrial AI: a pilot runs beautifully on one line, everybody signs off, and then the rollout to the second plant stalls out and quietly dies. The postmortem almost always ends up pointed at the model — not smart enough, needs better reasoning, wait for the next version. That is the wrong autopsy. The model did not change on the drive to plant two. The data environment did, and nobody scoped for that, because the pilot was being hand-fed by a person the project plan never accounted for.

The pilot's hidden dependency

Look at what a pilot actually runs on. Somebody exports a clean file. Somebody renames machine tags so a human can read them. Somebody who has been in that building a long time explains that a particular downtime code does not mean what the manual says it means. That work is real, skilled, and invisible — it never lands in the deck. So what the pilot proved was not the system. It was the system plus an interpreter you did not budget for and cannot copy to another site.

At plant two, the tags are named differently, the historian is a different vintage, the MES was configured by someone with different opinions, and the interpreter is not there. Same model, same prompts, same vendor, completely different outcome. That is not an intelligence problem. It is a problem with what those systems can and cannot say to each other.

"Interface" does not mean "connector"

I want to be precise here, because the word interface usually gets read as a connector, and that is not what I mean. Whether you can make a REST call into the ERP is a solved problem and has been for years. What I mean is whether the MES, the historian, the PLCs, the ERP, and the person on the floor agree on what a part is, what a batch is, what a downtime code means, and when a shift starts and ends. Connection is easy. Agreement is the job.

The difference shows up the moment you ask a real question. If the ERP treats a batch as a purchase lot and the MES treats a batch as whatever ran between two changeovers, both systems are online, both return data, and every metric that depends on both is quietly wrong. Nothing errors out. You just get answers that are confidently off, and a plant manager who stops opening the tool by week three.

Try tracing something that sounds trivial — why did line three run short last night. Answering it requires the order from the ERP, the stop time from the historian or PLC, the reason code somebody selected on an HMI, the target rate from a standard set years ago, and a shift boundary that may cut the run in half. One question, five systems, and every hop is a place where meaning can shift without anyone noticing.

The people with nothing to sell you are pointing at the same layer

I do not use outside documents to prove your plant is broken; a roadmap is not a diagnosis. What they are good for is showing where the attention of people with no product to sell is going. NIST's 2026 roadmap on artificial intelligence and machine learning for smart manufacturing, published July 3, 2026, names the complexity of industrial big data, data management, and integration with heterogeneous sensing and control systems among the critical challenges to deploying AI in industrial settings. Not one item on that list is a model capability.

The stronger signal is what the standards bodies are actually building. As of April 2026, the OPC Foundation is converting more than 430 OPC UA Companion Specifications into markdown, RAG chunks, embeddings, and MCP interfaces, with the stated aim of grounding agentic AI in semantic interoperability. The organization closest to the machines is not spending this year making anything smarter. It is spending this year making sure a machine, a system, and a model mean the same thing when they use the same word.

Why this gets expensive

A manufacturer walks in with an integration problem, describes it accurately, and gets answered with a model upgrade or an agent platform. I want to be fair about this: much of that software is good, and the people building it are not running a con. The pitch is simply aimed one layer above the actual constraint. You pay for capability you cannot reach, because what stands between you and it is that five systems disagree about what a part is. No license resolves a disagreement.

There is a fast way to find out which layer you are being sold at. Ask what happens at plant two. Ask who owns the mapping between equipment tags and the words your business uses. Ask what breaks if you swap models next quarter. If the answers are vague, or all of them route back into the vendor's platform, you are not buying a system — you are renting an understanding of your own operation, and that is a worse deal than the invoice makes it look.

Implementation: what this actually changes

If you own the interface layer, a model change is a migration — annoying, schedulable, finite. If a vendor owns it, every model change is amnesia. Practically, owning it looks like a few concrete artifacts:

  • A canonical vocabulary. One definition per term that matters — part, batch, shift, downtime, good — with the system of record named for each.
  • Explicit mappings. Tag-to-term and code-to-meaning tables, versioned in your repository, not in a vendor console and not in one person's memory.
  • Conflict rules. When the ERP and the MES disagree, something has to decide. Write the rule down instead of rediscovering it in every meeting.
  • Tests, not documents. A reconciliation check that fails loudly when a definition drifts beats a data dictionary nobody opens.
  • A second-site rehearsal. Before you scale, dry-run the workflow against another plant's naming and see what breaks. That is your real readiness signal, not pilot accuracy.

Here is the Monday version. Pick one workflow — not a program, not a transformation, one workflow somebody would notice if it started working. List every system it touches; it will be about five. Write down what each of those systems means by the four or five words the workflow depends on. Where they disagree, decide which one is right and record the decision somewhere durable.

It is boring work and it takes a couple of weeks. It is also worth more than any model decision you will make this year, because at the end you have what the pilot never had: a written, testable agreement about what your plant is saying. That is what travels to the second site. That is what survives your vendor. And if it turns out your systems already agree and the model really is the constraint, you found that out in two weeks for the price of some meetings. I do not think that is what you will find.

Full episode transcript

Your smart factory is failing at the interfaces, not the model. Here's the pattern I keep watching in industrial AI. A pilot runs on one line, it works, everybody's happy, and then it goes to the second plant and dies. And the postmortem always drifts toward the model — it wasn't smart enough, it needs better reasoning, wait for the next version. That's the wrong autopsy. The model did not get dumber on the drive to plant two. The data environment changed, and nobody scoped for that, because the pilot was quietly being hand-fed. Think about what a pilot actually looks like on the inside. Somebody exports a clean file. Somebody renames the machine tags so a human can read them. Somebody who has been in that building a very long time explains that a downtime code doesn't mean what the manual says it means. All of that is a person doing translation, off the clock, and none of it shows up in the deck at the end. So what got proven wasn't the system. It was the system plus an interpreter you didn't budget for and can't copy. Which means the pilot's real dependency list has a person on it, and that person does not travel. At plant two the tags are named differently, the historian is a different vintage, the MES was configured by somebody with different opinions, and the context that made the first deployment work was never written anywhere. Same model. Same prompts. Same vendor. Completely different result. That is not an intelligence problem. That is a problem with what those systems can and cannot say to each other. And I want to be precise about the word interface, because it usually gets used to mean a connector, and that is not what I mean. I'm not talking about whether you can get a REST call into the ERP. You can. That part has been solved for years. I mean whether the MES, the historian, the PLCs, the ERP, and the person on the floor agree on what a part is, what a batch is, what a downtime code means, and when a shift starts and ends. Connection is easy. Agreement is the whole job. Those two things get conflated constantly, and the difference shows up the second you ask a real question. If the ERP thinks a batch is a purchase lot and the MES thinks a batch is whatever ran between two changeovers, both systems are online, both return data, and every number that depends on both is quietly wrong. Nothing throws an error. You just get an answer that is confidently off, and a plant manager who stops opening the tool by week three. Take something that sounds trivial. Why did line three run short last night. To answer that, something has to know which order was running, which is the ERP. When the line actually stopped, which is the historian or the PLC. Why it stopped, which is a code somebody picked on an HMI, maybe carefully. What good output for that part is supposed to be, which lives in a standard someone set years ago. And whether the shift boundary cuts the run in half. One question, five systems, and every hop is a place where the meaning can shift without anyone noticing. This isn't a niche opinion held by people who do integration for a living. NIST published a 2026 roadmap on artificial intelligence and machine learning for smart manufacturing on July 3rd of this year, and when it names what is actually blocking AI deployment in industrial settings, the list includes the complexity of industrial big data, data management, and integration with heterogeneous sensing and control systems. That is a federal standards body describing a plumbing problem in a document that is nominally about artificial intelligence. I don't reach for a document like that to prove your plant is broken — it can't tell you that, and a roadmap is not a diagnosis. What it is good for is showing where people with nothing to sell you are pointing. Nothing in that list of critical challenges is a model capability. It's all about whether the data coming off a mixed fleet of equipment can be reconciled well enough to be worth modeling in the first place. The hard part sits upstream of the intelligence, and I'd say it always has. The stronger tell is where the standards work is going. In April of 2026 the OPC Foundation said it is converting more than 430 OPC UA Companion Specifications into markdown, RAG chunks, embeddings, and MCP interfaces, with the stated goal of grounding agentic AI in semantic interoperability. Sit with that for a second. The organization closest to the machines is not spending this year making anything smarter. It is spending this year making sure a machine, a system, and a model mean the same thing when they use the same word. So there are two conversations running at the same time and they are not about the same thing. One is about capability — bigger context windows, better agents, what the next model scores. The other one, run by the people who write the specs the equipment actually speaks, is about vocabulary. Ask yourself which of those decides whether your quality workflow survives contact with a second facility. It isn't close, and I don't think it has been close for a while. Here's where it gets expensive. A manufacturer walks in with an integration problem, describes it accurately, and gets answered with a model upgrade or an agent platform. And I want to be fair, because a lot of that software is genuinely good and the people building it are not running a con. The pitch is just aimed one layer above the actual constraint. You end up paying for capability you cannot reach, because the thing standing between you and it is that five systems don't agree on what a part is. No license fixes a disagreement. There's a fast way to figure out which layer you're being sold at. Ask what happens at plant two. Ask who owns the mapping between the equipment tags and the words your business actually uses. Ask what breaks if you swap the model out next quarter. If the answers are vague, or every one of them routes back into the vendor's platform, you are not buying a system. You're renting an understanding of your own operation, and that is a worse deal than it looks like on the invoice. This is why I care about this so much more than which model anybody picked. If the plant owns the interface layer — the vocabulary, the mappings, the process knowledge, the rule about which system wins when two of them disagree — then a model change is a migration. Annoying, schedulable, done. If a vendor owns that layer, every model change is amnesia. You start over, you pay again, and the second time you have less leverage than you did the first. So the Monday version, if you want something to do with this. Pick one workflow. Not a program, not a transformation — one workflow somebody would notice if it started working. List every system it touches, and my bet is it's about five. Then write down what each of those systems means by the four or five words the workflow depends on. Part. Batch. Shift. Downtime. Good. Wherever they disagree, decide which one is right and write that down too, somewhere that isn't a person's head. That exercise is boring, it takes a couple of weeks, and I think it's worth more than any model decision you'll make this year. Because at the end of it you have the thing the pilot never had — a written, testable agreement about what your plant is actually saying. That's what travels to the second site. That's what survives your vendor. And if it turns out your systems already agree and the model really is the constraint, good, you found that out in two weeks for the price of some meetings. I don't think that's what you'll find.

Sources

  • https://www.nist.gov/publications/2026-roadmap-artificial-intelligence-and-machine-learning-smart-manufacturing
  • https://arxiv.org/abs/2605.00839
  • https://opcfoundation.org/news/press-releases/opc-foundation-advances-opc-ua-for-the-ai-era-with-companion-specifications-optimized-for-agentic-ai/