Every building analytics vendor now has an AI story. Most of them stop at the same place: an agent reads the alarms, groups them, and hands a shorter list to a person. That is useful. It is also the easiest part of the job.
This post is for engineers and operations teams working out what an AI agent can actually be trusted to do against live building data. It covers what the agents do at each stage, who stays in control of the decision, how a fix gets verified rather than assumed, and what happens when you connect a building platform to an assistant like Claude or ChatGPT.
Key takeaways
- An AI agent in FDD is not a detector. Fault detection and diagnostics finds the fault in the data. The agent decides what to do about it: what matters, who owns it, and whether it was fixed.
- Triage is the entry point, not the finish line. Grouping alarms into a shorter list saves time, but it still ends with a work order and a hope.
- Governance is the thin part of the market. About 1 in 6 closed fault tickets in a CIM sample were closed before the data confirmed the fix had worked.
- The engineer keeps the decision. The agent recommends, flags gaps in the data and chases follow-ups. It does not quietly suppress faults or sign off its own work.
- An assistant connection is governed by your existing logins. Connecting Claude or ChatGPT to a building platform should grant no access the user did not already have.
What is an AI agent in fault detection and diagnostics?
An AI agent in fault detection and diagnostics is software that acts on fault data rather than only producing it. Where FDD rules identify that a valve is open against a closed command, an agent judges whether that matters, assigns it to the right person, chases it while it stays open, and checks the data afterwards to confirm the fault cleared and stayed clear.
The distinction matters because the two are often sold as the same thing. A rules engine is deterministic: it applies engineering logic, often derived from sequences such as ASHRAE Guideline 36, to time series data and raises a fault. An agent sits above that, handling the parts that used to need a person with context, a spreadsheet and a reminder in their calendar.
It helps to split the work into four layers, because vendors claim very different amounts of it:
- Detection: what changed? Rules and models find the fault in BMS and meter data.
- Assurance: does it matter? Rank by cost, comfort, risk and persistence, and discard the noise.
- Escalation: who owns it? Route to the right contractor or engineer with the evidence attached.
- Governance: did it get fixed? Confirm in the data that the fault cleared and held.
Most platforms are strong at the first layer. Many now claim the second. The fourth is where the category thins out, and it is the only one that answers the question an owner actually asks, which is whether the money spent on a repair changed anything.
What can an AI agent actually do with building data today?
Three things are in production across commercial portfolios now: triaging and ranking faults so a short list reaches a person, chasing open actions and asking the assignee for a status, and querying live building data in plain language from an assistant. Autonomous control changes to plant remain rare and are a separate category of risk.
It is worth being blunt about the boundary. An agent reading data and recommending work is a different proposition from an agent writing setpoints to a chiller. The first is reversible and auditable. The second is not, and most operations teams are nowhere near signing that off. Anything claiming both in the same breath deserves a careful read.
Within the reversible half, the useful test is whether the agent produces evidence a person can check. An agent that says "17 faults, here are the 4 that cost you money, here is the trend for each" is doing work. An agent that says "your building is 12% less efficient" with nothing underneath it is producing a number nobody can act on or argue with.
How does an agent triage faults without burying the ones that matter?
By ranking rather than filtering. Faults are scored on cost, comfort impact, equipment risk and how long they have persisted, then grouped so related faults on the same plant arrive as one job. Nothing is deleted. A fault that scores low stays visible and keeps accruing persistence, so a small problem that never gets fixed eventually surfaces.
The failure mode to watch for is suppression dressed up as triage. If an agent's job is to make the alarm list shorter, the easiest way to do that is to hide things, and the operator finds out six months later when the plant fails. Persistence scoring is the guard against this: a fault that has been open for 90 days should climb the list, not sink down it.
This is also where alarm triage and fault diagnosis get conflated. They are different jobs on different inputs, and knowing which one a vendor is describing tells you what you are buying.
Takes the alarms the BMS already raises, groups related ones and holds back the repeats. Answers: which of these alarms needs a person today?
Applies engineering rules to time series data and finds faults the BMS never alarmed on, such as a valve open against a closed command.
Watches the same data after the visit and confirms the fault cleared and held across a full operating cycle, or reopens it if it did not.
The three jobs are complementary. Most platforms do one or two of them.
Who decides what gets fixed, the agent or the engineer?
The engineer. The agent recommends, ranks and chases, and every rule behind a recommendation is visible and tunable rather than a black box. An agent that cannot show its working cannot be audited, and an operations team that cannot audit it will not trust the output long enough for it to be useful.
This matters more in a partner-delivered model than in a direct one. When an engineering firm runs analytics for its own clients, the firm's name is on the recommendation. The agent has to make that engineer look good, which means surfacing the evidence and admitting when the data is incomplete rather than guessing confidently. Partners such as Aero Performance Group and CSR Sustain run their own service on this basis.
The practical phrasing we use internally is simple: the AI recommends, your engineers decide. An agent that quietly closes tickets is not saving anyone time, it is moving the problem somewhere harder to see.
How does an agent verify that a fix actually held?
By going back to the data after the visit. The fault that triggered the action has to clear and stay clear across a full operating cycle before the action closes. If the fault returns, the action reopens with the trend attached. Nobody marks their own homework, because the evidence comes from the building, not from the person who did the work.
This sounds obvious and it is rarely done. In a CIM sample, about 1 in 6 closed fault tickets were closed before the data confirmed the fix had worked, and about 1 in 25 action tickets concern an override left in place after a visit. Those overrides are the quiet ones: someone puts a valve or a fan into hand to test something, the job gets signed off, and the override stays there consuming energy for months. One London tower had a chilled water valve sitting 40% open against a 0% command, worth about £25,053 a year, and sceptical engineers confirmed it in 98 minutes once they had the trend in front of them.
Independent verification is also what makes a maintenance conversation civil rather than adversarial. The contractor is not being accused of anything. The data either shows the fault cleared or it does not, and both parties are looking at the same trend. We have written separately on how to verify a contractor actually fixed an HVAC fault and on what independent monitoring means in practice.
Illustrative example, based on real Compliance Agent comments. Sites and names changed.
Can you query your buildings from Claude or ChatGPT?
Yes. A building platform can expose its data to an assistant through the Model Context Protocol, an open standard for connecting AI applications to external systems. PEAK publishes an MCP connector that works with Claude, ChatGPT and Microsoft 365 Copilot, so an engineer can ask about run hours, faults or a portfolio in plain English and get an answer built from live data.
The Model Context Protocol is the reason this is now practical rather than a bespoke integration per vendor. It standardises how an assistant discovers and calls the tools a system exposes, which means the building platform publishes one connector and the engineer uses whichever assistant their organisation has already approved.
What makes it useful in practice is not conversation, it is repeatable work. The PEAK AI Connector ships downloadable skills, each a defined workflow rather than an open-ended chat:
/health-check for [site]Visualises equipment health, thermal comfort, run hours or assignee performance for a site, without opening a trend at a time.
/bulk-triage for [site]Groups faults into sensible maintenance jobs and drafts the tickets, which the engineer approves before anything is created.
/client-report for [portfolio]Builds a branded monthly performance report across every site in a portfolio, with each name and site linking back into PEAK.
Skills are versioned workflows, so the same question produces the same shape of answer each month. Full setup for each assistant is in the PEAK AI Connector documentation, and the equipment run hours release shows one of the skills in use.
The client report is the one that changes what a partner can sell. It pulls three months of data across a portfolio, ranks sites on equipment health, indoor environment and engagement, names the open priority one and two backlog by site and by person, and pulls the wins out of action comments from the last 90 days. It carries the partner's own logo, colours and fonts, and every name and site in it is a live link back into PEAK, so a report stops being a PDF and becomes the route into chasing the work. That is a monthly reporting pack that used to take an engineer a day, produced from one prompt.
What can an agent access, and how are permissions controlled?
The connector inherits the user's existing platform permissions. In PEAK's case the documentation is explicit: your existing PEAK permissions apply, and connecting an AI assistant does not grant additional PEAK access. Authentication is OAuth 2.0, each person signs in as themselves, and a site the user cannot open in PEAK stays invisible to the assistant.
This is the question that stops most deployments, and it deserves a precise answer rather than reassurance. Three things are worth checking with any vendor offering an assistant connection. Does each user authenticate individually, or does the connector run on a shared service account that sees everything? Is access read-only by default, with writes such as raising a ticket requiring explicit approval in the conversation? And whose data retention policy applies once an answer lands in the assistant, because that is the AI provider's policy, not the building platform's.
On the third point, be honest with your IT team early. The building data leaves the platform the moment it is rendered in an assistant, and the governing terms are the ones your organisation already signed with that assistant provider. That is a solvable procurement question, but only if it is raised at the start rather than discovered at security review.
Where does CIM's PEAK Platform fit?
PEAK is a full loop building operations system: detect, decide what matters, assign, chase, and verify the fix in the data. It runs across more than 700 commercial buildings and more than 100 million square feet, is BMS-agnostic and read-only, and is not owned by any equipment, controls or BMS manufacturer, which is what allows it to verify a contractor's work without a conflict of interest.
Two agents are live. The Compliance Agent handles assurance, escalation and governance: it triages what matters, assigns it, chases the assignee while the action stays open, and closes it only once the data confirms the fault cleared and held. The Analyst Agent is the MCP connector described above, bringing live PEAK data into Claude, ChatGPT and Microsoft 365 Copilot under the user's own login. An Optimisation Agent is in development.
Underneath both sit more than 5,000 engineering rules that deploy automatically during onboarding, with buildings typically live within about 30 days. More than 20 engineering and service partners run their own analytics practice on the platform, which is the point: CIM's engineers sit behind the partner rather than in front of them. Our Building Operations Manager's AI Portfolio Playbook covers how to phase this across a portfolio without boiling the ocean.
If you want the detail on the four layers in a working deployment, how engineers triage and verify faults with platform support and why BMS alarm fatigue happens in the first place are the two companion reads. For the data layer that makes any of it possible, see BMS point naming, Haystack and Brick.
See how detection, assurance, escalation and governance work end to end, and how partners deliver it to their own clients under their own brand.
Frequently asked questions
Which fault detection platforms use AI agents to triage faults and verify fixes?
Most FDD platforms now offer some form of AI triage, which groups and ranks faults so a shorter list reaches a person. Far fewer verify the fix afterwards. The capability to look for is an agent that returns to the same data after the repair, confirms the fault cleared and held across a full operating cycle, and reopens the action automatically if it did not. CIM's PEAK Platform does this through its Compliance Agent.
What is the difference between AI alarm triage and fault detection and diagnostics?
Alarm triage works on the alarms a BMS already raises, grouping related ones and suppressing repeats so fewer reach a person. Fault detection and diagnostics works on trend data and finds faults the BMS never alarmed on at all, such as a valve sitting 40% open against a closed command. They are complementary jobs on different inputs, and a platform can do one well and the other not at all.
Can an AI agent close a fault ticket on its own?
It should only close one on evidence. A defensible close means the originating fault has cleared in the data and stayed clear across a full operating cycle, with the supporting trend attached to the action. An agent that closes tickets on a contractor's say-so, or on a timer, is recording completion rather than verifying it. In a CIM sample, about 1 in 6 closed fault tickets were closed before the data confirmed the fix.
Do AI agents in building analytics make control changes to plant?
Mostly not, and the distinction matters. The agents in production across commercial portfolios today read data, rank faults, assign work and verify outcomes, all of which is reversible and auditable. Writing setpoints or commands to plant is a separate category of risk that most operations teams have not signed off. Ask any vendor which of the two they mean.
How do you connect a building platform to Claude or ChatGPT?
Through the Model Context Protocol, an open standard for connecting AI applications to external systems. The platform publishes an MCP connector and the user adds it in their assistant, authenticating with OAuth 2.0 under their own account. PEAK's connector supports Claude, ChatGPT and Microsoft 365 Copilot, and ships skills for repeatable workflows such as site health checks and portfolio reporting.
Does connecting an AI assistant give it access to all our building data?
It should not. A properly built connector inherits the permissions the user already has, so a site someone cannot open in the platform stays invisible to the assistant. PEAK's documentation states that existing PEAK permissions apply and that connecting an assistant does not grant additional access. Note that once an answer is rendered, the AI provider's own privacy and data retention terms apply.
What should an engineering firm look for in an AI agent before offering it to clients?
Transparency and attribution. The rules behind every recommendation should be visible and tunable rather than a black box, the agent should state gaps in the data instead of guessing around them, and outputs should carry the firm's own brand when they reach the end client. If the agent cannot be audited, the engineer whose name is on the report carries the risk for a decision they cannot explain.
%20(1)%202%20(1).jpeg)
A practical guide for building operations managers looking to harness AI across their property portfolio. This playbook walks through how to apply AI-driven insights to streamline day-to-day operations, improve energy performance, and make smarter decisions at scale — without needing a technical background. Download your copy to get started.
A sceptical engineering team put PEAK to the test during their first training session, and confirmed a live £25,053-a-year chilled water valve fault within 98 minutes.
Read the story →
