AI Agent for Energy Consumption Optimisation

Energy optimisation agents sit on top of meter data, weather forecasts, and equipment setpoints, looking for consumption that doesn't match the pattern and for changes that would cut cost without disrupting operations. The interesting design decision is not the model — it's how much of the loop the agent is allowed to close on its own before a human signs off, especially once "recommend a setpoint change" becomes "write to a building automation system."

Anomaly detection on meter data

Consumption anomalies are a statistics problem before they're an LLM problem: a seasonal decomposition or a simple rolling z-score against a day-of-week/time-of-day baseline catches most equipment left running overnight or a compressor cycling too often. The LLM's job is downstream of that — turning "meter 14 is 340% over its trailing baseline for a Tuesday at 2am" into a readable summary, correlating it against maintenance logs or recent schedule changes, and suggesting likely causes a facilities engineer can act on quickly.

Don't ask the model to eyeball a time series and spot the anomaly itself; LLMs are unreliable at exact numerical pattern-matching over long sequences. Feed it the output of a proper anomaly detector as structured input, and let it do the part it's actually good at: language and correlation across heterogeneous signals (weather, occupancy, maintenance tickets).

Forecasting demand and recommending setpoints

Short-horizon demand forecasting (next 24-48 hours) is typically a dedicated forecasting model — gradient boosted trees or a simple ARIMA/Prophet-style model conditioned on weather and calendar features — not an LLM call. Where the agent adds value is turning the forecast plus current setpoints into a ranked list of recommended changes with an estimated savings and confidence for each, in language a non-specialist facilities manager can evaluate: "pre-cool zone 3 by 1.5°C starting 6am, estimated 4% peak demand reduction, based on tomorrow's forecast high of 31°C."

Human approval before actuation

The line between "recommend" and "actuate" is the entire safety story here. A wrong recommendation costs someone five minutes reading it and rejecting it; a wrong automatic setpoint change on live HVAC or refrigeration equipment can spoil inventory or violate a comfort/safety requirement written into a lease. Route every recommendation through an approval queue by default, and only allow auto-actuation for a narrow, pre-approved set of low-risk changes (e.g., dimming non-critical lighting) with an explicit rollback path.

How the pieces fit together

A workable architecture keeps three tiers cleanly separated: a data tier (meter ingestion, anomaly detection, forecasting — all deterministic or classical ML), an agent tier (LLM synthesizes findings into recommendations, drafts explanations, prioritizes by savings estimate), and an actuation tier (the safety governor plus the actual BMS integration, which only accepts pre-approved, bounded commands). The agent never talks to hardware directly — it writes a recommendation record, a human or the governor approves it, and only then does a separate, audited process send the command.

{
  "zone_id": "bldg-3-zone-7",
  "recommendation": "pre_cool",
  "setpoint_delta_c": -1.5,
  "window": "2026-07-23T06:00:00+03:00/08:00:00+03:00",
  "estimated_savings_kwh": 42,
  "confidence": 0.78,
  "basis": ["forecast:tomorrow_high_31c", "anomaly:none", "occupancy:normal"],
  "status": "pending_approval"
}

Wrapping up

The value in an energy optimisation agent is in synthesis and communication — turning dense meter and forecast data into a short, ranked list of actionable, explainable recommendations — not in the agent directly operating equipment. Keep forecasting and anomaly detection as classical models, keep a hard safety governor between any recommendation and an actual write to building controls, and expand auto-actuation only for the narrow set of changes where being wrong costs nothing worse than a few extra kWh.