Turning Manufacturing Tribal Knowledge Into Working Software: FABTECH 2026 Takeaways

Rutherford Wilson, our Chief Product Officer, started his FABTECH session the way he starts most of them: by asking the room a question. Who here uses an AI tool as part of their job? Almost every hand went up. What do you use it for? Spreadsheets, someone said. Reports. One shop had wired it into their CRM. Someone in the back called it a glorified search engine, which got a laugh.

Nobody said production.

That was the show for us in one exchange. We spent three days in Las Vegas (October 21-23, booth S39017) talking to fabricators who are clearly comfortable with AI and have no way to point it at the work that actually makes them money. Rutherford's session was about closing that gap, and it was also the first public look at what's coming next for Carbide. Here's what we took away.

How manufacturers turn tribal knowledge into working software

If you want the process without the story, here it is. Start with one thing that lives in someone's head: how to clear a particular fault, which machine a part runs best on, whether a four-day job is actually on pace. Make sure the machine and ERP data that the decision depends on is connected. Describe the workflow in plain language to a build agent that checks it against real production history. Deploy the app where the work happens, let the people who use it refine it, and move on to the next one. Every app you build adds data the next one can draw on.

A quick note on names, because we use three and they are not interchangeable. MaximaOS is the platform: the AI-powered manufacturing operations platform from MachineMetrics that connects your machines and business systems and runs the core MES functions (scheduling, work order management, job tracking, downtime and OEE). Max AI is the AI built into it. Carbide is our Build layer, and how you build your own apps on MaximaOS. If you have developers, Carbide for developers has let them code apps since September. If you don’t, the in-browser version ships in mid-December: describe the app to Max AI in plain language and Max builds it, no coding experience needed. That’s the version we previewed at the show.

Fabricators are using AI in the office, not on the floor

The show of hands set the pattern, and three days at the booth confirmed it. These are not people who are afraid of AI. They use it every day. It just has no idea what is happening on their floor, because it can't see the machines, the jobs, or the ERP. A few things came up in nearly every conversation:

• The ERP has the plan. Nobody has the shift. Shops know what was supposed to happen. What they can't see, while it is still fixable, is whether it is happening.

• Nobody wants to build from scratch. We heard this a lot. People want something that works on day one and bends to how their shop runs, not a toolkit and a six-month integration project.

• Fabrication has a bigger gap than machining. Walk the machining side of a show, and most shops have something between the ERP and the floor. Walk FABTECH, and far fewer do. The gap is wider, and so is the appetite to close it.

Tribal knowledge needs production context, not just documentation

Rutherford told a story about one of our customers in the UK. Third shift, a fault alarm comes up that nobody on shift has seen before. The one person who knows how to clear it is at home asleep. It turns out the fault had come up before and been solved before. Nobody wrote it down. They lost a full shift across three machines.

The obvious lesson is "write it down," but a page in a binder would not have reached that operator at 2 a.m. either. Knowledge is only useful when it shows up attached to the thing it applies to: this fault, on this machine, for this job. That is what connecting machine data and ERP context in MaximaOS gives you. Run your jobs and the system learns how your shop actually works, as a byproduct. The stuff that lives nowhere else goes into Knowledge Hub, and Max AI can surface it for whoever is standing at the machine, on whatever shift.

Machine data makes tribal knowledge testable

Rutherford asked a second question: who knows their utilization rate? No hands this time. Across roughly 100,000 machines we have connected over the last decade, the average shop runs at 26.8%. Top performers are around 85%. Most shops are measuring by having an operator write "down three hours" on a sheet, when the machine was really down four, and two of those hours were a fault the controller already knew about.

Real machine data does more than settle arguments about downtime. It lets you check whether the things everyone "knows" are actually true. One of our customers runs multi-day jobs on Swiss machines, and their planner had lost any sense of whether a job was ahead or behind until it was done. They built a job pacing app in Carbide. The first thing it flagged was a job running slow on a machine where someone had tested a new part, left the feed rate override at 25%, and walked off to tend three other machines. The machine had been quietly running at a quarter speed. Nobody on the floor caught it. The data did.

Shop floor software has to handle exceptions

You find out the difference between documenting a process and building software for it the first time the process doesn't go to plan. Rutherford walked through an in-process inspection app built in Carbide against a customer's spec. The first version took about 20 minutes. Partway through, the customer decided they wanted photos of the feature being inspected, so photos went in. Then came the part that actually mattered: making data entry easier. Nominal values pre-fill from the inspection criteria in Knowledge Hub. If the reading matches, one tap. If it drifted, type the last two digits. If it's the same as last time, tap "same as last." Another 20 minutes, and they had a working app before the end of the day. The photos and the shortcuts came up while it was being built, not before. That's the point.

What MachineMetrics showed and discussed at FABTECH 2026 (and what is still on the roadmap)

Rutherford also described an automotive supplier where a machine learning model on high-speed FANUC data flagged anomalies in tool load. They expected tool breaks. What they found was bad incoming material. When the model sees an anomaly, MachineMetrics triggers a program the customer wrote that safely stops the machine and notifies the team.

One more data point. One manufacturer's developers built seven apps within five working days of getting Carbide for developers, covering shift handoffs, downtime, production reviews, quoting, and material tracking. From mid-December, it gets faster: Rutherford's way of describing it is to treat applications like documents. You change the description, the platform rebuilds the app, and every version is kept. Build one for a problem you have today and throw it away when it's solved.

Is AI-built shop floor software secure?

It’s the right question to ask, and the answer starts with how the apps are built. Veracode’s 2025 GenAI Code Security Report tested more than 100 AI models on 80 coding tasks and found the generated code failed security tests in 45% of cases. Fast code is not automatically secure code, and every new codebase is another thing to review, patch, and maintain.

Starting in mid-December, apps built in Carbide's in-browser builder take a different approach. An AI agent, Max AI or your own, defines what the app needs, and MaximaOS assembles it from manufacturing components our engineers built and tested. No new application code is generated. Google's A2UI follows the same principle for AI-generated interfaces: Google warns that "running arbitrary code generated by an LLM may present a significant security risk," so A2UI lets agents request trusted, pre-approved components instead. The in-browser builder applies that principle to manufacturing apps.

So an app built this way has no code to review, no API key sitting in a prompt, and no password waiting to be discovered. It runs inside MaximaOS and reaches only the connections you've approved. MachineMetrics runs annual penetration testing and is ISO 27001-certified. Your developers can bring their own AI tools: Claude and other agents can build these apps through our MCP tools, and MachineMetrics validates and hosts them the same way it does apps built with Max.

Carbide for developers, available today, is for teams that want to write and host their own code. Those apps follow your team's review and security process, like any custom software.

Watch the full session: MachineMetrics CPO Rutherford Wilson at FABTECH 2026.

What's next for Carbide, the app builder in MaximaOS

For as long as there has been manufacturing software, you have had two options. Buy something off the shelf and bend your process to fit it, or pay someone to build exactly what you need and watch it stop evolving the day they hand it over. Most shops bought, and the gaps turned into spreadsheets, whiteboards, and travelers. AI takes that trade-off off the table. Here's what comes next:

• Describe it. Save it. Run it. In mid-December, the Carbide build experience ships inside MaximaOS. You describe the app in plain language. The Max AI build agent pushes back: ask for a scrap tracker, and it asks which scrap costs most, where to start, and who should act when scrap spikes. It checks your plan against your data and tells you when there isn't enough history to trust a trend. Save it, and it builds. Your designated approver decides when it reaches the shop floor.

• Built from manufacturing parts. More than 80 components made for the shop floor, with more on the way. Teams use them to build setup sheets, work instructions, checklists, inspections, supervisor task boards, shift handoffs, scrap and yield reports, and quoting tools. A lot of those apps never touch machine data at all.

• Context from day one. Apps draw on a knowledge graph that already links machine data, ERP records (15 ERP systems today), and whatever you put in Knowledge Hub. More business-system connections are planned for early 2027.

• More to build with. More building blocks, more connections, and workflows Carbide generates for you. The people who know the work will build the software that runs it.

Frequently asked questions

How can manufacturers capture tribal knowledge?

Attach it to the context it belongs to instead of filing it somewhere. Running jobs in MaximaOS captures how the shop runs on its own. The know-how that lives nowhere else goes into Knowledge Hub, where Max AI can surface it on the job that needs it.

What is the difference between documenting a process and building working software for it?

A document describes the happy path. Working software handles the exceptions, runs where the work happens, and records what people actually did, so the next version is better than the last one.

Is Carbide available today?

Yes. Carbide for developers has been in early release since September 2026. Your developers build apps with Claude Code, our MCP server, and the Carbide component library, then host and register them so they appear on the screens your operators already use.

From mid-December, building isn't limited to developers. Anyone who knows the process can describe the app to Max AI, or have their own AI agent build it through our MCP tools, and MachineMetrics validates and hosts it. Carbide for developers stays available for teams that want to own their code and host it themselves.

Why does manufacturing AI need machine data and ERP context?

A cycle time means nothing without the part, program, and order it belongs to. 60% utilization is good or bad depending on how much work is in the building and when it's due. General-purpose AI has neither piece of context, which is why the fabricators we met use it for spreadsheets and not for production.

How should a plant validate an AI-built application?

Build it against real production history, not sample data (the Carbide build agent will tell you when the history is thin). Put it in front of the people who will use it and refine it there. The inspection app picked up its shortcuts in a second session. And before it goes live, confirm what it can access.

Bring us a process. Leave with an app.

If there's a spreadsheet your team rebuilds every Monday, a handoff that loses something between shifts, or a question about the floor you can't answer without walking out there, bring it to us. Request a working session,  and we'll turn it into an app on your own data.