The freezer drifting warm, the lift starting to vibrate: the sensors already know, hours before anyone complains. This agent watches them across a retailer's stores, turns a fault into a costed work order, and escalates a critical dispatch to a human. The value is not a smarter alarm. It is the governed decision that follows the alarm.
In most retail estates, an asset is fixed when it breaks. The chiller fails and the stock spoils, the lift stops and the store posts a sign. The sensor data that would have warned everyone hours earlier sits unwatched, because no one can monitor hundreds of assets across dozens of stores by hand. The cost is paid twice, once in the emergency call-out and again in the customer-facing failure that triggered it.
Every building-management system can already fire "temperature > limit". If that were enough, no stock would ever spoil. A static threshold fails in exactly the ways that matter:
So the design is a degradation model (trend → time-to-failure horizon), weighted by asset criticality, feeding a governed work order. The consequential, billable dispatch goes to a human.
When a fault is detected, the agent opens a work order, checks warranty, criticality and parts, and models the repair options in cost and time, all deterministic. The model narrates and drafts; it doesn't decide. Low-criticality faults auto-raise; a critical or costly dispatch is escalated to the facilities manager. A technician is never sent on the agent's say-so.
A refrigeration unit at the Orchard store reads 9.6°C against an 8°C limit. It is high criticality and out of warranty. The agent opens a work order and models three options:
| Asset · fault | Criticality | Recommended option | Cost | Decision |
|---|---|---|---|---|
| Refrigeration · 9.6°C / 8°C | critical | Emergency vendor call-out (3h) | S$3,240 | escalate → facilities |
| Lighting circuit · flicker | low | In-house, next shift (14h) | S$250 | auto work-order |
The honest part. The detection in this build is threshold-based. It fires when a reading crosses its limit. The degradation-to-time-to-failure model in fig.1/fig.3 is the design, not yet the running code. I'm showing it because a static threshold is genuinely not predictive maintenance, and pretending otherwise wouldn't survive a facilities engineer's first question. What the demo does prove is the part that a plain BMS alarm lacks, the governed orchestration: a fault becomes a costed, criticality-prioritised work order, then a human-authorised dispatch, all logged. The detection model is a known upgrade path; the governance is built.
seq : 2 agent : Smart-building agent action : dispatch_technician subject : WO-A / AST-001 (refrigeration, Orchard) tier : high decision : escalate → facilities policy : POL-GOV-HITL reason : critical asset · billable dispatch routed to a human prev_hash : d1c0…3a77 hash : 5e9b…f140
This applies the same instinct as the rest of the portfolio to physical assets. I re-engineer a reactive process into a proactive one, and I keep the consequential action, a billable dispatch on a critical asset, under a human's authority. And I'll say plainly where the build stands. The orchestration and governance are real; the degradation model is the next step. Drawing that line honestly, and logging both sides of it, is what makes operational AI safe to run across an estate.
The work order and ledger entry above are real output from the agent over a synthetic sensor layer for Origin's stores. The full console runs as a working application, with live faults, costed options, and escalated dispatches.