Plenty of plants already have working models. Vibration signatures get scored, thermal trends get flagged, and dashboards light up. Yet maintenance teams still work reactively because an alert that never becomes a planned and scheduled work order, with the necessary parts reserved and the completed work verified, is just a notification.
That is the gap prescriptive maintenance exists to close, and it is an integration problem long before it becomes a modeling problem.
Prediction is the easy half. The hard half lies between the model and your CMMS. Someone has to assess the alert, determine the appropriate action, reserve the necessary parts, find an available window in the production schedule, and confirm that the repair worked.
This article walks through that process from end to end for the reliability leaders and CTOs responsible for approving it.
The Maturity Ladder, With Testable Criteria
Marketing often collapses every level into one word: “AI.” A useful self-assessment needs a clear test for each level.
- Reactive. No signal precedes the failure; the trigger is a stopped machine.
- Condition-based. A variable crosses a defined threshold. Test: does the alarm fire according to a rule documented in the system’s configuration or control logic?
- Predictive. A model estimates remaining useful life or failure probability with sufficient lead time. Test: can you compare predicted and actual lead times for each asset?
- Prescriptive. The system returns a ranked set of actions and their consequences, not just a risk score. Test: does the output identify the recommended action, required parts, and tradeoff of deferring the work?
- Agentic. The action is executed in a system of record and then verified. Test: is there a work order with a machine-generated origin, a closure code, and post-repair confirmation that the signal returned to baseline?
The most important business distinction appears in the final two levels. Prescriptive maintenance adds a decision layer. It considers the prediction, spare-parts availability, production schedule, and cost of deferral before ranking the available actions.
Agentic maintenance adds an action layer: access to the necessary tools, permission to write to the system of record, and an obligation to report the outcome. Autonomy is an architectural and governance property, not simply the result of a smarter model.
The direction is clear. The World Economic Forum’s Intelligent Industrial Operations Outlook 2026 describes industrial operations moving from traditional automation toward intelligent, connected, and increasingly autonomous systems. It also outlines a progression from assisted intelligence to more adaptive and self-orchestrating operations.
What remains unresolved on any given plant floor is who—or what—has permission to write to the CMMS.
The Closed-Loop Architecture, Layer by Layer
The system runs from the machine to the executed job and back:
- Asset and sensing layer. PLC and SCADA tags, along with retrofit IoT sensors, provide vibration, current, acoustic, and temperature data that the original control system may not capture.
- Data backbone. OPC UA provides structured access to OT data, while MQTT handles telemetry. A unified namespace ensures that every system reads from the same asset hierarchy, and a historian retains data at the resolution required to understand the failure.
- Prediction layer. Anomaly detectors, remaining-useful-life models, and vision classifiers are versioned with clear lineage back to their training data.
- Prescriptive decision layer. Constraint-aware reasoning evaluates predictions, parts availability, labor, and production windows.
- Action layer. Deterministic writes into the CMMS, EAM, and ERP create the work request, attach supporting evidence, reserve the required parts, and propose a maintenance window.
- Feedback loop. Technician findings, closure codes, and post-repair signal behavior return to the system as labeled data.
The choice between edge and cloud deployment should be based on latency, not preference. Inference that directly controls or gates a machine action belongs at the edge. Model training, fleetwide comparisons, and agent orchestration can be managed centrally.
Many stalled programs are actually data-modeling failures disguised as AI problems. They lack a canonical asset hierarchy that connects CMMS identifiers with historian tags, or a failure taxonomy that maps failure modes to codes and recommended actions. Without that taxonomy, a prescriptive maintenance system has nothing meaningful to prescribe.
Two layers often determine whether the system is adopted.
Computer vision as retrofit sensing. Cameras can capture conditions that traditional sensors may miss, including belt fraying, coupling misalignment, seal leaks, gauges on unnetworked machines, and thermal hot spots. They also provide something telemetry cannot: visual evidence that can be attached to a work order.
A work order that includes a cropped image and timestamp is easier for a technician to evaluate than one containing only an anomaly score. This is where computer vision development fits into a maintenance program as an additional sensing layer, not a separate technology showcase.
The integration contract. Treat the CMMS write path as a contract, not merely a plugin. Define the permitted operations, required fields, evidence-attachment format, reversible status model, and idempotency keys that prevent retries from creating duplicate work orders.
OT network segmentation shapes the entire design. Plan for a broker in the DMZ and explicitly review every inbound command path.
Autonomy Control Tiers Reliability Leaders Will Actually Approve
No reliability manager grants a model write access based on a promise. Define clear autonomy tiers with evidence-based promotion criteria instead.
| Tier | Action | Approval |
|---|---|---|
| 0 | Recommendation displayed in the dashboard during shadow mode | None, monitored only |
| 1 | Draft unassigned work request | Planner review before release |
| 2 | Automatically schedule a work order and reserve parts | Planner approval before execution |
| 3 | Make reversible actions within defined constraints, such as adjusting inspection routes or preventive maintenance intervals | Post-action review; action remains revocable |
| 4 | Safety-critical, irreversible, or novel actions | Human-led; no autonomous execution |
Tier 4 is intentionally a restricted category, not a higher level of autonomy.
Promotion should be based on evidence: alert precision at the operating threshold for the relevant asset class, planner acceptance rates over a defined period, and a clean incident history. A policy or performance breach should result in immediate demotion.
Hard stops must remain firm. Lockout/tagout procedures, pressure-system interventions, safety-instrumented functions, and failure modes the system has not previously encountered should remain under human control.
Agent failure modes require engineering controls, not hope. These risks include repeatedly pursuing an unresolved goal, selecting the wrong tool, submitting malformed arguments, and drifting as plant conditions change around a stale model.
Countermeasures include rate limits, step budgets, schema validation for every tool call, continuous monitoring, and periodic re-baselining. AWS guidance on operationalizing agentic AI provides a useful framework that emphasizes identity, scoped permissions, runtime guardrails, observability, drift detection, and lifecycle management.
Every agent-issued work order also needs a revocation path: cancel the order with a reason code, release or reverse the parts reservation, and record the event in an audit log.
Cold Start: When Failure History Is Thin
Critical assets fail rarely, which is exactly why supervised failure prediction often lacks enough training data. Ten years of maintenance history may contain only a handful of labeled events for each failure mode.
Start with methods that do not require labeled failure examples: unsupervised anomaly detection built around a healthy baseline, physics-informed features such as bearing defect frequencies, fleet-level transfer across identical assets, and visual condition assessments when sensor history is limited.
Then build data labeling into the maintenance workflow because technician findings become valuable training data. Use constrained pick lists instead of relying entirely on free text, require failure-mode fields, include a “Was this alert correct?” prompt when closing the work order, and capture photos at the point of repair.
A readiness assessment should clearly identify which failure modes can be modeled now and which require a defined period of deliberate data collection, potentially a year or longer.
When the Agent Is Wrong: False-Positive Economics
Every threshold is a bet on which type of mistake the plant is more willing to accept.
Overcall a problem, and you consume inspection labor while risking maintenance-induced failures from unnecessarily opening healthy equipment. Undercall it, and the plant returns to reactive repair.
Neither cost can be represented by a single number. Make both visible for each asset class by tracking inspections that found no fault and failures that escaped after being scored as low risk. Reliability leadership can then choose the appropriate balance explicitly.
Before any work order is created:
- Require corroboration across independent sources of evidence, such as vibration, a change in electrical current, and a thermal or visual indicator.
- Recheck the prediction against the asset’s operating context and known false-positive patterns.
- Match alert volume to the planning team’s actual capacity. A stream of alerts that exceeds the team’s ability to review them will eventually train people to ignore the system.
- Measure production precision for each asset class every month.
- Evaluate precision alongside lead time. A precise alert delivered eight hours before failure provides little value when the required part has a three-day lead time.
Proving Value: A Measurement Plan You Own
Borrowed benchmarks rarely survive a conversation with the CFO. Establish your baseline before deploying anything.
Track unplanned downtime hours by asset, mean time to repair (MTTR), the ratio of planned to unplanned maintenance, and preventive maintenance (PM) compliance. Agree on the definitions in writing because “downtime” often means different things across departments.
Then measure what purely predictive maintenance programs often overlook:
- Detect-to-do latency: the time between an alert and the creation of a work order
- Prescription acceptance rate: the percentage of recommended actions accepted by planners
- Planner override rate: including coded reasons for each override
- Parts availability: whether the required parts are available when the work order is opened
- Repeat-failure rate: whether the same failure returns after agent-initiated maintenance
- Verified-fix rate: whether the monitored signal actually returns to baseline after the repair
Keep a control group of comparable assets operating under the previous maintenance process to provide an honest comparison.
Finally, assign one measurement owner who is responsible for publishing the results, whether those results support the project or reveal that it needs improvement.
Staged Rollout: One Asset Class, One Line
Start with a scope narrow enough to finish.
- Phase 1: Assess readiness. Review tag availability, historian coverage, CMMS data quality, and the depth of the failure history. Select pilot assets based on criticality, observability, and the consequences of downtime.
- Phase 2: Run in shadow mode. Advance only when precision exceeds an agreed threshold and the alert lead time reflects parts availability and production realities.
- Phase 3: Connect the loop at Tier 1. Advance based on planner acceptance rates and detect-to-do latency, with zero duplicate or unsafe work orders.
- Phase 4: Expand autonomy gradually. Promote autonomy one asset class at a time, never across the entire operation at once.
Brownfield realities shape every phase. Legacy PLCs may require gateways, tag standards often conflict, and differences among site-specific CMMS configurations can become one of the largest hidden integration costs during a multi-site rollout.
It is the same lesson presented in the live data backbone discussion for digital twin programs: the integration layer, not the model itself, is where much of the engineering work takes place.
Softarex builds this foundation for manufacturing operations, including retrofit sensing and IoT data pipelines, edge inference on real plant hardware, and integration with CMMS, EAM, and ERP systems designed to extend beyond the first site.
Close the Loop Before You Scale the Models
Maintenance programs will increasingly be judged by the actions they execute and verify, not by the dashboards their models produce.
The operating test fits into one sentence: Take your most recent high-confidence alert and trace what happened next.
If the trail ends at a dashboard instead of a closed work order with a verified repair, the gap is in the loop, not the model.
Next step: Before investing in more predictions, conduct a maintenance data-readiness and loop-gap assessment for one asset class. Review the available signals, failure taxonomy, CMMS write path, and autonomy policy.
Softarex can scope that assessment around your actual PLC, historian, and CMMS constraints and identify the first three maintenance decisions a closed-loop system could improve.
