Energy Optimization Agent

An energy optimization agent continuously evaluates building load, weather, tariff windows, and occupancy signals, then proposes HVAC, lighting, and central-plant setpoint changes that reduce energy cost without breaking tenant comfort agreements. The agent is a recommendation layer on top of the building management system (BMS), not an unsupervised controller. Facilities staff define the allowable policy band; the agent suggests moves inside that band; a human confirms the standing rules that govern automatic or assisted apply paths.

For an energy manager supervising setpoints across one or many assets, the practical value is triage and prioritization. Instead of manually scanning hundreds of zones after a weather front or a demand-charge window, you get ranked proposals with expected cost effect, comfort risk, and which zones or plant loops are involved. Systems in this category (for example BuildingIQ and Deepki) differ in modeling depth and portfolio scope, but the operating pattern for the manager is the same: inspect proposals, tighten or widen bands, and refuse anything that would touch life-safety or critical process limits.

The agent should stay silent when required data is missing. If BMS telemetry or occupancy feeds are unavailable, incomplete, or stale beyond your freshness rules, output is empty. That empty state is intentional. Guessing setpoints from last-good values or weather alone can create comfort complaints, equipment stress, or unsafe conditions. Empty output forces a return to the current BMS schedule until data quality recovers.

Reliable proposals depend on a short list of live inputs. Zone temperature, humidity where used for comfort models, supply and return air temperatures, coil and valve positions, fan and pump statuses, and current setpoints come from the BMS. Meter or submeter readings (electric, gas, chilled water, steam) ground cost estimates against actual consumption. Occupancy signals (badge, Wi-Fi, CO₂, PIR, or space booking) tell the agent which zones can tighten setbacks and which must stay in occupied comfort mode.

Tariff and demand-charge calendars matter when cost, not only kilowatt-hours, is the optimization target. A proposal that saves energy overnight but spikes demand during a peak window can raise the bill. Weather forecasts and outdoor-air conditions support free-cooling and pre-cool or pre-heat strategies, but they never replace missing BMS or occupancy data. Without those two foundations, the agent returns no proposals.

Data contracts should include point naming, units, sampling interval, and maximum age. When a critical point drops out, the agent excludes the affected zone or plant loop from proposals rather than interpolating. Partial coverage is acceptable: optimize the floors and systems that still have clean data, and leave the rest on the existing schedule. Energy managers should treat “no proposal for zone X” as a data-health signal, not as an agent failure.

Human-in-the-loop starts with the policy band, not with each individual click. Facilities approve ranges for heating and cooling setpoints, deadbands, lighting levels, plant leaving-water temperatures, economizer enable rules, and maximum rates of change. The agent may only propose values inside those ranges. Expanding a band is a facilities decision; the agent cannot widen its own authority.

Within the band, proposals typically include the recommended setpoint, the previous value, the reason (for example, low occupancy plus mild outdoor air, or approaching a demand window), and a confidence or risk flag tied to model fit and sensor health. Some deployments allow auto-apply only for low-risk moves that stay well inside the band and far from comfort SLA edges. High-risk or edge-of-band moves stay in a review queue. Either way, the standing policy band remains under facilities control; the agent proposes, it does not redefine governance.

Versioning the band helps audits and seasonal changes. Winter and summer bands, event-day overrides, and lease-specific comfort clauses should be explicit documents the agent reads as constraints. When a lease or SLA conflicts with a cost-optimal move, the SLA wins. Cost reduction that triggers tenant credit claims is not a successful optimization cycle.

Rate-of-change limits protect equipment and comfort. Large jumps in leaving-water temperature or zone setpoints can cause hunting, valve wear, or short-term discomfort even if the final value is within band. The agent should propose gradual steps or a time-phased path that respects those limits.

Comfort SLAs define the floor of acceptable conditions: temperature and humidity bands by space type, hours of applicability, and response expectations when complaints rise. The agent scores proposals against those bands using zone sensors and occupancy state. If a proposal would push a zone outside the SLA under expected conditions, it is suppressed or flagged as rejected by constraint, not quietly softened into a “best effort” suggestion.

Life-safety and code-related setpoints are hard exclusions. Smoke-control, stairwell pressurization, freeze-protection, fire-alarm interlocking, emergency lighting, critical server or lab environments with mandated ranges, and any setpoint marked life-safety or life-critical in the BMS must not be auto-overridden. The agent must not propose changes to those points, must not bundle them into bulk “optimize all” actions, and must not treat a missing safety interlock as permission to proceed. If the only available savings path would require touching a life-safety point, the correct output is no change for that system.

These guardrails also cover degraded modes. During fire alarm, freeze watch, or BMS fail-safe operation, optimization pauses. Returning to normal mode should require explicit confirmation that safety and freeze-protection sequences have cleared, not an automatic resume of aggressive cost setpoints.

Day-to-day work is review of proposal batches by building, by tariff window, or by risk tier. You confirm that policy bands still match lease language and seasonal conditions, that occupancy feeds match how spaces are actually used, and that meter-backed savings estimates look plausible against recent bills. You reject proposals that chase cost at the expense of known problem zones (chronic complaints, under-performing AHUs, or spaces with poor sensor placement).

Approval is primarily of the policy band and of escalation rules: which proposal classes may auto-apply, which need energy-manager sign-off, and which always stay manual. Individual setpoint clicks are secondary once those rules are trusted. When BMS or occupancy data is missing, you should see empty output and a data-quality alert, then decide whether to restore points, fall back to schedule, or open a work order for controls or sensors.

Ongoing monitoring closes the loop. Track comfort tickets by zone after accepted proposals, compare modeled versus metered energy for the same periods, and watch for equipment alarms that follow plant setpoint changes. Persistent mismatch usually means bad sensors, wrong occupancy assumptions, or a band that is too aggressive for that asset. Related workflows such as Building Defect Detection via Computer Vision, Contractor Invoice Validation, and Maintenance Request Triage & Dispatch Agent help when savings work exposes envelope issues, invoice disputes on energy projects, or a surge in comfort-related tickets that need dispatch.

The durable operating model is simple: the agent proposes setpoint changes that minimize energy cost inside an approved band; facilities keep ownership of that band and of every life-safety limit; missing BMS or occupancy data yields empty output; life-safety setpoints are never auto-overridden. That split keeps cost optimization useful without turning the BMS into an unsupervised cost-only controller.