AI Agents for Autonomous Maintenance: Workflow Automation in FM and CMMS

The AI conversation in maintenance operations spent most of 2024 and 2025 talking about copilots: LLM-mediated interfaces that surface information, suggest actions, and let the human decide. The 2026 conversation is starting to shift toward agents: AI-mediated processes that take defined actions autonomously, escalate to humans only for exceptions, and close entire workflow loops without a human touching every step. Done properly, this is a meaningful productivity multiplier. Done carelessly, it is where a lot of AI programmes will produce their worst public failures. This article covers what agents actually are, where they belong in maintenance operations today, and the discipline required to deploy them without creating an audit disaster.

Scope note: this article sits at the end of the AI-in-maintenance series covering copilots (Topic 1), NLP (Topic 2), computer vision (Topic 3), voice AI (Topic 4), and generative reporting (Topic 5). Agents build on all of them.

What is an AI agent, actually?

In the maintenance operations context, an AI agent is a software actor that: receives a goal or a triggering event, reasons about the steps needed to achieve it, executes those steps against operational systems (CMMS, ERP, contractor portals, messaging), monitors the outcomes, and either completes the loop autonomously or escalates to a human when the situation exceeds defined boundaries.

Two distinctions matter for maintenance leaders trying to make sense of the vendor landscape:

• Agents versus copilots: a copilot proposes and a human confirms every action. An agent takes routine actions autonomously and only escalates non-routine ones. The difference is where accountability for the individual action sits.
• Agents versus traditional automation (RPA, workflow rules): traditional automation follows fixed rules on structured triggers. Agents use LLM-based reasoning to handle unstructured inputs and adapt to novel situations. When the situation matches the rule, both work. When the situation is slightly off, traditional automation breaks and agents can (sometimes) still succeed.

The technical foundations are the same as copilots: an LLM as the reasoning engine, retrieval to ground the model in current operational data, structured tool use to take actions in downstream systems, and observability to log everything the agent does. The design shift is in how much autonomy the agent has and what its escalation boundaries look like.

The maintenance automation landscape today

Before proposing agent use cases, it helps to be honest about what is already automated in maintenance operations and what is not. The 2026 baseline for a typical mid-to-large CMMS deployment:

• PM scheduling: fully automated by the CMMS scheduler. This is not new.
• Work order creation from triggers: mostly automated where the CMMS is integrated with the BMS, alarm systems, or IoT layer.
• Technician assignment: partially automated using skill-and-availability rules, but most CMMS implementations leave complex assignments to the planner.
• Vendor coordination: mostly manual. Emails to contractors, phone follow-ups, status chasing.
• Spare parts requests: partially automated where the CMMS integrates with the parts/inventory system.
• Escalation management: rules-based in mature CMMS deployments (SLA breach triggers), but the actual escalation actions (calling the right person, chasing the right vendor) are usually manual.

The pattern: the structured parts of maintenance operations are already automated. The unstructured parts (coordinating humans, chasing contractors, handling exceptions) are still manual. This is exactly where agents make sense, because unstructured coordination is what LLM-based reasoning handles better than rule-based automation.

Autonomous work order management

The flagship agent use case. Consider a typical work order lifecycle: creation, priority setting, trade routing, technician assignment, parts sourcing, permit checking, execution scheduling, technician dispatch, completion recording, cost coding, closure approval. Traditional automation handles a subset. Humans still coordinate the rest.

An agent-based work-order management system takes autonomous responsibility for the routine steps. It reads incoming events. It creates work orders with correct classification and priority (drawing on the AI enrichment patterns covered in the AI help desk pillar). It checks technician skill and availability, then assigns. It verifies parts are on hand or triggers procurement. It checks whether a permit is needed and if so, initiates the permit process. It monitors execution and follows up on delays. It confirms completion and closes the loop.

The planner and supervisor are still in the loop, but only for the cases the agent escalates: high-priority events, unusual asset situations, permit exceptions, cost overruns, missed SLAs. Their attention concentrates on the cases that actually require human judgment. Everything routine handles itself.

Realistic split I see in production: 60 to 75 percent of routine work orders can be handled autonomously by a well-designed agent in a mature CMMS environment. The remaining 25 to 40 percent needs human touch. The planner's job becomes the higher-value exception handling rather than the paperwork chase.

AI-driven scheduling

Scheduling maintenance work at scale is a constraint-optimisation problem: PM schedules, corrective work, permit windows, technician availability, skill matching, geographic clustering, contractor availability, parts arrival, shutdown windows. Traditional CMMS schedulers do part of this. Human planners do the rest through experience and judgment.

AI-driven scheduling agents extend the CMMS scheduler's capabilities using LLM-based reasoning to handle the unstructured parts: interpreting technician preferences, incorporating known site constraints not encoded in the CMMS, adapting to short-notice changes, and balancing multi-objective trade-offs (efficiency versus SLA compliance versus workload fairness).

The output is not a fully replaced planner. It is a planner working from an AI-optimised draft schedule that they refine rather than build from scratch. The daily planning cycle compresses from hours to minutes; the planner's attention shifts to the strategic decisions the CMMS scheduler cannot make.

Autonomous technician assignment

Given a work order, which technician should do it? The traditional answer combines rules (trade, certification, availability) and planner judgment (experience with this asset, current workload, geographic proximity to the site). Agents can automate most of this at scale.

The agent evaluates each incoming work order against the available technician pool using: required skills and certifications, current workload, geographic location relative to the site, recent experience with this asset or asset class, historical first-time-fix rate on similar work, and available time in the shift. The best match gets the assignment. Where multiple candidates are similar, the agent balances workload across the team. Where no clean match exists, the agent escalates to the supervisor with the specific reason (no available technician with the required certification, workload imbalance, geographic conflict).

The trade-off worth being clear about: technicians build tacit expertise on specific assets, and pure algorithmic assignment can dilute that expertise if not tuned. The agent should preserve the "primary technician for asset X" relationship where it exists, not just optimise for immediate efficiency.

Following up on overdue work

A quiet operational pain point in every CMMS deployment: work orders that go overdue and nobody chases them until the weekly review meeting. By then the delay compounds, the customer is frustrated, and the underlying reason (technician stuck on a harder job, parts unavailable, permit blocked) has festered.

Follow-up agents chase overdue work systematically. When a work order crosses an SLA threshold, the agent: checks the current status, identifies the reason for delay, contacts the assigned technician for update, chases parts availability if that is the blocker, escalates to the supervisor if the delay exceeds a defined threshold, and logs the chase activity in the CMMS.

This is not a new concept; SLA-breach automation has existed for years. What agents add is the ability to interpret unstructured status updates ("waiting on part XYZ but should be back by tomorrow"), chase the specific reason rather than issuing generic reminders, and escalate with useful context rather than just alerting that something is late. The dispatcher's follow-up work compresses to reviewing exceptions the agent surfaces.

Vendor and contractor coordination

External vendor management is where most maintenance operations still coordinate by email and phone. Someone at the FM operator emails the contractor. The contractor emails back with an availability window. Someone updates the CMMS. The technician gets dispatched. Actual arrival gets confirmed by phone. Completion gets emailed back. Payment gets processed through a separate finance workflow.

Agent-based vendor coordination compresses this significantly. The agent handles: initial notification to the contractor with the work order context, availability negotiation using the contractor's scheduling system or a shared calendar, confirmation of the visit, monitoring arrival (potentially via geolocation or check-in), status polling during the visit, completion confirmation, and cost capture for invoicing.

The human FM operator only gets involved when the contractor is unresponsive, when a schedule conflict emerges, or when the completion needs approval outside routine parameters. Their time shifts from chasing status to managing exceptions and vendor relationships. For a large FM operation with dozens of contractor relationships, this is a materially different operational rhythm.

Autonomous spare parts requests

When a work order needs parts, someone traditionally checks stores, and if the part is not on hand, initiates a purchase requisition. Depending on the organisation's procurement process, this can take hours to days before the technician actually has the part in hand.

Agent-based parts management shortens this loop. When a work order lists required parts, the agent: checks stores availability across the network of storerooms, reserves the part at the closest location if available, initiates a purchase requisition if not available, tracks the requisition through the approval workflow, follows up on procurement delays, and updates the work order status when the part arrives. The technician's mobile app shows the parts status in real time.

For high-consumption parts, the agent extends into reorder-point management: watching inventory levels, predicting demand from PM schedules and recent consumption, initiating replenishment before stockouts occur. This tips into inventory optimisation, which is where the value compounds beyond individual work orders.

Intelligent escalation management

Traditional SLA breach automation is binary: the SLA was breached, escalate to the next tier. Agent-based escalation is graduated and contextual. The agent evaluates the specific situation: is the delay likely to be resolved shortly, is the underlying issue understood, is this a symptom of a broader problem, does the escalation need to reach a specific person or role, and is there historical precedent for how similar situations resolved.

Based on that reasoning, the agent chooses the appropriate escalation path: additional monitoring for cases likely to resolve, direct message to the specific person best positioned to help for cases with a clear owner, supervisor escalation with structured context for cases needing decision-maker attention, or crisis-response protocol for genuine emergencies. Each escalation carries the context the recipient needs, not just a generic breach alert.

The result: fewer alerts, higher-quality alerts, faster resolution of the ones that need attention. The escalation process shifts from noise to signal.

End-to-end automation: composing the agents

The individual agent use cases above are useful on their own. The strategic value compounds when they compose into end-to-end automated workflows. Consider a typical scenario:

1. A tenant reports a fault via the AI help desk (Topic 3). The complaint gets classified, routed, and turned into a work order automatically.
2. The work order management agent (this article) picks up the new work order, checks priority, assigns the appropriate technician based on skill and workload.
3. The parts agent checks parts availability and reserves the required items.
4. The technician receives the work order on their mobile app with full context: asset history, checklist, AI-suggested diagnosis (Topic 1 copilot pattern), parts location.
5. The technician executes the work, documents via voice input (Topic 4).
6. The generative AI drafts the completion report (Topic 5), the technician reviews and confirms.
7. The work order closes, cost coding auto-populates, and the tenant receives an update about the resolution.

Every step above uses AI. No step required a human other than the technician doing the physical work and the tenant experiencing the initial fault. This is not science fiction; it is how a well-designed maintenance operation looks in 2027 to 2028 for the organisations that invest in the design work now. The composition matters as much as the individual agent capabilities.

The honest limitations of maintenance agents

Being clear-eyed about what agents cannot do reliably is what separates a successful deployment from an expensive experiment.

• Safety-critical decisions: an agent should never autonomously approve isolation procedures, switching schedules, permit issuance, or any decision where a wrong call causes harm. These stay with qualified humans, always.
• Novel or unusual situations: agents work well on patterns that appear in historical data. Genuinely novel situations trigger poor reasoning. Design the agent to recognise when it is out of its depth and escalate rather than push through.
• High-cost financial commitments: agents should not autonomously approve expenditures beyond a defined ceiling. Financial guardrails need to be explicit and enforced.
• Regulatory or contractual boundaries: any action with regulatory implications (statutory compliance certifications, permit conditions, contractual commitments) needs human accountability, not agent autonomy.
• Interpretation of ambiguous human input: when a tenant, technician or contractor says something that could mean multiple things, the agent should ask rather than guess. Guessing wrong on unclear input is where reputational damage happens.
• Auditability: every autonomous action needs a defensible audit trail. If the auditor cannot understand why the agent did what it did, the agent should not have done it autonomously.

These are not obstacles to agent deployment. They are the design constraints that make agent deployment defensible. Ignore them and the programme becomes a governance case study. Respect them and the productivity value lands cleanly. See the AI governance for enterprise operators pillar for the broader framing.

Where to start with agents

Four practical steps for a maintenance leader thinking about agents:

1. Start with follow-up-on-overdue-work agents. Low stakes, clear value, easy to measure, and a good place to learn how autonomy behaves in your specific operational context.
2. Then extend to autonomous technician assignment for low-consequence work orders. Same skill-match logic that the planner already uses, but automated for the routine cases.
3. Then vendor coordination for routine contractor visits. Higher operational impact, but tightly bounded by existing contractor relationships and processes.
4. Only after those three are stable and trusted, extend to end-to-end work order management. This is the ambitious use case; earn the trust with the smaller wins first.

At each step, budget for observability, exception handling, and human review of the agent's decision quality. A month of quiet running is not proof the agent is working correctly; it might be proof the agent is quietly making bad decisions nobody has checked. Actively audit the agent's behaviour, especially in the first six months.

Measuring whether agent deployment is working

The KPIs that matter for agent-based maintenance workflows:

• Autonomous completion rate: percentage of work orders that close without human intervention. Should trend upward as trust and scope expand.
• Escalation rate: percentage of cases the agent escalates to humans. Too low is bad (agent overreaching), too high is bad (agent not adding value). Target range depends on use case.
• Time-to-resolution: for autonomous work orders, should be faster than the pre-agent baseline. If not, something is off.
• Human override rate: percentage of agent decisions that a human subsequently overrode. High override rate signals poor agent decision quality.
• Cost per work order: should trend downward as autonomy compresses manual coordination cost.
• Audit findings: monthly review of a sample of agent-executed work orders for correctness. Zero unaddressed findings tolerated on safety-critical or regulatory-adjacent work.

Set the baseline before deployment. Track monthly for the first year. Where KPIs diverge from targets, tune the agent's scope, guardrails, and escalation thresholds before extending to new use cases.

Agent deployment maturity levels

A useful framing for planning is to think about agent deployment as a maturity curve rather than a binary switch. Four levels I find useful:

1. Level 1: Assistive. Agent monitors, surfaces recommendations, but takes no autonomous actions. Every action still requires human confirmation. Low risk, moderate productivity value. Good starting point.
2. Level 2: Bounded autonomous. Agent takes routine actions autonomously within tight rules (assign a technician if the match is high-confidence, chase overdue work with generic reminders, close routine low-cost work orders). Human review of a sample. Higher productivity value, still low risk.
3. Level 3: Contextual autonomous. Agent takes actions across a wider range of situations using LLM-based reasoning, escalates novel or ambiguous cases. Human review of exceptions and audit sampling. Materially higher productivity, moderate governance discipline required.
4. Level 4: Composed multi-agent. Multiple agents coordinate across end-to-end workflows (help desk to work order to dispatch to completion). Human intervention only on exceptions. Highest productivity, highest governance discipline required.

Every organisation should start at Level 1 and earn the trust required to move up. Skipping levels is where the governance failures happen. The right question is not "how far up the curve can we get" but "how far up the curve can we get while maintaining defensible governance." Answer that honestly and the deployment stays on the right side of the outcomes.

Final thoughts

AI agents are the next phase of the AI-in-maintenance evolution and they are meaningfully different from copilots in the accountability model they create. Deployed carefully, they compress manual coordination costs, free planners for higher-value work, and enable operations at a rhythm and scale traditional automation cannot match. Deployed carelessly, they create autonomous systems making bad decisions with no human accountability, which is exactly the pattern regulators and auditors will treat as a governance failure.

The organisations that get value from agents are the ones that treat the autonomy question with real discipline: clear guardrails, honest scoping of what should be autonomous versus assistive, active observability of what the agent actually does, and an escalation pattern that keeps humans accountable for the decisions that matter. Get those right and the productivity value lands and compounds. Skip them and the programme produces the case study the next AI governance article uses as a warning.

The technology is ready. The design discipline is what separates the two outcomes.

Related reading (the full AI-in-maintenance series): Topic 1: Copilots, Topic 2: NLP, Topic 3: Computer Vision, Topic 4: Voice AI, Topic 5: Generative Reporting, AI governance, AI help desk reference architecture.