.png)
At the IMTS Industrial AI Conference in Chicago, our Chief Product Officer, Rutherford Wilson, took the stage with Steve Blackwell, who leads the Worldwide Manufacturing Center of Excellence at AWS, and opened with a question for the room: who here is already using AI in their shop? The hands came up slowly. One team reviews work packages against safety and compliance standards. Another uses it for engineering problem solving.
The rest of the session hung on why those tools work at all. They are useful because they know something. They know who you are and what you are trying to get done, and somebody gave them that context by using them.
Almost nothing in your plant has that. Your ERP holds a plan that stopped being true at 9:40 this morning, when a hot job jumped the queue and a setup ran long. Your best troubleshooter holds twenty years of pattern recognition that exists in no system anywhere and retires in eighteen months. Rutherford spent his ten minutes on what it takes to give AI enough context about your operation to be worth anything on a floor, and on what manufacturers are already building once it has that.
Watch the full session: Rutherford Wilson on bringing industrial AI to the machine shop floor, from the IMTS Industrial AI Conference.
These tools work because you taught them
The AI tools your team uses every day are useful because they have context. They know who you are, what job you are trying to finish, and how you like to be spoken to. You gave them that context by using them.
Your shop runs on the same principle, without the software. You have an operator who can put a hand on a machine and tell you it will have a problem in the next ten minutes. That knowledge is not in your ERP and it is not in your bill of materials. It is in your people. And as Rutherford put it to the room: Jimmy is going to retire in eighteen months. So what are you going to do about it?
Getting that knowledge into a structured form, where the next operator on the next shift can reach it, is the work.
Start with what the machines actually did
Before any of that, a shop needs a record of what happened.
MachineMetrics connects directly to CNC machines, and to welding and other equipment, and reads real-time telemetry off the control. When we walk into a shop, the team usually tells us utilization is in good shape, somewhere in the sixties. Then the software goes in and the measured number comes back far lower. The gap between what a shop believes about its capacity and what its machines report is often the single largest unclaimed asset on the floor.
That is one kind of execution gap, and there are dozens more. The tool needed changing. Material did not reach the machine. A setup ran forty minutes long. A job sat waiting on first article inspection while the spindle stayed idle. Very few plans survive the shop floor, and they come apart in small increments all day rather than in one dramatic failure.
Connecting the machines and connecting the ERP puts the plan and the reality side by side while the shift is still running. You cannot stop an operator from calling out or a setup from running long. You can know about it in time to move work.
No vendor's software does exactly what you want
Here is the part most software companies will not say out loud. Rutherford said it from the stage: as much as vendors like us would love to tell you our software does precisely what your business needs, it is not true, and saying it would be lying to you.
Every shop operates differently. Every vendor tells you the product is configurable, and that is true, but configuration has a price. Ask what it costs to get a systems integrator to build one application against your enterprise ERP. Nobody in that room could get it done in a month. A good scope and a fair quote still leave you waiting, and by the time the application arrives the problem may not be your problem anymore. That is worse than expensive.
That's why we built MaximaOS
Most of what happens in a machine shop is common work. Jobs get dispatched. Machines run and parts get counted. Downtime gets attributed, labor gets recorded, and the ERP has to hear about all of it before anyone can quote the next job. None of that should be a project. It ships complete, it stays configurable, and we maintain it.
Then there is everything else. The extra inspection step one customer demands and nobody else does. The way third shift hands off to first. The report your plant manager rebuilds in Excel every Monday. Buy a rigid system and each of those turns into a change order with a quote and a queue behind it. Buy a build-it-yourself platform and you own an application layer for as long as you run the business.
MaximaOS closes that space from both directions.
Underneath the platform runs Max AI, built for discrete manufacturing. It answers from your data: every sensor reading, on every machine, on every job, on every shift, tied to the work your ERP says you are running. Ask Max AI where your setups are running long and you get an answer grounded in what your control reported this morning. It runs on AWS, in commercial cloud and in GovCloud.
And for the work that is genuinely yours, there is Carbide.
Carbide is the application layer of MaximaOS, and it is how a shop gets the last ten percent built without hiring an integrator. The Carbide Design System is available now: 80+ manufacturing-aware components, which matters more than it sounds. A standard date picker assumes a day runs midnight to midnight. Your third shift does not, and Carbide's components already know that. Templates cover common starting points like tool life, dispatch, supervisor inbox, and inspection capture.
The Carbide Application Builder goes further. Describe the application your floor needs in plain language, and build it against your own live production and ERP data. It is in beta, and we are building with customers today. In the beta, it also argues with you, which Rutherford considers the feature. It will tell you when it does not have enough information, or when what you asked for is not what you should build. That is closer to a good consultant than a chatbot.
What manufacturers are already building with it
Two applications Rutherford walked through, both solving problems the core product was never going to solve for everyone.
A cycle time validator. It takes the actual cycle times measured on the machine for a job, baselines them across every prior run to get a median, and compares that to the expected cycle time sitting in the ERP. Where the two diverge, you have a standard worth correcting.
A planner's view of fast and slow jobs. A Swiss shop planner in Michigan wanted to know which jobs were running ahead of their expected cycle and which were falling behind, live. This app was built in two days. Because the platform counts every completed cycle off the control, the comparison happens in real time. Jobs near the baseline are fine. The ones running slow tell a supervisor which machine to walk to and why.
Neither of these predicts the future. They put a specific number in front of a specific person while there is still something to do about it, which is most of the job.
Start with one problem
The manufacturers getting real value out of AI right now are not the ones with the most ambitious plan. They pick one thing that is costing them money, fix it, confirm it worked, and go find the next one. If the problem goes away, they stop using the application and build something else. Do that twelve times in a year and you have a floor that runs on what actually happened rather than on what somebody assumed in 2019.
That is the operation we are building toward with our customers. Standards that match the machine. Knowledge that outlasts the person who has it. A shop where the answer to "how are we doing" takes a glance instead of a morning.
See It in Action. If the gaps between your plan and your production are costing you capacity and delivery dates, come see how we close them.