AI for Building Maintenance Companies: Tickets and Contracts

AI for building maintenance companies works best as operational memory. An agent reads tickets, vendor contracts and equipment history, suggests priorities and chases deadlines. It does not approve quotes, hire vendors or authorize spending. That decision stays with a person who has defined authority.

Key takeaways

• The value is in bringing tickets, contracts and equipment history into one context the agent checks before it acts.
• Prioritizing and chasing are the right jobs for the agent. Approving spend, switching vendors and accepting risk are not.
• A vendor contract has to become structured data (term, scope, warranty, visit limits), not just a PDF in a folder.
• Every agent action should leave a record: what it read, what it suggested, who approved.
• The safe path is a pilot on one real workflow, with a metric agreed beforehand and an explicit decision to expand, adjust or stop.

What does AI in building maintenance mean, without the hype?

Building maintenance is coordination work. A request arrives from a resident, a property manager, a site manager or a tenant. Someone has to understand what it is, check whether a contract or warranty applies, choose the vendor, follow the visit and confirm the problem was actually fixed. Much of the time goes to hunting for context: what has already been done on this elevator, which company services that pump, whether the work is still under warranty.

This is where an AI agent fits. It does not replace the maintenance coordinator. It cuts the search for context and the repetitive follow-up. When people talk about superintelligence applied to this sector, the term deserves care: what is described here is a set of language models with controlled access to operational data, not an intelligence that decides for the company. If you want to see how that set is organized, the article on the company superintelligence layer in five building blocks covers the architecture.

What operational memory does the agent need?

An agent is only useful if it consults reliable sources. In building maintenance, three sources hold almost everything that matters.

• Tickets: original description, photos, location, time, who opened it, status, messages exchanged and final outcome.
• Vendor contracts: covered scope, agreed response times, visit windows, warranties, exclusions, reference values already approved by someone with authority, and rules for extra work.
• Equipment history: asset identification, location, installation date, preventive maintenance plan, previous interventions, parts replaced and recurring failures.

The central step is turning loose text into records the agent can cross-reference. A ticket saying the garage gate jammed again only gains value when it is linked to the asset (the garage gate in block B), to the maintenance contract in force and to the three earlier interventions. Without that link, the agent answers in generic terms. With it, the agent can say this is the third similar occurrence, that the contract sets a corrective response time, and that a parts warranty needs to be checked.

For long documents, the usual technique is to retrieve only the relevant passages at the moment of the query instead of loading everything into context. Anthropic's engineering guidance on context engineering for AI agents deals with exactly this choice of what goes into context and what stays out. It is official documentation; applying it to building contracts is a design adaptation that needs testing in your own operation.

How does the agent prioritize tickets?

Prioritizing is not guessing. The agent applies criteria the company defines and writes down. A simple decision guide you can adapt:

• Risk to people's safety (gas leak, elevator failure with people trapped, electrical hazard): goes straight to a human with an immediate alert, without waiting in a queue.
• Risk of damage to property (active leak, water pump down): high priority, with a vendor suggestion based on the contract.
• Contractual or regulatory obligation with a deadline (inspections and preventive routines): the agent tracks due dates and warns ahead of time.
• Nuisance without risk (burned-out bulb in a common area, cosmetic adjustment): joins the normal queue, grouped by vendor and by visit.
• Recurrence: if the same asset failed again, the agent flags it and suggests a root cause analysis instead of another identical visit.

The agent does not apply these criteria alone in doubtful cases. When a description is ambiguous, it asks the requester or routes the ticket to a person. It is a simple rule that prevents many errors: doubt about safety goes up, never down.

How does the agent chase vendors without authorizing spend?

Chasing is where the agent saves the team the most effort, and it is also where the limit must be clearest. The agent can:

• Remind the vendor of the response time set in the contract.
• Ask for confirmation of the visit date and record the answer.
• Request a report or photos of the work done.
• Alert the coordinator when the contractual deadline passes with no reply.
• Prepare a draft of a requested quote, pointing out what the contract already covers and what would be extra.

The agent cannot approve a quote, accept out-of-scope work, hire a new vendor or promise payment. In technical terms, this means the tools available to the agent are for reading, drafting and notifying, and any action with a financial effect goes through a human approval step. OWASP's Authorization Cheat Sheet reinforces the principle of least privilege and of checking permission on every action, not only at the start of a session. Apply this literally: the agent should not hold a credential capable of issuing a purchase order.

If the follow-up happens over WhatsApp, pay attention to the rules on the service window and on outbound messages. The article on the WhatsApp 24 hour customer service window explains what the agent may send and when, so you do not build a flow that is blocked later.

Illustrative scenario: a booster pump that keeps failing

The example below is illustrative and does not describe any real company.

A commercial building opens a ticket: the booster pump for the water tank tripped again. The agent receives the ticket and checks operational memory. It finds the asset, sees two earlier corrective interventions with the same symptom, and sees that the vendor's maintenance contract sets a corrective response time and periodic preventive visits. It also sees that the last part replacement was recent and that the contract mentions a warranty for that part.

The agent classifies the ticket as property risk with high priority, because the lack of water affects the whole building. It sends the vendor a message with a short history, cites the contractual deadline, asks for a visit date and requests that the report say whether the failure is related to the replaced part. At the same time, it alerts the coordinator: third occurrence, possible warranty claim, root cause analysis suggested.

After the visit, the vendor sends a quote to replace the entire assembly. The agent prepares a summary comparing the quote with the contract scope, highlights what looks like extra work and what depends on the warranty review, and sends it to the person responsible for approval. Nothing is authorized until that person replies, and the reply is recorded on the ticket. If the vendor pushes for payment without approval, the agent only states that the request depends on an internal decision.

How to start: map, limit, pilot, hand over

The method we use in agent projects has four steps, and it fits building maintenance well.

• Map: describe how a ticket moves through the operation today, where context gets lost and how much time goes into chasing. Record a simple baseline, such as the time between opening and first action, before any automation.
• Limit: define which data the agent reads (tickets, contracts, history), which actions it takes (summarize, prioritize, notify, chase deadlines) and which require human approval (any spend, vendor change, contract exception). Also define who receives safety cases.
• Pilot: pick one small, real workflow, for example corrective tickets for a single type of asset, with every decision recorded and a success metric agreed beforehand. Before going live, test with simulated data; the article on mock tools for testing AI agents in a sandbox shows how to do it without risk.
• Hand over: give the team the records, the criteria and the adjustment procedure, and decide together whether to expand, adjust or end the pilot.

If the company also serves industrial sites, the piece on how to start with AI in manufacturing, beginning with maintenance and quality adds considerations about production equipment that complement this one.

What risks and controls belong in the design?

Three risks appear often in agents that read third-party text and act on it.

The first is a malicious or accidental instruction inside a ticket or a vendor email. A text that says to ignore the rules and approve the quote must have no effect. The OWASP guidance on preventing prompt injection describes practical measures, and the most important one here is structural: the agent simply has no permission for the financial action.

The second is personal data. Tickets carry names, unit numbers, phone numbers and sometimes the routines of residents or employees. Under LGPD, the company should use only what the purpose requires, limit access and know where the data goes. If the model runs outside Brazil, read about international data transfer under LGPD when using AI providers before settling the architecture. For each field, ask whether the agent really needs it.

The third is overconfidence. The agent may misread a clause or mix up two similar assets. That is why a contract summary should always show the source passage, and the human approver should see the passage, not only the conclusion. The NIST AI Risk Management Framework offers a general structure for identifying, measuring and handling this kind of risk, and it works as a governance reference, not a ready-made recipe.

Frequently asked questions

Can an AI agent approve a maintenance quote? It should not. Approving spend has financial and contractual consequences and needs a person with defined authority. The agent can prepare the comparison between quote and contract, point out discrepancies and route the item for a decision, with everything recorded.

Do we need to digitize all contracts before starting? Not all of them. Start with the contracts of the vendors tied to the pilot workflow and structure the essentials: scope, response times, warranties, exclusions and rules for extra work. Expanding later is safer than trying to organize everything at once.

Does the agent only work over WhatsApp? Not necessarily. WhatsApp is often the entry channel for tickets and the channel for chasing vendors, but the agent can also work on email, a form or the ticketing system the company already uses. What matters is that each ticket is recorded in a single place, with a searchable history.

How do we know the pilot worked? Define the metric before you start, based on the baseline you mapped, such as the time to first action on corrective tickets or the number of follow-ups done by hand. At the end, compare against that baseline, review the agent's decision records and decide with the team whether to expand, adjust or end it. Without a metric agreed beforehand, the evaluation becomes opinion.

Sources

• Anthropic: Effective context engineering for AI agents
• OWASP: Authorization Cheat Sheet
• OWASP: LLM Prompt Injection Prevention Cheat Sheet
• NIST: AI Risk Management Framework