The agentic data platform for utilities: a guide for data leaders
This guide explains how utility data teams adopt agents for their data back office. It covers the shift underway, the use cases that matter most, charts of the impact, how the agents work together, and a month-by-month path to autonomy.
Key takeaways
- •Who this is for. Data leaders and teams at electric, gas and water utilities.
- •The problem today. Most of the data team's week goes to hand estimation, broken outage analytics and quarterly studies.
- •What changes. Specialised agents take that work over across the systems you already run: they catch bad data where it enters, fix it where it lives and verify the number before anyone reads it.
- •What stays with your people. Anything regulated or customer-facing waits for a named approver with the full diff, blast radius and rollback plan in front of them.
- •The result. Data teams that spend their time on grid analytics on trusted data.
The PRD for agentic data in energy and utilities
This is the requirements document we would write with you. Everything below expands on it.
| Who | Data leaders and teams at electric, gas and water utilities. |
| The job | Meter and grid data that runs billing and the grid. |
| Environment | AMI head-end systems; meter data management systems; Databricks or Snowflake; GIS; outage management systems, and the other platforms your teams run. |
| Constraints | Regulated and customer-facing numbers always go to a named approver; agents run in your infrastructure under the roles you already govern. |
| Success is measured by | 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; catalog upkeep closed autonomously 88% of the time. |
| Owned by | The head of data or CDO, with domain owners as named approvers. |
| Pilot scope | Per-collector gap detection at L2. |
What going fully agentic and autonomous means in energy and utilities
- •Put your data pipelines on autopilot. Agents catch bad data where it enters, fix it where it lives and verify the number before anyone reads it.
- •Run the data back office without the busywork. The week that goes to hand estimation, broken outage analytics and quarterly studies moves to agents.
- •Scale data without scaling headcount. New sources, partners and data products are onboarded as missions, not projects.
- •Get the plumbing off your plate. Data teams spend their time on grid analytics on trusted data.
The shift
AMI turned utilities into data companies: millions of meters sending 15-minute reads, device events and voltage data. Billing must never break, while grid analytics, DER planning and rate design all want the same data.
Our view: agents should keep reads complete, validated and governed so billing and grid analytics run on the same trusted data.
A day on a energy and utilities data team today
A storm takes out a collector and 40,000 meters miss reads. A firmware update changes outage event codes. Engineers wait for a quarterly transformer study while overloads grow.
That week is typical, not exceptional. Here is where the time goes, today and with agents on the back office:
Then and now
| Work | Today | With Data Workers |
|---|---|---|
| Read gaps | Estimated by hand | Detected per collector, recovered |
| Event changes | Broken outage analytics | Mapped on arrival |
| Billing vs analytics | Contention | Billing protected |
| Transformer health | Quarterly studies | Continuous products |
| Customer data access | Tickets | Policy-based |
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
Across the routine work:
Use cases, in depth
Bills on complete reads after a storm
Today. A storm knocks out a collector; 40,000 meters miss reads.
With Data Workers. Quality Monitoring flags the gap per collector, Incident Debugging traces it, Conductor backfills when reads arrive and verifies billing determinants.
What changes. Billing runs on complete reads. Read the playbook.
Outage analytics that survive firmware updates
Today. A firmware update changes outage event codes.
With Data Workers. Schema Evolution maps the codes; Pipeline Building updates outage models.
What changes. Outage analytics stay accurate. Read the playbook.
Transformer health as a data product
Today. Engineers run quarterly studies.
With Data Workers. Pipeline Building builds a continuous transformer-load product with tests.
What changes. Overloads are seen weeks earlier. Read the playbook.
Agents working together: A storm-damaged collector
Minute by minute
Illustrative example. Interval reads land from the head-end into a lakehouse; billing determinants compute nightly.
| Time | Who | What happens |
|---|---|---|
| Tue 18:00 | Head-end | Collector 77 offline |
| 18:30 | Quality Monitoring agent | Gap flagged for 40,000 meters |
| Wed 00:10 | Head-end | Collector recovers; backlog sent |
| 00:30 | Quality Monitoring agent | Reads loaded; VEE checks pass |
| 01:00 | Spellbook Data Catalog | Determinants proposed |
| 07:30 | Spellbook Data Catalog | Billing lead approves |
How it fits your stack
Data Workers connects to what you already run: AMI head-end systems; meter data management systems; Databricks or Snowflake; GIS; outage management systems. Each agent is an MCP server, so the same agents work inside Claude Code, Cursor or Codex and in Slack or Teams through Spellbook. Nothing migrates.
- •Runs in your infrastructure with your credentials and your model key. The hosted Autonomous Data-Conductor sees workflow metadata only, never rows.
- •Uses the access you already govern. Agents act under scoped service identities and your existing roles; every grant goes through provision_access and is logged.
- •Proposes changes as diffs in your dbt project, orchestrator and warehouse, with blast radius, tests and a rollback point, and applies them only at the autonomy level you set for that domain.
- •Open-source core. The Apache-2.0 community edition ships 11 agents and 160+ MCP tools, so your engineers can read exactly what the agents call.
How autonomy expands over the first year
Autonomy is earned per task class. In a mature deployment, it looks like this:
A typical path: month 1 at L1 everywhere; months 2 to 3, L3 and L4 on reversible upkeep; months 4 to 6, new data products built by the swarm; months 6 to 12, wider autonomy where the evidence supports it, with regulated or customer-facing numbers kept at L2.
What happens when an agent is wrong
- •At L2 propose, nothing changes until a named person approves. The proposal shows the full diff, the blast radius and how to roll it back. Unanswered requests expire and escalate.
- •At L3 act, reversibly, every change keeps a rollback point, and Conductor verifies the downstream number after the change. If verification fails, the change is reversed and the domain drops a level.
- •No agent approves or promotes its own work. Autonomy only grows on evidence, per repair class, and repeated errors shrink scope automatically.
- •One org-wide stop halts all autonomous dispatch, and every action lands in a hash-chained audit trail you can export with generate_audit_report.
Governance and regulation
Utilities answer to regulators on billing accuracy and customer data privacy. Data Workers provides validation evidence, approvals on billing determinants and access logging.
Data Workers doesn't make you compliant; your controls, people and assessors do. It supplies controls and evidence wherever agents touch data. Not legal advice.
The alternatives energy and utilities data teams weigh
Build it yourselves. A strong team can wire a coding agent to MCP servers for the warehouse and dbt. The work is everything around it: routing approvals to the right owner, blast radius, rollback, receipts, and current context about every other system.
Observability, catalogs and point tools. Observability alerts, catalogs document, and quality tools test. Data Workers takes their signals, diagnoses, proposes the fix, verifies it and leaves the receipt.
Platform-native agents. Snowflake made its managed MCP server and Cortex Agents generally available on Nov 4, 2025, and Databricks made Genie One generally available on Jun 16, 2026. They are excellent inside their platform; this work crosses the source systems, orchestrator, warehouse and BI, and Data Workers works across all of them.
In this space specifically. Meter data management systems validate for billing; Data Workers works alongside them to keep analytics data complete and governed.
The case for your CTO
What this replaces. The week spent on hand estimation, broken outage analytics and quarterly studies.
What your teams get back. Time for grid analytics on trusted data, on data that is verified before anyone reads it.
Integration effort. Connecting is configuration, not a migration. The agents attach over MCP to the platforms you already run, under the roles you already govern, inside your own infrastructure.
Risk and control. Autonomy is set per domain, starts at L1 and rises only on evidence. Regulated and customer-facing numbers stay at L2 with a named approver, and one org-wide stop halts all autonomous work.
Why now. Grid modernization and DER growth need analytics now.
The first win. Per-collector gap detection at L2. The pilot below lays out the scope, what you see each week and the cost.
The climb: from assisted to autonomous to agentic
Our thesis is that the data platform climbs the way analytics did, in stages. In energy and utilities, that climb looks like this:
- •Assisted. Agents work alongside each data team, read the whole stack and propose every fix with a receipt. Regulated and customer-facing numbers always go to a named approver.
- •Autonomous, under your governance. The upkeep behind hand estimation, broken outage analytics and quarterly studies runs on its own, domain by domain, as the receipts earn it.
- •The agentic enterprise. The platform largely runs itself. People set direction and standards, and the teams spend their time on grid analytics on trusted data.
You choose the altitude, every step is visible and reversible, and the pilot below is the first rung.
The pilot: how energy and utilities data teams start
The pilot is how a 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.
- •First week. Agents run at L1 and show the fixes they would have made, with receipts.
- •By week two. Reversible upkeep (reruns, staging fixes, documentation, cleanup) runs on its own; regulated and customer-facing numbers 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%
- •What you decide. Which domain or team goes next. 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.
Teams we work with in energy and utilities
FAQ
Does it replace our MDM? No.
Can it change billing reads? Billing determinants are L2.
Is customer data protected? Access is policy-based and logged.
Where do the agents run? In your infrastructure, with your credentials and model key. The hosted Conductor sees workflow metadata only.
Do we have to migrate anything? No. Your warehouse, dbt project, orchestrator, catalog and BI stay where they are.
Sources
- •Itron, Tampa Electric AMI 2.0: https://na.itron.com/w/unlocking-operational-value-with-ami-2.0-data-at-tampa-electric
- •Data Workers pricing: https://dataworkers.io/pricing/
- •Data Workers open-source repository (tool registrations): https://github.com/DataWorkersProject/dataworkers-claw-community
- •Snowflake, managed MCP server and Cortex Agents GA release note (Nov 4, 2025): https://docs.snowflake.com/en/release-notes/2025/other/2025-11-04-cortex-agents-mcp
- •Databricks, Genie One launch (Jun 16, 2026): https://www.databricks.com/company/newsroom/press-releases/databricks-launches-genie-one-all-new-agentic-coworker-every-team