Most “smart building” use cases stop at a notification. Agentic use cases don’t — they close the loop. Each one below follows the same anatomy: a trigger the system detects, an action it takes on the building, the systems and data it draws on, the guardrail that bounds it, and the measure that proves it worked. That structure is what separates an agent from a dashboard.
What counts as an agentic use case
A use case is agentic only if the system acts, not just advises. The test is simple: after the trigger fires, does a person still have to do something for anything to change? If yes, it’s analytics. If the system decides and acts within guardrails — and you can see every decision it made — it’s agentic.
Every use case here is written the same way, five lines each, so you can compare them and lift them straight into a spec:
Trigger — what the agent detects. Action — what it does to the building. Systems and data — what it reads and writes. Guardrail — the bounds it operates inside. Measure — how the outcome is verified.
Energy and cost
Continuous HVAC optimization
Primary persona: Energy and Sustainability Manager
- Trigger — live load, occupancy, weather forecast, and tariff signals show the current control strategy is over-conditioning a low-occupancy floor during a high-price period.
- Action — re-sequences plant and shifts setpoints within comfort bounds to cut load through the price peak, pre-cooling earlier when power is cheaper.
- Systems and data — BMS plant and zone points, interval meter, occupancy, weather forecast, and dynamic tariff, resolved against the RealEstateCore model of the building.
- Guardrail — stays inside comfort and equipment limits; plant sequencing respects minimum run and rest times.
- Measure — energy and cost per degree-day, peak demand, comfort-complaint rate.
Demand-charge and demand-response management
Primary persona: Energy and Sustainability Manager
- Trigger — forecast load, or an incoming grid demand-response signal, shows the building on track to set a new monthly peak or a DR window opening.
- Action — stages non-critical loads down and pre-conditions ahead of the window to shave the peak without a comfort hit.
- Systems and data — interval meter, load forecast, DR signal or API, and BMS controllable loads.
- Guardrail — life-safety and critical systems excluded; occupant-facing zones held within their limits.
- Measure — monthly peak demand, DR event performance, comfort exceptions during events.
Comfort and occupant experience
Comfort complaint triage and resolution
Primary persona: Head of Facilities and Operations
- Trigger — a tenant logs a “too warm” or “too cold” complaint, or a cluster of complaints concentrates in one zone.
- Action — correlates the complaint with live zone data, identifies the cause, applies a bounded correction, and logs the diagnosis — raising a work order only if the fix needs hands on site.
- Systems and data — tenant app or ticketing system, BMS zone points, equipment status, and the RealEstateCore model.
- Guardrail — auto-correction limited to setpoint and schedule within range; mechanical faults escalate to a person with the diagnosis attached.
- Measure — time-to-resolution, share of complaints resolved without a truck roll, repeat-complaint rate.
Out-of-hours drift correction
Primary persona: Head of Facilities and Operations
- Trigger — an after-hours scan finds zones running as if occupied — air, heating, or lighting on with no occupancy or schedule reason.
- Action — returns the zones to unoccupied setback and flags the schedule mismatch for review.
- Systems and data — occupancy, schedule, BMS zone and lighting points, and the meter.
- Guardrail — won’t touch zones with an active booking or manual override; respects tenant-controlled areas.
- Measure — off-hours energy use, number of drift events caught, recurring offenders.
Maintenance and equipment health
Fault detection to work order
Primary persona: Head of Facilities and Operations
- Trigger — sensor patterns indicate a developing fault, such as a chiller drawing more power for the same output, or a valve hunting.
- Action — confirms against related points to rule out a false positive, then raises a prioritized work order with the diagnosis, location, and likely part, routed to the right team.
- Systems and data — BMS equipment points, the CMMS or work-order system, and the asset register in RealEstateCore.
- Guardrail — auto-dispatch limited to defined fault types and severities; ambiguous cases go to a human queue.
- Measure — mean time to detect, false-positive rate, share of faults caught before failure.
Predictive maintenance prioritization
Primary persona: Asset and Portfolio Manager
- Trigger — degradation trends across assets suggest several units approaching intervention thresholds in the same window.
- Action — ranks interventions by risk, cost, and disruption, auto-scheduling routine items and proposing a sequence for the capital ones.
- Systems and data — equipment run data, CMMS history, the asset register, and cost data.
- Guardrail — capital or tenant-impacting work is proposed, not executed; routine preventive maintenance is auto-scheduled within policy.
- Measure — planned-to-reactive work ratio, avoided failures, maintenance spend per asset.
Sustainability and reporting
Carbon-aware operation
Primary persona: Energy and Sustainability Manager
- Trigger — a grid carbon-intensity forecast shows a high-carbon window coinciding with flexible load in the building.
- Action — shifts flexible loads — pre-cooling, thermal storage, EV charging — toward lower-carbon periods, within comfort and cost bounds.
- Systems and data — grid carbon-intensity feed, tariff, BMS flexible loads, and the meter.
- Guardrail — comfort and cost limits still bind; carbon optimization won’t breach the budget or the comfort band.
- Measure — operational carbon, cost impact, comfort exceptions.
Reporting-ready data, continuously
Primary persona: Energy and Sustainability Manager, Asset and Portfolio Manager
- Trigger — a reporting period or an ad hoc request needs energy, carbon, and performance data across the portfolio.
- Action — assembles normalized, audit-traceable metrics per building from the live model, instead of a manual data-pull scramble.
- Systems and data — meters, BMS, the RealEstateCore model across buildings, and the target reporting framework.
- Guardrail — figures are traceable to source; where data quality is low, the report flags it rather than silently filling the gap.
- Measure — reporting cycle time, data-coverage and quality score, audit exceptions.
What ties the use cases together
Read together, three things make these work as a system rather than a pile of point features.
Guardrails make autonomy safe. Every use case acts inside bounds the operator sets and escalates at the edge of them. Autonomy is scoped on purpose — the agent takes the routine decisions off a person’s plate, not the judgment.
A shared model makes them portable. Each use case resolves messy, vendor-specific data against one semantic model — the RealEstateCore ontology — so the same logic runs across buildings that were never built to talk to each other. That’s what lets a use case built once run estate-wide, and it’s the answer to a technology leader’s first question: how does this work across our mixed stack without a rip-and-replace?
They compound across a portfolio. One agent overseeing a hundred buildings turns each use case from a single win into a continuous baseline. That shift — from tuning buildings one at a time to operating all of them at once — is what an Asset and Portfolio Manager is actually buying.
Underneath all of it is the same division of labour: the BMS stays the system of record; the agent is the system of action on top of it.
