There’s a moment that happens on almost every factory visit. You’re sitting with a production manager — coffee in hand, whiteboard behind them covered in handwriting that was never meant to be permanent — and you ask: “Where does this data live?”
They pause. Then they point at their head. Or the head of someone in the room.
We’ve now shipped or co-shipped more than 80 complex AI systems to factories over the past two years. Across industries, across countries, across production contexts that look nothing like each other. And if there’s one thing that keeps crystallizing with every deployment, it’s this: the most important data in any factory is not in the ERP. It is, stubbornly, magnificently, infuriatingly — in people’s heads.
This is a practitioner’s point of view, not a research paper. Everything can change. But right now, here’s what we believe.
The output should be code, not AI.
This one surprises people when we say it. We are building AI systems, and we are telling you the output shouldn’t be AI.
When you deploy an AI model directly as the operational interface — the thing the factory actually runs on — you get a system that is fast, impressive in demos, and brittle in production. It hallucinates. It drifts. It produces different answers to the same question on different days. For a factory running at 95% utilization, that’s not a feature.
Code, on the other hand, is deterministic. It does exactly what it says. It can be audited, versioned, tested. When something breaks, you know where to look.
So the correct architecture — the one that actually survives contact with the shop floor — uses AI to generate code, and then runs that code as the operational layer. The AI is the craftsman. The code is the product. And the factory runs on the product, not the craftsman.
The code must be created by AI under human supervision.
This is where it gets interesting. The AI can write the code. But it cannot write the right code without knowing things that aren’t written down anywhere.
Which shift has the equipment that vibrates on Tuesdays. Which operator eyeballs the viscosity before the sensor even reads it. Which line manager quietly overrides the scheduling system every Friday afternoon because the system doesn’t know about the weekend maintenance window.
This knowledge — tribal, embodied, accumulated over years — is what we call the contextual layer. Our working estimate is that at least 40% of the operationally relevant data in any factory lives there and nowhere else. It is not in any database. It has never been transcribed. It exists only because someone has been showing up to the same job for a long time.
You cannot scrape it. You cannot buy it. You can only earn it, slowly, by being trusted enough for people to share it — and then encoding it into the system carefully, with human hands in the loop.
What does this mean for the companies building in this space?
It means the products that win are not the ones with the best foundation models. The moat is not the AI. The moat is the contextual layer — and the contextual layer belongs to whoever manages to capture it first, most completely, and in a form that compounds over time. And builds a product around training humans to nurture that contextual layer.
That form is a codebase and, surprisingly, a form of SaaS-like product.
The future winning companies are turning white collars into coders with domain knowledge.
This is the design challenge nobody talks about. Because it sounds hard. And it is hard. But it’s the right problem.
The production engineer who knows everything about that Tuesday vibration problem needs to become the person who owns the code that handles it. Not a software engineer — they don’t need to be. But someone who understands enough about the codebase to nurture it, extend it, and keep it aligned with what’s actually happening on the floor.
That’s a new kind of worker. Part operator, part developer, part institutional memory keeper. They exist at the intersection of domain knowledge and technical fluency — not deep on either end, but uniquely capable of bridging both.
The goal is not to replace these people with AI. The goal is to give them a superpower they didn’t have before — the ability to turn what they know into software that runs without them.
The economic logic is compelling. One person who can encode contextual knowledge into a compounding codebase is worth more than ten who carry it only in their heads. The knowledge becomes durable. Transferable. Scalable.
In a sense, it’s exactly similar to what happened in factories in early 1900s. Turning doers into coders of machines. Here, the machine is AI.
Getting a production manager to write code — even AI-assisted code — is a product design problem of the first order. The interface has to make it feel like configuration, not programming. The AI assistant has to ask the right questions. The feedback loops have to be tight enough that mistakes surface before they reach the line.
This does not happen with a good UX team alone. It requires what we’ve started calling forward deployed engineers — people who are technically excellent and operationally empathetic, who live inside the customer’s context long enough to understand what the product needs to become. Not account managers. Not implementation consultants. Engineers with enough human range to sit in a factory and understand what they’re actually looking at.
We love a good ol’ challenge.
The companies in our portfolio that are figuring this out are pulling away from the field — not because their AI is better, but because their contextual layer is deeper. Every deployment teaches them something about how factories actually think. That knowledge loops back into the product. The product becomes better at capturing more context. The moat widens.
This is the flywheel. It does not run on GPU hours. It runs on trust, proximity, time, design.
If you’re building in industrial software and wrestling with any of this — or if you’re a forward deployed engineer who wants to work on exactly this kind of problem — we’d love to hear from you. renan@oss.ventures