Your smart factory is failing at the interfaces, not the model.

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.