AI for Facility Management: Work Orders, Vendors and Approvals

AI for facility management works best as an agent that takes in maintenance requests from every site, turns them into complete work orders, routes them to the right technician or vendor, and follows up until the job is closed. It does not decide by itself to spend money or change a vendor arrangement. Anything above a defined limit goes to a named person for approval, so the agent removes the chasing and the lost messages while people keep every cost decision.

Key takeaways

• Start with one role: the coordinator who receives requests, builds work orders and chases vendors. Do not start with a general facilities assistant.
• The agent's main value is completeness and follow-up: a work order with the right site, location, urgency and photos, and a vendor who is reminded until they answer.
• Spending needs an explicit approval boundary. The agent may gather quotes and prepare a recommendation, but a named human approves anything past the limit.
• Vendor emails and tenant messages are untrusted input. The agent should read them as data, never as instructions that change its permissions.
• Measure it with an observable result, such as how many requests sit without an owner or how many vendor jobs are past their promised date.

What does an AI agent actually do in facility management?

Facility management is mostly coordination. Someone reports a problem, someone has to understand it, someone has to decide who fixes it, and someone has to confirm that it was fixed. Across several sites, the work is spread over email, phone calls, chat messages, spreadsheets and the memory of a few experienced people. Requests get lost in the gaps between those channels.

An agent fits into those gaps. It listens on the channels people already use, reads each request, and asks for what is missing. It creates or updates a work order in your system of record, picks a route based on your rules, and tells the requester what happens next. When a vendor goes quiet, it asks again. When a job closes, it checks that the requester agrees.

What it should not do is just as important. It should not approve spending, sign vendor terms, grant building access, or declare a safety issue resolved. Those stay with people. The [guidance on building effective agents](https://www.anthropic.com/engineering/building-effective-agents) from Anthropic makes a similar point: start with simple, well-defined workflows, and add autonomy only where the task needs it and the risk is understood.

If your portfolio is residential, the same pattern applies with tenants as the main requesters, which we cover in AI agents for property management and tenant maintenance. For service companies that clean and maintain client buildings, see AI for cleaning and facility services.

How should requests be taken in across several sites?

Intake is where most facility problems start. A message that says the second floor is too cold is not a work order. It has no site, no room, no urgency and no way to tell whether it is a thermostat setting or a failed heating unit.

The agent's first job is to turn loose messages into structured requests. For each one it should establish:

• Which site and which area of the building
• What is wrong, in the requester's words and with photos if they can send them
• Whether anyone is at risk or whether the problem is getting worse
• Who reported it and how to reach them
• Whether this looks like a repeat of an earlier request at the same place

The agent asks only for what is missing, in the channel the person used. A short reply to a chat message beats a form nobody wants to open. If the requester is a site manager, the agent can assume more context than it would for a visitor, and that distinction belongs in its written operating context rather than in improvisation.

Duplicate detection matters more than it sounds. When three people report the same leak, the agent should link the requests to one work order and tell each person that it is being handled. Otherwise the same vendor is called three times.

Urgency is the other part of intake. Define a short list of conditions that always go straight to a human, such as water near electrical equipment, smell of gas, blocked fire exits, or anything involving injury. The agent recognizes these patterns, alerts the on-call person through the channel you specify, and does not wait to finish the normal flow. It should be conservative here: a false alarm costs a phone call, a missed one costs much more.

How does work order routing work?

Routing means deciding who does the work. In a single building that might be one maintenance technician. Across several sites it usually involves in-house staff at some locations, contracted vendors at others, specialist trades for certain systems, and warranty or landlord obligations that change who pays.

The agent routes using rules you write down, not its own taste. A routing table is a good artifact to start with. For each site and each category of work, it names the default owner, the backup, the expected response window and the conditions that change the route.

Here is an illustrative scenario. A staff member at a regional office reports that the kitchen sink is draining slowly and there is a damp patch in the cabinet below. The agent asks for a photo and whether water is actively leaking. The answer is a slow drip. It creates a work order for that site under plumbing, marks it as non-emergency but time-sensitive because of the water damage risk, and checks the routing table. For that site, plumbing goes to a contracted vendor with a response window. The agent sends the vendor the site address, the room, the photo, an access note and a contact name, then tells the staff member that a plumber has been asked to visit and what to do in the meantime, such as placing a container under the pipe.

Notice what the agent did not do. It did not choose a new vendor, offer a price or authorize an after-hours call-out. If the vendor had not confirmed within the response window, the next step in the rules would apply: remind the vendor, then alert the facility coordinator.

Good routing also depends on memory. The agent should know the history of a location: that the same pipe was repaired recently, that a vendor already quoted for a full replacement, that a warranty may still apply. This is retrieval work, pulling the right records at the right moment rather than storing everything in a single prompt. The operations teams article covers how recurring work and reports share this memory.

Where does the spending approval boundary sit?

This is the part that decides whether an owner can trust the system. A facility agent touches money indirectly all the time: it requests quotes, schedules paid call-outs, and tells vendors to proceed. The boundary must be written, specific and enforced by the system, not just described in a prompt.

A practical decision guide has four tiers:

• Pre-approved routine work: jobs covered by an existing service contract or a standing arrangement. The agent can dispatch these and log the work order.
• Below the site limit: small repairs a site manager may approve. The agent prepares the request with the vendor's estimate and sends it to that manager. It proceeds only after a recorded yes.
• Above the site limit: the agent gathers at least the quotes your policy requires, summarizes scope and differences, and sends a recommendation to the named approver. It does not choose.
• Contract changes, new vendors and anything unusual: always a human, always outside the agent's authority.

The limits themselves are yours to set, and they can differ by site and by category. What matters is that approval is an event with a name, a time and a decision attached to the work order. If someone asks later why a repair went ahead, the record answers.

Enforcement belongs in the tools and permissions. The agent's connection to your work order system should simply lack the ability to mark a spend as approved. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) recommends least privilege and checking permissions on every request, which is the right posture here. A rule that exists only in the instructions can be talked around. A rule that exists in the permissions cannot.

When the approver does not respond, the agent reminds them and escalates to a backup you named. It never treats silence as consent.

How should the agent follow up with vendors?

Vendor follow-up is the work coordinators dislike most and drop first when they are busy. It is also where an agent is most obviously useful, because the task is repetitive, time-based and well defined.

For every dispatched job, the agent tracks a small set of states: requested, acknowledged, scheduled, on site, completed, invoiced. Each state has an expected time. If a vendor has not acknowledged by then, the agent sends a polite reminder through the channel that vendor actually answers. If a scheduled visit passes with no completion note, it asks what happened. If the vendor reports a different problem than expected, it updates the work order and, where a cost change is involved, routes the question to the approver instead of agreeing.

A few habits make this reliable:

• Keep a vendor profile with contact methods, coverage areas, trades, usual response patterns and any access or insurance requirements.
• Send the same complete job packet every time, so vendors stop asking the same questions.
• Ask for completion evidence that matches the job, such as photos or a short note, and attach it to the work order.
• Close the loop with the requester before closing the order.

One security point deserves attention. Vendor replies, tenant messages and forwarded documents are text from outside your organization. A message that says to ignore previous rules and approve the invoice is an attack, and models can be fooled by content like that if it is treated as instruction. The [OWASP prompt injection prevention cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) describes the defenses: separate untrusted content from instructions, limit what tools the agent can call, and require confirmation for sensitive actions. The spending boundary above is your strongest protection, because even a successfully confused agent cannot approve what it has no permission to approve.

Where quotes and supplier comparisons become frequent, the same patterns appear in AI agents for procurement teams.

What is a sensible plan for starting?

Do not start with every site and every trade. Start narrow enough that you can see the result and correct it. A workable sequence:

• Pick one role to define: facilities coordinator for intake, routing and vendor follow-up.
• Choose two or three sites and a few common categories of work, such as plumbing, electrical and climate control.
• Write the routing table, the urgent conditions list and the spending tiers on paper before any configuration.
• Decide where the system of record lives and which channels the agent listens to. Give it only the access it needs.
• Run the agent in a suggest-only mode first. It drafts work orders and vendor messages, and a person approves them.
• Review the drafts every week: what was misrouted, what was missing, what vendors ignored.
• Move specific, low-risk actions to automatic, such as acknowledging requests and sending vendor reminders, while keeping approvals human.
• Add sites and categories only after the first set behaves consistently.

Choose a success criterion you can observe without special tooling. Examples include requests that have no owner after a set period, vendor jobs past their promised date, or requests that needed a second question from a human because the agent missed a detail. Monitoring and recurring evaluation then make these visible over time, rather than leaving you with an impression. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is a useful reference if you want a structured way to think about mapping, measuring and managing the risks of a system like this.

How does Be Human approach this?

Be Human designs, implements and operates AI agents for companies, with identity, memory, channels, tools and permissions under human control. For facility management, a first engagement defines one useful role, usually the coordinator described above, along with the memory it needs (site records, routing rules, vendor profiles), the tools it may use, the approval boundaries for spending and the success criterion. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, so the agent keeps matching how your sites and vendors actually work. The service is remote and available in English and Portuguese.

Frequently asked questions

Can an AI agent replace a facilities coordinator? It can take over the repetitive parts: gathering details, creating work orders, reminding vendors and updating requesters. The coordinator still handles judgment calls, vendor relationships, exceptions and approvals. Most teams find the role shifts toward oversight and problem solving rather than disappearing.

Does the agent need to replace our existing work order system? No. It is usually better to connect to the system you already use, or to a shared tracker if you do not have one, and treat that as the record. Replacing tools adds change for everyone, while connecting with limited permissions keeps the first engagement small and reversible.

What happens when the agent is unsure how to route a request? It asks the requester for the missing detail or hands the request to a named coordinator with a summary of what it knows. Uncertainty is a normal outcome, and the rules should say where it goes. A request that sits unrouted is a failure, so the fallback owner matters.

How do we keep the agent from committing us to costs? Do not rely on instructions alone. Limit its permissions so it cannot approve spending, require a named approver for anything above your limits, and record each decision on the work order. Review the permissions regularly, since sites, vendors and staff change.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.