The question that decides whether it makes sense
Predictive maintenance has been solving the forecasting part for years: the model warns that a bearing is wearing out. What has almost never been solved is the next step, which is where the money is lost: someone has to interpret the alert, check that machine’s history, see whether the spare part is in stock, find out what downtime window is available, and decide.
So the question is whether that step is documented in a system or lives in the maintenance manager’s head. If it’s the latter, the agent has nothing to work with, and the project first becomes a knowledge-capture exercise.
What an agent does here
It picks up the alert from the model or the monitoring system and turns it into a complete proposal: which machine, which symptom, what similar repairs were done before and how they turned out, which spare parts are needed and whether they’re in stock, how long the job takes, and which production windows are coming up in the next few days.
The maintenance manager doesn’t get one more alert. They get a written work order they can approve, adjust, or reject. That’s the fundamental shift.
In the next step, the agent reserves the spare part, opens the order in the CMMS, and notifies the shift. It never decides on a line stoppage by itself — that always takes a human sign-off.
The data you need
Plant signals with reliable timestamps (from PLCs, SCADA, or retrofitted sensors), a work order history that includes the text of what was done, a spare parts master with real stock levels, and the production calendar. The work order history is the gold mine: if the “work performed” field holds real sentences and not “checked OK,” the agent has something to learn from.
How we measure it
Unplanned stoppages avoided and their cost, average time from alert to repair, the share of repairs done within a planned window, and stockouts of critical spare parts. The metric that convinces a steering committee isn’t model accuracy — it’s how many hours of line downtime were avoided this quarter.
Where it fails
In three places. First, signal quality: poorly calibrated sensors generate alerts the team learns to ignore, and from then on the system is dead even if it technically works. Second, alert overload: an agent that proposes fifteen repairs a week at a plant that can handle three isn’t helping — you have to prioritize by cost of failure. Third, building this without a harness and without scoped permissions on the CMMS, a system where a bad write has consequences.
One industry-specific warning: in facilities with safety requirements, any system that influences maintenance decisions enters regulatory territory. Check it against the regulations before you build, not after.