IMTS REACTION: Machine Monitoring Is Dead (As We Know It).

I spent this past week at IMTS 2026. My fifth one. It was as exhilarating as it was exhausting, and as I sit on the plane home with what is left of my voice, I finally have a few free minutes to write down what I saw.

The best parts are always the same parts. Long days in the booth with my team. Dinners with customers who have become friends. Turning a corner in the West Building and running into someone I have known for a decade, both of us a little grayer, both of us still here. Five shows in, you start to notice how much doesn't change. Same aisles, same coffee, same aching feet by noon on day two.

Then, you notice how much has.

Underneath the familiar, something shifted this year. I left that floor with one clear thought: the category we built for this industry has changed.

IMG_4366

(Sidebar: the importance of stretching during a week-long trade show cannot be overstated).

What the floor told me

Countless unactionable dashboards. Countless connectivity devices. "Machine monitoring," they called it. Half of the old competitors had empty booths and tech that looked like it was built in the 90s. Even worse, they are dropping prices, and some are giving it away for free. That tells you exactly what the market thinks it is worth.

Basic machine monitoring is becoming harder to justify as a standalone purchase. To be clear, that is not a statement about the value of the data. Monitoring is becoming a component instead of a product, the same way GPS stopped being a device you bought and became something inside everything else. It got more valuable as it got absorbed. Buying it on its own made sense for years, and plenty of good operators made that call for good reasons. What changed is that the category stopped moving while everything around it accelerated.

We built one of these

I should be clear about something. We started MachineMetrics as machine monitoring software, and it was (and still is) genuinely disruptive. Modern UI and UX, cloud-based, built for speed and performance. The systems available then were MS-DOS. Ours: Apple.

The problem we set out to solve was visibility, because our customers didn’t have it. Manufacturers could not answer what a machine did last shift without walking to it or trusting a paper log. For many, giving a plant manager a live, accurate picture of the floor for the first time was a real unlock, and it changed how a lot of companies ran.

I am proud of what we built, and that visibility layer still matters. It is in every deployment we run. I am also not going to stand in a booth in 2026 and tell you that machine monitoring alone is the answer anymore.

What changed

That was a different world, and while some things remain the same, a lot has.

The technology changed. Capabilities that used to require a data science team and a multi-year roadmap are now something a good platform ships continuously. Systems can reason across an entire operation instead of reporting one slice of it. The ceiling on what software can do for a plant moved so far that the old roadmaps did not fall behind schedule; they became irrelevant.

The people changed. The ones replacing the generation that built this industry grew up expecting software to just answer the question. They will not file a ticket and wait three days for a report. They will work around a tool that makes them, and that is how good systems quietly die, four months after go-live, with nobody sending an email about it.

Most of all, the pressure on manufacturers has changed. Reshoring, supply chains that still have not settled, labor you cannot hire your way out of, customers demanding shorter lead times at lower prices. Manufacturers are being asked to do more, faster, with fewer people, and the margin for a slow decision keeps shrinking.

Visibility itself doesn’t solve those problems.

The value curve flattens

There's a familiar story you’ll hear from those who implemented machine monitoring over the past decade, and that story has a similar shape. The first six months were great, maybe the first few years. You found the obvious downtime, you settled some arguments with real numbers, you got a utilization lift that paid for the system. Then it leveled off. Or the champion left. Now, no one is really using it anymore, and the value can’t be justified.

value_curve_plateau_vs_platform

That is not a failure of execution. It is what happens when a product has a fixed ceiling. Once you have harvested the obvious, there is nothing underneath to go deeper into. The tool told you what it was built to tell you, and it will tell you the same thing next year.

The scaling problem is the same problem wearing a different shirt. Adding the eleventh machine works. Adding the third plant is where it breaks, because every site names things differently, runs different processes, and needs different logic. Most of these systems were architected for one site and one use case, so scale gets handled with more spreadsheets, more admin work, and eventually a second system nobody wanted to buy. Manufacturers end up managing the tool instead of the operation.

A system that plateaus is not an investment. It is a purchase you have to repeat.

The other half of the floor

The part nobody is writing about is the part that gave me hope.

For every booth selling a 1990s product with a 2026 label on it, there was a manufacturer walking the floor who was genuinely impressive. Shops that have grown fast, taken share, and pulled work back onshore. Ask them how, and they do not talk about a dashboard. They talk about their systems. They talk about the decisions they can make now that they could not make three years ago. They talk about how many of their people can get an answer without filing a ticket. I may have audibly gasped when one customer used the words “knowledge graph”.

These manufacturers are not waiting for the industry to catch up. They are already operating the way the rest of the market will have to operate in five years. That gap is what the floor actually showed me, and it is widening.

The AI claims do not pass the sniff test

Most of the software this industry runs on will not survive the next few years of AI. Neither will the manufacturers who treat AI as a pilot project.

To see how thin the moat really was, we rebuilt dozens of these products on our platform using AI. It took days, not quarters. I am happy to walk anyone through what we built and what it cost us.

People ask how that is even possible. It is possible because the hard part was already done, years ago, and it was never the interface.

Most of these products are a thin application sitting on top of a pile of raw machine signals. Everything that makes the application useful, knowing that this spindle load belongs to this part on this order for this customer, has to be hand-wired into the product itself. Rebuild the product, and you rebuild all of it.

We do not carry that weight. Our data model already represents the entities of a manufacturing business and how they relate. The context layer already holds each customer's own definitions and logic on top of it. The knowledge graph already connects those entities so a question can travel across them instead of stopping at a table boundary. By the time you go to build an application, the meaning is already there. The application is just a view.

The last piece is that our platform exposes all of it to AI through MCP, so an agent can reason against a customer's real, structured operation rather than guess at a schema. When a model can ask the graph what is true, building a new application stops being a development project and becomes a matter of describing what you want.

That is the part competitors cannot copy by adding an AI tab. You cannot bolt a data model onto a product that was designed without one.

Build applications. I do not mean hire developers. Carbide is the part of our platform that lets anyone generate an application by describing what they need, in plain language, against their own live operation. No code, no ticket, no roadmap. The scheduler, the quality manager, the continuous improvement lead can each build the thing that solves their own problem. Nobody knows your process better than they do.

Building the platform underneath is a different job, and it is the one AI does not shrink. Modeling an operation so it holds across a job shop and a multi-plant enterprise. Learning every way a machine lies about what it is doing. Keeping context intact when a customer changes a routing or renames half their part numbers. Every one of those is boring until you hit it, and then it stops the project cold. It also never finishes, because it has to keep working for years while your business changes around it.

That is what an operating system is for. Your people build what makes you money. The platform handles the part that never should have been your job.

That exercise was not a victory lap. It was a warning. If a whole product category can be reproduced that quickly, the product was never the value. The value is underneath it.

How to tell a real AI company from a phony one

Ask four questions. The answers separate the two groups fast.

What shipped in the last 90 days? Real AI companies rebuild constantly, because the ground moves under them every quarter. Phony ones demo the same screen they showed you last year with a new badge on it.

Does it run on my data, live, right now? Not a curated demo environment. Your machines, your part numbers, your naming conventions, your mess. AI that only works on clean sample data is a slide, not a system.

What happens when it is wrong? Real answers involve how the system shows its work, where the number came from, and how it corrects. Phony answers get quiet, or get defensive.

Is AI the architecture or a tab? If you can click away from the AI and the product works exactly as it did before, it was never AI. It was a chatbot bolted onto a reporting tool.

The real opportunity is not the dashboard

operating_system_stack_layers

Here is what the companies that are accelerating understand, and the rest of the market has not caught up to yet. The opportunity is not smarter charts. It is six things underneath, and they compound.

The data model. Machine data on its own is close to worthless. A spindle load reading means nothing without the part, the program, the operator, the tool, the order it belongs to, and the customer waiting on it. A real data model captures those relationships from the start instead of asking you to reconstruct them later in a spreadsheet. Everything above it is only as good as this layer, and this is the layer most vendors skipped.

The data context. Is 60% utilization good or bad? You cannot answer that from the machine. It depends on how much work is in the building, what is promised, and when it is due. A number without that context is trivia. This is the missing link in machine monitoring: the machine data has to meet the order, the routing, the due date, the customer. Without ERP in the picture, you are watching a machine. With it, you are running a business.

Two plants can run identical machines and mean completely different things by the word "downtime." Context is the business logic that makes your data yours: your definitions, your routings, your standards, your exceptions. Software that ignores this forces you to change how you operate to match the tool. That is backwards. The system should mold to how you do business, not the other way around.

The knowledge graph. This is where the first two stop being storage and start being usable. A knowledge graph connects every entity in your operation to every other one, machine to program to part to order to customer to supplier to operator, and keeps those relationships live as things change. Tables can answer what happened. A graph can answer why, because the path between the symptom and the cause is already mapped.

It is also the difference between AI that guesses and AI that knows. A language model pointed at a pile of disconnected tables will produce a confident answer it cannot defend. The same model pointed at a graph can traverse the actual relationships in your business and show you the path it took to get there. Ask why a customer's orders keep slipping and the system can walk from the order to the routing to the machine to the tool to the maintenance history, and hand you the chain. No specialist required, and nothing invented along the way.

The platform. Standalone products stop where the vendor's imagination stopped. A platform keeps going, because new capability builds on what is already there instead of starting over. This is why the rebuild experiment mattered. When the model, the context, and the graph are right, a new application is days of work, not a two-year roadmap item you are told to wait for.

Configuration at scale. Out of the box was the right answer for an era when customization was genuinely too hard. Every change meant custom code, a services engagement, a version you could never upgrade, and a vendor who dreaded your ticket. So the industry standardized, and manufacturers were told to adapt their process to the software.

That tradeoff no longer exists. Configuration is now cheap, fast, and safe to maintain, which flips the entire calculus. The product that matches how you actually run will beat the generic one every time, and the gap is not small. Your process is not an inconvenience to be standardized away. It is frequently the thing you compete on.

This is also the single biggest predictor of whether a deployment sticks. Systems that fit how people already work get used. Systems that demand new behavior get abandoned. Ask any vendor how much of what they sold you two years ago is still in daily use, and watch what happens.

Operator empowerment through knowledge capture. This is the one I would underline twice. Start with what we are not asking for. Operators do not need another screen. Most plants have already given them four, one for the drawing, one for the job, one for quality, one for whatever got bought last year, and the honest response to a fifth is to ignore it. A single place to do the whole job is the bar. Beyond that, the goal is not to ask operators to put more in. It is to automate what we can and augment the rest, so the system carries the work instead of adding to it. Knowledge capture only works if it happens as a byproduct of doing the job, never as an extra task.

I said earlier that the people changed. Here is the other half of that. Your best process knowledge is not in any system. It is in the operator who knows that machine runs hot on Tuesdays, the setup guy who has a feel for that fixture, the supervisor who knows which jobs to sequence together and why. That knowledge walks out the door every time someone retires, and this industry is losing it faster than it is replacing it.

For most of our history, getting an answer out of your data required a specialist. An engineer, an analyst, a consultant, a ticket, a queue. That bottleneck defined how fast any company could improve, and it also meant the people closest to the work had the least access to the information about it.

AI changes both halves of that, but only if the layers beneath it are real. When they are, the operator at the machine can ask a question in plain language and get an answer grounded in the actual business. More importantly, what that operator knows can be captured as they work and made available to the next person who hits the same problem, instead of living in one person's head until they leave.

You go from a handful of people who can interrogate your data to everyone who needs to, and from institutional knowledge that leaks to institutional knowledge that compounds. That is not a productivity feature. That is a different rate of improvement for the entire company, and it is the single biggest source of advantage available in manufacturing right now.

Who you buy from is a critical bet

Look at what AI has already done to software outside of manufacturing. Companies that looked permanent a few years ago have been acquired, gutted, or quietly shut down, because their entire product became a feature of something else.

That is the risk you take on when you sign a contract. You are not just buying software. You are betting on whether that company still exists, and still matters, in five years. The technology you invest in today defines the business outcomes you get tomorrow. Buy the past, and you will operate in it.

I was fortunate enough once to get some advice from a revenue leader for a billion-dollar SaaS business. “You don’t have to sell to everyone. You just need to sell to the ones who see where this is going, and the others will eventually follow.”

That is not a knock on those who are slower to adopt new technology. Conviction is simply what separates the companies that move now from the companies that move in five years. I met plenty of the first group at IMTS. They were the ones growing, and they understood the difference.

Operating systems are the present and the future. Connected systems, contextualized with your data, built for your business. If you see what is coming and you know what you want your business to be, come build it with us.

Until then, I’m going to lay my seat back and close my eyes, because I have a feeling I’m going to need some rest for what’s next.

IMG_4336

(Somehow, this may be the only picture we've ever gotten together over the years.)