.png)
Two years of depots, plant floors, and hangars, and what they taught me about prescriptive maintenance.
I got into maintenance by accident, thanks to two things: my husband and my job. My husband is a rocket scientist, a Berkeley PhD who builds things that fly to space, yet what I hear about over dinner is rarely physics. It's a story your maintainers could finish for him: the part that's out of stock with a ridiculous lead time, the machine that's down with no obvious root cause, the test that needs to run today when the one technician qualified to run it isn't scheduled until Thursday. And my job is AI: my company builds agentic software for security-conscious organizations across the public and private sectors, so I spend my days figuring out where the latest AI advances hold up in real operations, and where they're still just demos.
Put those together and one question became impossible for me to ignore: if the friction is that thick on rockets, supposedly the most advanced engineering there is, what does it look like on the fleets, plants, and facilities somebody is paid to keep running every day? I've spent the past two years finding out: walking depots, plant floors, and hangars, and talking to the people who answer for uptime, or readiness, depending on the uniform, and the systems underneath both. Different industries, different assets, identical friction.
Nearly every leader I've talked to has asked the same question: what can AI actually do for us? It's a fair question, coming from a sector the software world has mostly passed over. Plenty of pitches over the years, not much built for them. This is my attempt at a straight answer.
You already know the maturity curve; you've sat through the reactive-to-prescriptive pyramid slide more times than anyone should. So I'll skip the catechism and get to the part that pyramid never explains: knowing a failure is coming and preventing it are two completely different accomplishments. Gartner draws the same line. Their March 2026 research on prescriptive maintenance makes the point that predictive systems tell you something is wrong without telling you what to do about it (How CIOs Should Use AI to Enable Prescriptive Maintenance, Gartner, 30 March 2026). The first is a data science problem, and the industry spent a decade and heroic money solving it. The second is a parts problem, a scheduling problem, a funding problem, and a "who has authority to approve this" problem. That second one is where your operation actually lives, and that's the one that's finally changing.
Gartner defines prescriptive maintenance as software that does both jobs: diagnose the root cause of a fault, and deliver specific, context-aware recommendations for resolving it inside a workable time frame (Market Guide for Enterprise Asset Management Software, Gartner, 20 May 2026). Note what the definition requires beyond diagnosis: a recommendation specific enough to act on, and a time frame it has to fit inside. Those are scheduling and parts constraints, not analytics.
Two things get sold as AI in maintenance: predictive analytics with a new haircut, and a chatbot that reads the manual. The chatbot isn't nothing. Chat-with-the-manual alone has driven a 25% increase in technician capacity in the first weeks of a federal sustainment deployment, which nobody should scoff at. But if a vendor's entire demo is a chat window, they're selling you the floor of what's possible and calling it the ceiling.
What can modern AI do that predictive models couldn't?
The knowledge that decides a repair lives in text, not in time-series sensor data.
It's in the manuals and the service bulletins. Twenty years of work order history holds it, including the closeout where a tech wrote "replaced seal, third time this year, something upstream is wrong" and then, as far as the system was concerned, that sentence ceased to exist. Free-text fields are where your operation's most valuable observations go to die. The parts catalogs have it, and the supersession chains, and the redlines that never made it back into the official procedure. It's in the gap between the configuration your documentation describes and the one in front of your techs, on the flight line or the plant floor. And an alarming amount of it is in the head of the one person who's been on the line since the late nineties.
And here's the part the sensor-first crowd keeps forgetting: a huge share of the equipment that matters isn't instrumented at all. No sensors, no telemetry, no fault codes. Whole fleets of assets that predate the concept of the machine telling you anything. For that equipment, the historical work orders, with notes ranging from meticulous to "fixed it," aren't a supplement to the data.
They are the data. Any technology that can't read that pile of text has nothing to work with.
Traditional predictive models were, functionally, illiterate: they ate time-series data and produced probabilities, brilliant about vibration signatures but unable to read the bulletin that explained what the vibration meant.
Modern AI can read, and this mundane fact is doing more work than any model improvement of the last decade. The starting point doesn't have to be a fault code, because often there isn't one. It can be a tech's plain-language description of a symptom: intermittent grinding under load, pressure dropping after warm-up. When a system can take that description and search twenty years of messy work order history for the pattern, even when it was described in completely different words, then pull the applicable manual section, notice the bulletin that matches, surface what actually fixed it last time, and check the supersession chain to find the called-out part number now maps to something else entirely, it has closed the four-hour research project that currently stands between "something's wrong" and "here's what to do."
Which brings up the objection I hear in nearly every conversation: "our data is a mess." I know. You've probably been told to run a multi-year cleanup before you're allowed to think about AI. That ordering is now backwards. Reading past inconsistency and inferring what a hurried human meant is exactly what language models are good at. Your data doesn't have to get clean first.
It also makes the alternate-parts problem tractable, the one my husband loses entire evenings to. Today, finding an approved substitute is an evening of one expensive engineer's life per part. It should be a shortlist with citations.
Agentic AI is the other half, a dignified way of saying software with hands. It carries out multi-step work across systems. Checking stock in one system, pulling the schedule from a second, verifying the funding line in a third, drafting the work order in a fourth: that traversal used to require either a seven-figure integration project or a human with fifteen browser tabs. Agents do the traversal themselves. Reading plus hands. That's the change, and it lands on the two moments that define your operation: the failure you didn't see coming, and the one you did.
The failure you didn't see coming
Every facility I've visited has a version of this story.
Something breaks. Not the polite failure the sensors flagged three weeks out. On plenty of assets there are no sensors and never were, so the first report comes from a human: "it's making a noise it shouldn't make." The surprise, at 4:40 on a Friday, on the asset that matters most. The scramble that follows, I can now narrate from memory. Dig through history, which means keyword-searching free-text fields and hoping the tech in 2017 described the noise the same way. Find the right procedure and pray it matches the configuration in front of you, because the fleet has three and the documentation acknowledges one. Figure out who has seen this before; discover it's Dave; discover Dave is on leave; call Dave anyway. Check parts; discover the part is available in the system and not on the shelf. All while something important sits broken and someone important asks for updates on the half hour.
Watching a senior maintainer run that triage is like watching speed chess against a machine that's on fire: thirty years of pattern recognition squeezing four hours of research into forty minutes. But look at what's carrying the performance. Fifteen tabs, a binder, and one irreplaceable memory. And that memory is walking out the door. The workforce holding the deepest institutional knowledge is retiring faster than it's being replaced, and you cannot exit-interview your way out of that. Gartner has a name for the counter. They call it experience compression: AI-augmented work that puts expert-level insight in front of technicians at any skill level, and they flag it as most urgently needed in exactly the industries watching their experienced maintenance workforce walk out. What walks out with the veteran was never written in the binder.
Now run the same Friday with an agent in the loop. The tech describes the symptom in plain language, the same sentence they'd say to Dave. The system searches the fleet's history for the pattern, even the entries described badly or barely at all. It finds two prior occurrences, surfaces what resolved them, pulls the procedure for this asset's actual configuration, confirms the primary part isn't on the shelf but an approved alternate is, deliverable Monday, and identifies which on-shift techs have handled this failure class. What lands in front of the tech is a response package with receipts: what this looks like, what fixed it before and where that's documented, the procedure, the part, who can do it.
The division of labor matters here, because it is the design. The human is in the loop at every consequential step. The tech judges whether the historical match actually fits, because "similar symptom" and "same failure" are different things and telling them apart is a judgment call. The tech decides whether the alternate is acceptable for this application, runs the repair, and a certified human makes the final call on return to service. The agent's job is to make sure that human is deciding with everything the operation knows in front of them, instead of whatever they could dig up in the time available. Dave's knowledge, on every shift, without calling Dave. But the judgment is still, always, human. They just start at minute five instead of hour four.
That's response, and for unplanned failures, which predictive tools by definition miss, it's the difference between a bad morning and a bad week. The scramble never made it onto a slide, and it turns out to be the part AI is suddenly good at.
The failure you did see coming
The other moment is the one your predictive investment already handles, right up until it doesn't. A prediction, on its own, is homework. "Compressor 4, trending toward failure, 87% confidence" is not a plan. It's an assignment.
Someone checks stock. Someone checks whether the work can ride along with the inspection already scheduled, because two touches is one too many. Someone confirms the funding line, because the money question isn't a formality (in government maintenance especially), and the person who knows the right line is a specific human with a specific inbox. Someone verifies the cert. Someone drafts the work order and routes it. At most places I've visited, "someone" is the same three exhausted people, and everyone knows their names because their names are on everything.
Prescriptive maintenance means the system does that assembly and arrives with a plan instead of an alert. The work order, drafted, procedure attached. Three candidate windows, ranked, tradeoffs stated: Tuesday bundles with the scheduled inspection but pushes the risk envelope to eleven days; Thursday is safer and costs a second touch. The part, confirmed on the shelf, or the approved alternate with the shorter lead. The tech with the right cert, available in that window. The funding line, pre-validated. Approve, adjust, or reject.
Watch what that does to your senior people. They go from building the answer to judging it, which is a promotion however it sounds. Assembling information is the part of their job that wastes their expertise. Judgment, deciding whether eleven days of risk envelope is acceptable for this asset given what's on the schedule, is their expertise. Every hour your best planner spends toggling between systems to confirm a part number is an hour of judgment you paid for and didn't receive.
This is what "human in the loop" actually means when it's a design principle rather than a compliance phrase. The human is the decision, and the machine's entire job is to make that decision better-informed and faster to reach. Get the arrangement backwards, with the machine deciding and the human approving in bulk at 4 p.m., and you've automated the accountability rather than the work, and everyone on the floor will know it by Wednesday. Gartner's guidance lands in the same place. Their recommendation to CIOs is to treat AI output as a recommendation and have mechanics and engineers apply their own expertise to validate the diagnosis, because pairing machine processing with human context is what catches a hallucination before it becomes an expensive repair. They are direct about the limit: the technology does not replace skilled technicians. Vendors should be too.
Why the guardrails are the product
At Legion Intelligence, where I work, this is the problem our Maintenance Pack is built around, for both aircraft maintenance and facility maintenance. The tours are a big part of why I believe in how we've built it. Three commitments, all learned from the people doing the work.
It sits on top of whatever you already run. Prescriptive value lives in the connection between prediction and the work itself, and that work lives in your existing systems: the CMMS, the ERP, the scheduling tools that took five years to implement. Nobody who survived that implementation wants to hear "replatform." The agent's job is to traverse the systems you have, not to become system number nine. A recommendation engine that can't reach your systems of record leaves the traversal exactly where it was.
It shows its work. Every recommendation carries its receipts: the symptom report, the manual section, the bulletin, the historical work orders that informed the call, including the half-legible closeout note, shown as-is so you can weigh it. A recommendation you can't trace is a hunch, and maintainers audit hunches for a living. The system should survive the same skeptical read a junior tech's write-up gets. If your people can't check its reasoning, they won't act on it, and an unactioned recommendation is worth exactly nothing.
The agent prepares everything and signs nothing. In aviation maintenance, the record and the sign-off are sacred, and rightly so; an airworthiness determination belongs to a certified human, full stop. So that boundary is fixed in the product. The agent assembles everything up to the line and never crosses it. It never touches the record. It never signs. No setting changes that.
The last commitment sounds like a limitation, and it's the one that makes the other two usable. Prescriptive maintenance only works if the people receiving the recommendations trust them enough to act, and in high-consequence environments, trust isn't built by capability. It's built by boundaries. A maintainer trusts a system the way they trust a colleague: by knowing exactly what it will and won't do, especially under pressure. A system that could maybe be configured to auto-sign "for efficiency" is a system no responsible maintainer will ever fully trust, because they've met efficiency before. The intelligence gets you the recommendation fast. The governance is what lets a professional whose license and conscience are on the line actually use it. The fastest way to lose that professional forever is to suggest, even once, that the machine's judgment could stand in for theirs.
If you're evaluating anything in this space, ours included, those commitments double as the test. Does it reach your real systems or only demo beautifully in isolation? Can it show the evidence behind every call, including when the evidence is a scanned PDF from 2009? And can the vendor tell you, in specifics rather than vibes, what the system can never do regardless of configuration? If the answer to that last one is "whatever you'd like," you're being sold a liability with a dashboard.
What can AI actually do for maintenance operations?
AI in maintenance is software that can read everything your operation already knows (the sensor data where it exists, the manuals, the bulletins, twenty years of work order history, the notes scrawled in margins, the stuff in your best people's heads) and that now has hands to do something with it at the moment of decision. Sometimes that moment is three weeks before a failure. Sometimes it's ninety seconds after one.
The people I've met in this world don't need replacing, and they'd be the first to tell you so. What they need is for everything their operation knows to actually show up when it counts, instead of hiding in a binder, a legacy database, and Dave. For the first time, that's a solvable problem. The operations that solve it first are going to be very hard to catch.
See how the Facilities Maintenance Pack turns a one-line work order into a supervisor-approved dispatch plan, without replacing your CMMS.