EnergyOps Agent

Problem & responsibility

Business problem: unstable cumulative readings must become auditable statistics and settlement, while the agent must operate business capabilities without overstepping. I led the design and delivery of agent runtime governance and the eval loop; my mentor owned business direction.

System flow

1. Cumulative readings
2. Quality states
3. Interval usage
4. Layered aggregation
5. Diagnosis
6. Alert loop
7. Agent calls

Engineering focus

Data Quality

Seven quality states plus a trusted whitelist; only trusted intervals enter aggregation — no unsupported estimates.

Runtime Governance

Dozens of MCP tools consolidated into six capability bundles with R0/R1/R2 risk tiers and Before/After Tool hook chains.

Recoverable Ops

Idempotency windows, persisted task state, and startup backfill — restarts and out-of-order data leave no aggregation gaps.

Evidence

Eval

replay eval · task completion ≈ +12pt

Security

all internal privilege cases blocked

Perf

core API P95 ≈ −86% (fixed query set)

Ops

manual backfills ≈ −70% · scheduler 99%+

Pipeline

raw → interval → hourly → daily

Python · FastAPI · PostgreSQL · MCP · WPS Comate · pytest

Design tradeoffs

1. Put the safety boundary in a hook chain, not in the prompt

   Why

   To the model, “query” and “publish” are just two different tool names — it has no sense of what an operation actually costs. Drawing the boundary in a prompt means handing safety to probability.

   Cost

   Every write tool needs an explicit parameter schema, risk tier, idempotency key, and audit fields, and R2 additionally needs a confirmation state — far more expensive than adding a sentence to a prompt.

2. Split anomaly candidates from business alerts into three layers

   Why

   Treating “data deviates” as equivalent to “send an alert” buries the handful of incidents that matter under a flood of low-value notifications.

   Cost

   Adaptive baselines, candidate scoring, and quiet windows become three separate configurations to maintain, and operations inherits one more model to understand; during cold start there is not enough history, so the honest output is “undetermined”.

3. Only trusted intervals enter aggregation — no estimating questionable readings

   Why

   Estimated values look more complete, but once they reach settlement they cannot be traced back. Better to leave a visible gap in coverage than to book a number of unknown provenance.

   Cost

   Coverage reads lower than a “count everything” approach and the gap has to be explained to the business; backfilling stays a manual process and cannot be automated in the short term.

4. Offload large results to artifacts instead of putting them in context

   Why

   Reading detail runs to tens of thousands of rows; putting that in context only crowds out the information that actually needs reasoning, and inflates cost.

   Cost

   The model keeps only an aggregate summary and a reference, so detail requires a second fetch — one extra tool round-trip in exchange for a bounded context.

What this system does not do

Deliberate non-goals. A boundary that is written down is a boundary that can be held.

• Does not replace the existing acquisition platform for physical metering or protocol integration
• Does not directly control HVAC, lighting, or chiller plant
• Does not handle maintenance dispatch, shift scheduling, or SLA timing — work orders stop at the notify → guide → feedback → close loop
• Does not replace the finance system for bookkeeping, payment, invoicing, or the general ledger
• Does not perform formal carbon accounting, ESG disclosure, or ISO 50001 certification
• Does not treat an anomaly candidate as automatically equivalent to a confirmed incident
• Does not let the model modify raw readings, decide charges, or bypass business rules
• Does not expand into access control, fire safety, asset, or property management

Open questions

What I do not have an answer for yet. Happy to be asked about any of these.

• The adaptive baseline raises both false positives and false negatives during seasonal changeovers; human confirmation covers it today, and per-usage-type modeling needs more samples than we have
• Anomaly scoring weights still come from human judgment — there is no labeled candidate-to-incident data to calibrate against
• Work orders stop at the information loop; without maintenance-system scheduling and SLA data, disposition outcomes cannot be quantified back
• R2 write operations require per-action human confirmation, and there is no good answer yet for confirmation UX under batch or high-frequency load