Skip to main content
Don't let an algorithm decide what you read JOIN 500+ SUBSCRIBERS →
Back to newsletter
Edition #18 February 27, 2026 7 min read
Read in: nl de

AI in the Factory: Three Levels in Production

Why off-the-shelf AI agents do not work without the right data structure, and how three levels of AI, answering, doing and building, transform your factory.

The previous editions of this newsletter covered the two foundations of digital transformation in metalworking: what a Unified Namespace is and why it is the foundation for everything that follows, and what an MES system is and how you can start with one today. Today it all comes together: AI.

AI is misunderstood in industry. Not because it does not work, but because we approach it as something you buy.

An agent here, a chatbot there. Fine as a starting point. But you miss the full potential.

The problem with “buying an agent”

You get a call. Companies that want to build an AI agent for your email processing. Your ERP vendor, Business Central, Odoo, SAP, announces they are “doing something with AI.” Someone offers you an AI-powered planning tool.

That is all fine. But what do you have then? An agent that lives inside your ERP. It knows orders and financials. But it has no idea what your machine is doing. It does not see a quality issue. It does not know your material is arriving late.

Imagine hiring a new employee. They need to know: which orders are running? What is the machine status? Where are the drawings? Right now that person has to look in three, four systems. An off-the-shelf AI agent has exactly the same problem. And if you buy five, one per system, you have five colleagues who do not talk to each other.

That is the spaghetti problem you know from integration, I wrote about it before. Now with AI. And it makes agents inefficient too: the more systems an agent has to search through on its own, the more computation, and the slower and more complex the whole thing becomes.

AI is a tool, not a product

What almost nobody realizes: AI can now not only answer, but also do and build. Not in the future, now.

I distinguish three levels:

Level 1, AI that answers. Chatting with your data. “What is the status of order X?” Useful, but not a breakthrough. Most companies are here.

Level 2, AI that does. Processing orders, updating statuses, flagging problems. Taking over real work. Think about rescheduling two delayed orders through a conversation with the AI, and the adjustment actually lands in the system.

Level 3, AI that builds. Dashboards, apps, connections between systems. Things you would normally have a software company build. Having a dashboard generated from production data, without writing a single line of code yourself.

Industry is stuck at level 1. The real opportunities are at 2 and 3.

And to make it concrete: the ERP system I use in demos, I built myself with AI. The database, the screens, everything. Not because I am lazy, but because it is faster, better and more consistent.

How AI can actually work: the back door and the menu

Okay, AI can do and build. But how? How does an AI adjust an order in your ERP?

Almost every modern software system has an API, the back door of your software. When you click “create order” in your ERP, that button sends a command to the database. An API makes that same command available to other systems, or to an AI.

And for that, something called MCP was created: Model Context Protocol. MCP is a menu for your AI. You describe which actions are available, what they are for, and how they work. Compare it to an instruction sheet for a new employee on their first day: these are the systems, this is what you can do with them, this is how it works.

Without that menu, an AI can only talk. With that menu, an AI can work.

And the beauty of it: you do not need to replace your existing software. If it has a good back door, you can put such a menu on it. Not just your vendor’s AI product, any AI can then work with it.

That is why this might be the most important question with every software investment: does it have a good back door? Because without that back door, no AI can work with it. Then your software is a dead end.

The key: your data structure

Now you understand that AI needs a menu. The question is: where do you hang it?

Option A: on each system separately. But then you get exactly what you already know, spaghetti. Five connections, five maintenance points. And an agent that has to search through all those systems on its own is slow and hard to manage.

Option B, and this is where it gets interesting: one central point.

This is where the Unified Namespace comes back. All your systems send their data to one central point. Your ERP sends order data. Your machines send their status. Your MES sends production progress. Everything at one address, structured, with context attached.

And then you give the AI one menu: the one for the central point. One connection, access to everything.

The AI participates as an equal, just like your ERP, your MES, your machines. Not on top as a loose add-on. Inside, as a colleague who has access to the same information as all other systems.

Concretely: via an MCP connector on a UNS you can ask the AI about the status of the welding robots in a factory. It immediately knows which cell is active, which is inactive, and can build a dashboard on that, because the context is already embedded in the structure of the namespace.

But, and this is an important point, you are not going to send all data from all systems to the AI. It would drown. The discipline lies in what you publish: the right data, at the right address, with the right meaning attached. Not a data swamp, a structured hub. That starts with the data you actually collect.

UNS and AI are complementary, not competing

There is a question I get regularly: why do you need a Unified Namespace if you have an AI agent that can query systems on its own, or even write its own middleware?

The answer lies in the difference between two problems.

The UNS solves the infrastructure problem: reliable, real-time, semantically structured data that is available to everything and everyone, not just AI, but also machines and other systems that need data deterministically and without delay. A conveyor that knows what the machine upstream is doing does not need AI. It just needs data, on time.

The AI solves the reasoning problem: what should you do with that data?

An AI that operates on a well-structured UNS is dramatically more powerful than an AI that has to scrape systems or guess schemas on its own. Because the context is already baked in. The AI does not need to figure out what a value means, that meaning is already embedded in the structure of the central point.

The chain is simple: your data structured in one place, a menu for the AI, and the AI gets to work.

The human side

I want to say this very clearly: AI is not meant to take away jobs.

I work with a lot of creative people in my client companies, people who handle preparation, who operate the machines themselves, who see where the opportunities lie. They have been given enormous new capabilities. Do more, do it faster, no more bottlenecks from external parties.

We have too little inflow of new talent in metalworking. The barrier to entry is too high. There is more than enough work. Much of what people do now is essentially robot work, copying data from one system to another, manual printing, manual lookups. That is work not meant for humans.

People are creative. People should be searching for ideas and solutions. When AI takes over the robot work and lowers the barrier to entry, you are using it effectively.

AI is an enabler. Embrace it.