A Practical Test for Agentic AI in Buildings

A buyer's guide to separating useful agentic building tools from chat interfaces, scripted automation and unsupported autonomy claims.

The credible test is not whether an AI can make a recommendation, but whether it can work through a bounded task and leave evidence an engineer can verify.

Those are not the same capability, and they do not carry the same risk.

A useful working definition is that an agent can pursue a stated outcome through several steps, using tools and checking the result as it goes. In a building, those tools might include document search, trend queries, a simulator, a work-order system or, at the highest-risk end, a route to change a control value.

The word "agentic" tells a buyer very little on its own. The questions around it tell much more.

1. What is the agent actually allowed to do?

Start with authority, not intelligence.

Can the agent only read drawings and trends? Can it create a draft report? Can it open a work order? Can it change a schedule or setpoint? Is that permission permanent, or granted for one named task?

An agent that can summarise a fault and an agent that can write to plant should not sit behind the same approval model. Current NCSC guidance for privileged access in OT emphasises just-in-time, least-privilege access and auditing. That is a sensible baseline for automated actors too.

2. What evidence is it reasoning from?

A convincing explanation is not necessarily a grounded one.

Ask whether the answer is tied to named points, time ranges, documents, equipment and prior actions. If the agent says a valve is passing, can it show the command, feedback, temperatures and period that support the conclusion? If it proposes a new sequence, can it identify the specification and safety constraints it used?

Building data is messy. Sensors fail, names drift and manual overrides outlive the person who applied them. A capable agent needs to expose uncertainty rather than smooth it away.

3. Can it prove a proposal before applying it?

A proposed control change can be syntax-checked, simulated against representative conditions and tested against failure cases. A commissioning plan can disclose every intended write before the run. A schedule change can be checked for conflicts and shown to an operator in plain English.

This is not uniquely an AI principle. ASHRAE Guideline 36 is built around documented high-performance HVAC sequences. Deterministic, reviewable control logic remains the right foundation. An agent can help construct and test that logic; it should not make the foundation vague.

4. Who approves consequential action?

Human approval is useful only when the human can understand what is being approved.

"Allow agent to optimise building" is not a meaningful control. "Change the occupied cooling setpoint for these four zones from 22°C to 23°C until 18:00, then restore it" is much closer.

The approval should name the target, scope, duration and recovery path. Higher-impact actions should require stronger evidence and a more deliberate decision. NIST's AI Risk Management Framework similarly calls for defined roles, documented scope and explicit human-oversight processes across an AI system's life.

5. How does it know the action worked?

A successful API response is not the same as a successful building outcome.

If an agent changes a setpoint, it should read back the value from the intended controller. If it starts a plant item, it should check the relevant status and feedback signals. If it creates a work order, it should retain the source evidence and the reason for raising it.

Verification also needs a time horizon. A command may be accepted immediately but fail to produce the expected temperature or pressure response. Good systems distinguish command receipt, device state and physical outcome.

6. What happens on the bad day?

Ask to see a rejected command, a missing device, a failed sensor and a lost network connection.

Does the agent stop safely? Does local control continue without it? Can it restore the previous state? Is the failure visible to an operator? Does the audit record show what was attempted, by which model or workflow, against which version of the data?

This is where many demonstrations become less impressive and more useful.

Where agents help today

There is already valuable work for agents in buildings: searching large project records, assembling a fault timeline, drafting control code for review, creating test cases, triaging incoming work and checking commissioning evidence. These tasks consume engineering time but can be bounded and inspected.

There is also a credible path to more active optimisation. The International Energy Agency sees significant potential for AI to improve heating and cooling efficiency and make building electricity use more flexible. It also identifies familiar barriers: limited digitalisation, fragmented ownership and poor incentives.

In other words, better models do not remove the need for better building data, clearer authority and sound controls engineering.

Automatry's position

Automatry uses agents in engineering and commissioning workflows, with interpreters, simulation, approval and readback around the work. We ensure what we release conforms to these standards, and the agents we release are powerful tools that assist engineers with bounded, reviewable work.

Automatry Core is the longer-term deterministic execution layer for this direction. The Builder and lab testing are proving out well; field adoption is the next step. We're looking forward to deploying our take on what will help the industry.

The most useful agentic building tool will not be the one with the most human-sounding interface. It will be the one that can show its scope, evidence, proposed action, approval, result and recovery path without making an operator guess.