Best practices for agentic smart meter and grid data: a field guide for utility data teams
How utility data teams move their data back office to agents, practice by practice: the state of the space, the old world and the new, what the agents do step by step, how to set autonomy, who owns what, and how to start.
Meter data now runs the grid, not just the bill.
Validation, gap recovery and governance are repeatable work for agents.
The state of the space
Teams that own smart meter interval data, device events and grid sensor data: AMI operations, meter data management, grid analytics and enterprise data platforms at utilities. Titles include AMI Operations Manager, Grid Analytics Lead and Utility Data Platform Owner.
Millions of meters send 15-minute reads, and utilities now use them for outages, transformer health, DER planning and rate design, not just billing. Billing must never break while analytics grows. Agents keep reads complete, validated and governed so both can run on the same data.
The old world
A storm drops a collector; reads are estimated by hand and billing complaints follow.
It is rarely one failure. Three patterns repeat:
- •A collector outage. A storm knocks out a collector; 40,000 meters miss reads.
- •A firmware event change. A firmware update changes outage event codes.
- •Transformer health as a data product. Engineers run quarterly studies.
The new world
The gap was flagged in 30 minutes, reads loaded on recovery and determinants approved before billing.
Here is that new world as a chain of hand-offs between agents:
These are the impact metrics we move:
- •Customer data access: from about a week to 5 min
- •Event code change mapped: from about 3 days to 15-30 min
- •Transformer product refresh: from about 3 months to 1 day
The rest of this report walks through the 5 practices that make that possible. At a glance:
The practices, one by one
1. Check gaps per collector
Totals hide local gaps.
Why it is harder than it looks. Collector outages hide in network totals.
The old world. Network totals.
The new world. Per-collector checks.
What the agents do, step by step:
- 1.The Quality Monitoring agent calls
get_anomaliesand checks per collector. - 2.The Incident Debugging agent calls
diagnose_incidentand finds the outage. - 3.The Incident Debugging agent calls
execute_backfilland loads recovered reads.
In practice. 40,000 meters flagged.
What to measure. Hours to detect a gap.
2. Protect billing from analytics
Billing must never break.
Why it is harder than it looks. Billing and analytics compete for the same data and compute.
The old world. Contention.
The new world. Separate SLAs and schedules.
What the agents do, step by step:
- 1.The Quality Monitoring agent calls
set_slaand protects billing. - 2.The Autonomous Data-Conductor calls
verify_dataand verifies determinants. - 3.The Usage Intelligence agent calls
detect_usage_anomaliesand flags contention.
In practice. Billing first.
What to measure. Billing delays.
Practices like these compound. Across the routine work they cover:
3. Map firmware changes
Events drive outage analytics.
Why it is harder than it looks. Firmware updates change event codes.
The old world. Broken models.
The new world. Schema Evolution.
What the agents do, step by step:
- 1.The Schema Evolution agent calls
detect_schema_changeand catches codes. - 2.The Schema Evolution agent calls
generate_migrationand maps them. - 3.The Pipeline Building agent calls
sandbox_testand tests models.
In practice. Codes mapped.
What to measure. Event breaks.
4. Turn studies into products
Quarterly studies are late.
Why it is harder than it looks. Studies are late by design.
The old world. Studies.
The new world. Continuous products.
What the agents do, step by step:
- 1.The Pipeline Building agent calls
generate_pipelineand builds the product. - 2.The Quality Monitoring agent calls
create_quality_tests_for_pipelineand adds checks. - 3.The Data Context & Catalog agent calls
generate_documentationand documents it.
In practice. Weeks earlier.
What to measure. Days to detect overload.
Autonomy where work is reversible, a named approver where it matters:
5. Grant customer data by policy
Privacy rules apply.
Why it is harder than it looks. Customer data carries privacy rules.
The old world. Tickets.
The new world. provision_access.
What the agents do, step by step:
- 1.The Data Access & Governance agent calls
check_policyand checks purpose. - 2.The Data Access & Governance agent calls
provision_accessand grants access. - 3.The Data Access & Governance agent calls
generate_audit_reportand logs it.
In practice. Same day.
What to measure. Days to access.
Designing the autonomy ladder
Autonomy is set per task class, not per tool. This is where we would set each class for a mature deployment, and why:
| Task class | Closed autonomously | Escalated | Handled by a person | Where we set it | Why |
|---|---|---|---|---|---|
| Catalog upkeep | 88% | 8% | 4% | L4 once the receipts are clean | The work is reversible and repeatable |
| Backfills | 80% | 14% | 6% | L4 once the receipts are clean | The work is reversible and repeatable |
| Event drift | 68% | 22% | 10% | L3: acts and keeps a rollback point | Most cases are routine; the rest escalate with evidence |
| VEE checks | 74% | 18% | 8% | L3: acts and keeps a rollback point | Most cases are routine; the rest escalate with evidence |
| Billing determinants | 0% | 86% | 14% | L2: always proposed to a named approver | The number carries accountability outside the data team |
The operating model: who owns what
Agents change who does the work, not who is accountable for it:
| Role | Owns | What the agents take off their plate |
|---|---|---|
| Head of Grid Data | Standards, autonomy levels per domain and which domain goes next | Assembling status, chasing owners, keeping the catalog current |
| Domain owners and approvers | Billing determinants | Preparing the diff, blast radius and rollback plan for every proposal |
| Data engineers | Reviewing agent proposals and building new data products | Read gaps are detected per collector and recovered when reads arrive; event codes are mapped after firmware updates |
The swarm behind the practices
| Agent | What it does for you | Tools it calls |
|---|---|---|
| Data Ingestion | Interval reads and device events per collector | get_connector_status, trigger_airflow_dag, register_kafka_schema |
| Quality Monitoring | Gap, range and VEE checks | set_sla, run_quality_check, get_anomalies, create_quality_tests_for_pipeline |
| Incident Debugging | Traces read gaps | diagnose_incident, get_root_cause, prepare_backfill, execute_backfill |
| Schema Evolution | Firmware and event changes | detect_schema_change, validate_schema_compatibility, generate_migration, rollback_migration |
| Pipeline Building | Grid analytics products | generate_pipeline, validate_pipeline, sandbox_test, deploy_pipeline |
| Data Access & Governance | Customer data access by policy | provision_access, check_policy, request_governance_review, generate_audit_report |
Data Context Wizard keeps one governed graph of definitions, lineage and owners that every agent and person answers from. Autonomous Data-Conductor runs each job from detection to a verified result. Spellbook Data Catalog is where your team approves, audits and rolls back, and asks questions in plain English.
What disappears
- •Hand estimation after storms.
- •Billing delayed by analytics.
- •Broken outage analytics.
- •Quarterly transformer studies.
- •Access tickets.
The magic is not any single agent. It is that the back office keeps running: bad data is caught where it enters, every new table gets quality rules and documentation without anyone writing them, access follows policy, fixes are verified before anyone opens a dashboard, and every action leaves a signed receipt.
A product manager's scorecard
| Metric | How to read it |
|---|---|
| Hours to detect a gap | Baseline it in the first week of the pilot; review it monthly. |
| Billing delays | Baseline it in the first week of the pilot; review it monthly. |
| Event breaks | Baseline it in the first week of the pilot; review it monthly. |
| Days to detect overload | Baseline it in the first week of the pilot; review it monthly. |
| Days to access | Baseline it in the first week of the pilot; review it monthly. |
Where this goes next
Utilities will run billing and grid operations on the same continuously validated data, and grid analytics will move from studies to live products that guide DER and capital decisions.
The climb: from assisted to autonomous to agentic
Our thesis is that the data platform climbs the way analytics did, in stages, and that the hard part of data work was never knowing what to do but doing it. For utility data teams, the climb looks like this:
- •Assisted. Agents work alongside your team. They read the whole stack, show what needs doing and propose every fix with a receipt; billing determinants always go to a named approver.
- •Autonomous, under your governance. Routine work runs on its own: read gaps are detected per collector and recovered when reads arrive, event codes are mapped after firmware updates, and transformer load is computed continuously. Your team governs the agents instead of doing the upkeep.
- •The agentic enterprise. Utilities will run billing and grid operations on the same continuously validated data, and grid analytics will move from studies to live products that guide DER and capital decisions.
You choose the altitude, every step is visible and reversible, and the pilot below is the first rung.
The pilot: how utility data teams start
The pilot is how your team proves the value on its own data before committing.
- •What we connect. AMI head-end systems; meter data management systems; Databricks or Snowflake; GIS; outage management systems, over MCP, inside your infrastructure. Nothing migrates.
- •Scope. Per-collector gap detection at L2 for billing.
- •First week. Agents run at L1 across the scoped domain. They map every pipeline, definition and lineage path and show the fixes they would have made, with receipts, so your team sees the value before anything changes.
- •By week two. Read gaps are detected per collector and recovered when reads arrive and event codes are mapped after firmware updates start running on reversible work. Billing determinants stay at L2 with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Customer data access: from about a week to 5 min
- •Event code change mapped: from about 3 days to 15-30 min
- •Transformer product refresh: from about 3 months to 1 day
- •the share of catalog upkeep closed autonomously, targeting 88% as the deployment matures
- •What you decide. Whether to expand to the next domain. The pilot fee is credited in full against the first year.
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
The pilot is the start of a longer curve:
Read the full playbook: Data Workers for utility data teams