From Audits to Agents: Inside the AI Models Reshaping Building Optimization
Agentic AI for building optimization is software that reads building telemetry, identifies the root cause behind a fault, and converts that diagnosis into a scoped project with an annualized dollar figure attached. Grouping faults by common cause, tracing that cause through connected equipment, and pricing the fix now run without an engineering team driving each step.
Noda is an agentic AI platform for commercial building operations that works as a virtual building engineer, continuously tuning HVAC and energy systems to grow net operating income and protect asset value. On August 26, Jon Schoenfeld, P.E., Noda's Director of AI & Product Innovation, walked through the multi-agent workflows now running against customer portfolios, and the change in frontier models that made them possible. Kate Henningsen opened the session and Andrew Blauvelt ran audience Q&A.
Why did energy audits and fault detection stop scaling?
Every generation of building optimization automated more of the data collection and left the engineering judgment with a person. Judgment is the part that does not scale.
Jon's career tracks that progression closely. He remembers his first energy audit with real pride: a multi-day survey of a BMW manufacturing plant in Greer, South Carolina, twenty years ago. Mechanical rooms and rooftops taught him the trade, and retro-commissioning still surfaces real savings, particularly in plants that have never been properly commissioned. The findings, though, only pay back when the site team executes them, and an audit report starts losing accuracy the day it is delivered, because operational drift continues after the auditor leaves: occupancy patterns shift, sensors fall out of calibration, and overrides get left in place. An audit also covers only the building the auditor walked, so extending the method across a portfolio means paying for a separate engagement in every building.
After about ten years in consulting, Jon left to build software that could find the same problems without sending an engineer to every building. Continuous commissioning answered the staleness problem directly, moving the assessment onto live data so it never aged out between engagements. The freshness problem was solved. Interpretation stayed exactly where it had always been, with an engineer reading output.
Fault detection and diagnostics was where the industry landed next. Rules would run continuously across every asset and catch problems early enough for a site team to get ahead of them.
Savings did not reliably follow, and teams that saw results did so at high cost: most were forced to run triage and root cause analysis by hand, manually assessing and discarding instrumentation noise to categorize, qualify, and quantify the operational projects worth pursuing. In practice, this meant that labor hours merely shifted to another bucket of work. Data modeling added hours of its own, since every point in every building had to be mapped to its equipment, and that equipment to its system, before a rule could fire on it. Machine learning eventually took over part of the mapping, and more sophisticated rules made the detection sharper. Neither change touched the condition of the underlying data.
Operational data in commercial buildings remains notoriously messy and unstandardized. This means that root cause analysis is frequently a manual exercise for engineering teams — even those with good fault detection rules defined and running across their buildings. A rule can flag a deviation, but it cannot tell whether that deviation is a genuine equipment fault, a miscalibrated sensor, or a point mapped to the wrong piece of equipment. Andrew, who has written hundreds of fault algorithms himself, put the scale of that ambiguity at 30 to 40 percent of sensors in commercial buildings failed or failing.
Sorting real faults from instrumentation noise therefore takes an engineer who knows the building, and a fault engine switched on across buildings that have never had one returns findings by the thousand. The engineers qualified to do that sorting are the same ones already carrying the day-to-day load, so prioritization consumes the schedule before any wrench time begins.
The problem has thus persisted across iterations of process and technology for decades. Energy audits and retro-commissioning generate measurements and observations, and a consulting engineer has to interpret them into diagnoses and write the report. Continuous commissioning runs on an ongoing basis over live data, but analyzing its findings and drawing actionable conclusions still reside with an engineer. Fault detection automates the detection itself, but deciding which faults matter, and why, stays with the building engineering team. Each generation of optimization software has automated another step of collection and detection — a worthy advancement — but each has also handed more time-consuming diagnostic work back to the same in-house engineers. Now, for the first time, technology has arrived to solve this entrenched operational challenge: Agentic AI automates that diagnostic step, because frontier models can now carry the domain knowledge and reasoning it requires.
What changed in the AI models?
Frontier models can now apply engineering judgment to a fault. Automating that judgment is the step that stayed out of reach through twenty years of rule-writing and machine learning.
Mechanical and control systems in commercial buildings are well represented in the training data behind today's frontier models, so a model already carries a working knowledge of chillers, air handlers, cooling towers, and the sequences that control them. Those models also reason through a problem across several steps, call tools to fetch what they need, and follow written instructions closely enough to be trusted with one defined job inside a larger workflow.
An agent can now gather the context around a fault, weigh the evidence, and commit to a conclusion, which is the same sequence a building engineer runs when deciding whether a fault is worth a work order.
How do audits, FDD, and agentic AI compare?
| Energy audit and retro-commissioning | Fault detection and diagnostics | Agentic AI | |
|---|---|---|---|
| What it produces | A report of findings | A continuous fault list | A scoped project with root cause, next steps, and annualized impact |
| Cadence | Point in time | Continuous | Continuous |
| Root cause analysis | Manual, on site | Manual triage | Automated across connected equipment |
| Prioritization | Engineer's judgment | Rule severity | Financial impact |
| Relative labor effort per finding | High | Moderate and constant | Review only |
What do Noda's project generation agents actually do?
Four specialized agents hand work to each other in the sequence a building engineer would follow.
Grouping: Reads the fault and insight output for a building and clusters everything that one fix would resolve. A project shown in the demo consolidated five separate insights into a single piece of work.
Refining: Gathers more information on each draft project, ranks them by priority, and discards duplicates of work already in the pipeline. Refining keeps root cause analysis and impact estimation, the two most computationally expensive stages, from spending inference on projects the team has already been given.
Root cause analysis: Pulls data for the suspect equipment and for the equipment upstream and downstream of it, then commits to a cause. It writes a concise description of the problem and the specific next steps required to resolve it.
Impact estimation: Produces the annualized savings figure an owner needs in order to approve the spend, writing and executing analytical code in a controlled sandbox to calculate savings over the measured period and project them across the year. Faults that shorten equipment life carry a maintenance cost alongside the energy cost. Cooling tower fans that short-cycle degrade effective useful life, so the estimate prices the accelerated replacement as well as the wasted kilowatt-hours.
These workflows run continuously in the background with no one triggering them, so a project arrives fully assembled with its supporting data attached. Reviewing one takes a fraction of the time that building one from scratch used to take.
Root cause analysis works down the prioritized list, and Noda measures itself on projects completed. Each task can be assigned to an internal stakeholder or a third-party contractor, and where a CMMS integration exists, a task becomes a work order in one click.
The agents are reusable in isolation too. An engineer can run impact estimation against a manually-entered chiller replacement or VFD retrofit and get an annualized figure for a capital request.
Splitting the work this way follows a principle Jon called progressive disclosure, where each agent collects only the context it needs at the moment it needs it. Handing one agent every data point in a portfolio and asking for a finished project produces unreliable results, if it produces anything at all.
"Working with AI has made us better communicators, because we recognize that we have to write it down in order for AI to understand everything that's in our heads."
Jon Schoenfeld, P.E., Director of AI & Product Innovation, Noda
The recording also covers the separate multi-agent workflow that builds the data model those projects depend on, working from BMS screenshots and raw point lists through successive passes that resolve ambiguous points against historical data.
Why not point a frontier model at building data directly?
Pointing a model directly at building data fails on security, cost, and repeatability.
Continuous analysis means polling every point on every piece of equipment, on an interval, which requires standing read access to the building automation system. The BAS is an operational technology network, and it is the same network that issues commands to chillers, air handlers, and pumps. Granting a general-purpose model an open channel into it widens the attack surface across every building in the portfolio, and no owner or IT security team should approve that.
Inference cost scales with that same polling: reading every point at every interval through a frontier model means re-tokenizing the same telemetry thousands of times a day, which runs into thousands to tens of thousands of dollars a month for a portfolio of any size. The spend also buys an answer that cannot be reproduced, because frontier models are nondeterministic. The same prompt against the same data can return a different savings figure on a second run, and an owner approving capital needs a number that survives a second look from finance.
Noda's architecture is built around security, cost, and repeatability. AI performs the data modeling, and the Independent Data Layer holds the result in a vendor-neutral, time-aligned schema, where an MCP server exposes only the scoped data a given agent is permitted to read. Deterministic fault detection then finds the faults, work that rules do faster and more consistently than a model, and the agents analyze those faults into projects. For more on separating real capability from positioning, see how to evaluate AI claims in commercial real estate.
How do teams correct an agent that gets something wrong?
Teams correct an agent by writing down what it had no way to know.
When an agent reaches the wrong conclusion, the cause is most often tribal knowledge: a fact about the building that lives in the site engineer's head and never made it into a system the agent can read. Every project carries fields for recording that kind of detail, so the engineer who spots the error supplies the missing context inside the project and the agent works from it on the next pass. A site team can also address a project directly in chat, and the update is stored against that project.
Noda collects that feedback automatically. Credentialed professional engineers review agent output during development and alongside customers, and what they find informs the next generation of agents.
What does Noda need from a building to start?
Noda needs a building automation system with its data exposed over an open protocol such as BACnet/IP, Modbus, or MQTT. Each building then gets a site survey and a single gateway.
Noda surveys the site because the agents reason from context, and a large share of that context never reaches the BMS. A Noda engineer walks the chilled water plant and produces a piping diagram of the plant topology, which reads like a single-line drawing and which customers routinely keep for their own use. Photographs of each major asset capture the nameplate design data and equipment capacities that a BMS point list does not carry. Both artifacts land in the Independent Data Layer, where the human engineers and the agents work from the same record of the building.
One device handles connectivity. The Noda LaunchPad, an edge gateway, is installed on the building automation network and makes an outbound-only connection to the cloud over MQTT, so no inbound ports are opened and the BMS needs no reprogramming. From there the data modeling agents build the model the project pipeline runs on, and quantified projects typically reach the customer inside the first 30 days. How Noda integrates with an existing BMS covers the protocol and network requirements in more detail.
Stream the session
Jon's walkthrough covers the architecture and the live platform, and Andrew's Q&A gets into BMS connectivity, agent tuning, and how the corpus of candidate projects is built. Noda is an agentic AI platform for commercial building operations that works as a virtual building engineer, continuously tuning HVAC and energy systems to grow net operating income and protect asset value. The recording is above, and a demo will show the agents running against your own portfolio.
For the earlier session on preparing building data for AI, see Overcoming Building Data Challenges with AI. For definitions and a deeper FDD comparison, see What Is Agentic AI for Building Operations? and the fault detection and diagnostics guide.
Frequently asked questions
What is agentic AI for building optimization? Agentic AI for building optimization watches building systems continuously, works out what is actually causing a fault, and hands the engineering team a defined project with next steps and an annualized savings figure already calculated.
How is this different from fault detection and diagnostics? FDD finds faults and stops there, which leaves triage, prioritization, and root cause work with the site team. Agentic AI treats those faults as an input, groups them into work that a single fix would resolve, traces the cause through connected equipment, and prices the outcome. Noda runs deterministic fault detection to find faults and uses agents to turn them into projects.
Why split the work across several agents? A single agent given an entire portfolio's data has no way to judge what matters for one fault, and its output degrades accordingly. Narrow agents that fetch only what the current step requires, a pattern called progressive disclosure, stay accurate and repeatable.
Can the impact estimation agent price a capital project? Yes. Impact estimation can be pointed at a project an engineer entered by hand, so a chiller swap or a VFD retrofit carries the same annualized savings figure as an automatically generated project.
What does Noda need to connect to a building? Noda connects through a building automation system whose data is exposed over an open protocol such as BACnet/IP, Modbus, or MQTT, plus one Noda LaunchPad gateway making an outbound connection from the automation network to the cloud. A site survey captures the piping diagram and equipment capacities.