Blog

LLMs in Building Automation: What AI Can & Can't Do

An LLM won't run your chiller plant - and you should distrust anyone who says it will. What large language models actually do in building operations, and how CobiBot applies them.

Tan Kok XinTan Kok Xin
Reviewing energy data on a laptop with an AI assistant

LLMs in building automation: what AI can and can't do

The honest version of "AI for buildings" is narrower and more useful than the hype. A large language model will not run your chiller plant, and you should be wary of anyone who says it will. What an LLM is genuinely good at is the part of building operations that has always been the bottleneck: turning a mountain of sensor data into a plain-language answer a human can act on. The control stays where it belongs — deterministic, fast, at the equipment. The LLM sits on top as the interface between people and the building's data. Get that division right and it's transformative; get it wrong and it's a confident liar.

Here's what LLMs actually do in building automation, where they don't belong, and how CobiBot applies them.

What an LLM is good at — and what it isn't

LLMs are language and reasoning engines. They're strong at exactly the things building operators lose hours to:

- Answering questions in plain language — "what set my peak demand last month?" — instead of building a query or a report.
- Summarising and explaining — turning a week of half-hourly data into "consumption rose 12%, mostly overnight, driven by the chiller running off-schedule."
- Drafting reports — EECA submissions, ESG summaries, anomaly write-ups — from underlying data.
- Decision support — surfacing what looks abnormal and suggesting where to look.

They are not real-time controllers. Staging a chiller, holding a setpoint, tripping an interlock — these are deterministic, millisecond, safety-critical jobs that must run reliably whether or not the internet is up. That's the edge control layer, and an LLM has no business inside that loop. The model's place is one level above: reading what the control and monitoring systems produce, and making it intelligible.

The real risk: a confident liar

The defining failure mode of an LLM is hallucination — producing a fluent, plausible answer that is simply wrong. In a chatbot writing a poem, that's harmless. In a tool telling a facility manager their peak demand, it's dangerous, because the number looks authoritative.

This is the single most important thing to understand about LLMs in building automation: an ungrounded LLM will invent your energy figures. Ask a raw model "what was my power factor in March?" and it will happily produce a number it has no way of knowing. The fix isn't a better-sounding model — it's grounding: forcing the model to answer only from real, retrieved data, and to fetch that data through defined tools rather than from its own memory.

A trustworthy building AI therefore isn't judged on how well it writes. It's judged on whether every number it gives you traces back to an actual sensor reading. The language is the easy part; the discipline of grounding is the whole game.

How CobiBot applies LLMs — grounded, not guessing

CobiBot is Cobler's AI assistant, and it's built around exactly that discipline. It uses a large language model (Anthropic's Claude) for the language and reasoning, but it does not answer energy questions from the model's imagination. It answers them by querying your building's live data through a defined set of tools — the same hierarchy of locations, equipment and sensors the rest of the platform runs on — using the open Model Context Protocol (MCP) to connect the model to that data.

In practice that means you can ask, in plain language:

- "What was our maximum demand last month and what drove it?" — and it pulls the actual 30-minute peak, not an estimate.
- "Is our power factor below the surcharge threshold anywhere?" — and it checks the real readings against the 0.85 limit.
- "Which sites had CO₂ over 1,000 ppm this week?" — and it reads the actual IAQ sensors.
- "Draft the EECA report for this site." — and it assembles it from metered data.

Every answer is anchored to real readings across energy, demand, power factor, indoor air quality, water, equipment condition, tariffs, alerts and M&V — because the model is only allowed to speak from what it retrieves. That's what separates a useful building assistant from a plausible-sounding one. It's also why anomaly explanations are trustworthy: the anomaly detection runs on real analytics, and the LLM's job is to explain the finding in context, not to invent it.

Two design choices that make an LLM safe in a building

Two principles keep CobiBot on the right side of the line:

Data access is read-only by default. The assistant fetches and reasons over your data; it doesn't quietly change things. Actions that do change state — editing a report, for instance — are explicit, separate, and guarded, never a side effect of a chat. The deterministic control of the building stays in the control layer, untouched by the conversation. The LLM informs decisions; it doesn't seize the controls.

Answers adapt to the reader, not the data to the answer. The same underlying figures can be delivered to an executive as a two-line summary, to an energy manager as a KPI breakdown, or to a technician as equipment-level detail. The numbers don't change with the audience — only the framing does. That's the right use of a language model: it's a translator, fluent in both the building's data and the reader's role.

Where this leaves the engineer

LLMs don't replace the people who run buildings, and CobiBot isn't built to. What it removes is the friction between a question and its answer — the half-day of pulling data, building a chart, and writing it up before anyone can decide anything. The engineer still decides; the assistant just gets them to the decision faster, and makes the building's data reachable for the people who aren't fluent in dashboards.

That's the realistic, valuable role of AI in building automation today: not an autonomous building that runs itself, but a layer that finally makes a building's own data easy to ask questions of — grounded in what the sensors actually say. It fits naturally on a platform whose whole job is unifying that data, which is what CobiNeural is and how it turns data into decisions.

To see CobiBot answer questions against a real building's data — and check its working — book a CobiNeural walkthrough.

FAQ

Frequently asked questions

Keep Reading

Related articles