A playbook for the Head of Grid Data

Key takeaways

• •Who this is for. 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.
• •The problem today. Hand estimation after storms, outage analytics broken by firmware updates and quarterly transformer studies.
• •What changes. Read gaps are detected per collector and recovered when reads arrive, so bills go out on complete reads. Event codes are mapped after firmware updates, so outage analytics stay accurate.
• •What stays with your people. Billing determinants: customers are billed on them, so billing operations approves.
• •The result. A utility that runs billing and grid analytics on the same trusted data.

The PRD for agentic utility data teams

This is the requirements document we would write with you for your team. Everything below expands on it.

What going fully agentic and autonomous means for utility data teams

• •Put your data pipeline on autopilot. Read gaps are detected per collector and recovered when reads arrive, so bills go out on complete reads.
• •Run the data back office without the busywork. The work that fills the week today moves to agents: hand estimation after storms, outage analytics broken by firmware updates and quarterly transformer studies.
• •Scale data without scaling headcount. Event codes are mapped after firmware updates and transformer load is computed continuously, so the data you manage grows without the team having to.
• •Get the plumbing off your plate. A utility that runs billing and grid analytics on the same trusted data.

Who this is for

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.

The shift

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 product you ship

• •Validated interval reads for billing
• •Outage and voltage event data
• •Transformer and asset-health analytics
• •DER and load forecasting data

Where the week goes

• •Meter read gaps after network outages.
• •Estimation and validation by hand.
• •Device firmware changes event formats.
• •Analytics jobs compete with billing.
• •Customer data privacy rules.

Add it up and upkeep is most of the team's week. Here is how a typical week splits today, and once agents own the back office:

Time spent on new data products moves from 14% of the week to 50%. Most of the rest becomes review: people steer and approve agent work instead of doing it by hand.

Then and now

These are the impact metrics we move for utility data teams:

• •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 in this domain:

The biggest change is Customer data access: from about a week to 5 min.

Use cases, in depth

A collector outage

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.

A firmware event change

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.

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.

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.

Without the agents, estimated reads go to billing.

The agents on the job

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 goes on autopilot

Once a domain has earned it, this work runs on its own, and each item removes a problem your team deals with today:

• •Read gaps are detected per collector and recovered when reads arrive, so bills go out on complete reads.
• •Event codes are mapped after firmware updates, so outage analytics stay accurate.
• •Transformer load is computed continuously, so overloads are seen weeks earlier.

Where your people stay in charge

Agents never get blanket access. Each domain has its own autonomy level, set by you, and it only rises when the receipts show the agents are reliable. Everything starts at L1, observing only; reversible upkeep such as reruns, staging fixes, documentation and cleanup is usually first to run on its own.

• •Billing determinants always goes to a named approver: customers are billed on them, so billing operations approves.
• •Rate and operational decisions: these stay with people.

Once a deployment has matured, here is how that ladder plays out across task classes:

Catalog upkeep closes autonomously 88% of the time. For Billing determinants, autonomous closure is 0% by design.

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.

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.

Governance and regulation

Utilities answer to regulators on billing accuracy and customer data privacy. Data Workers provides validation evidence, approvals 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 utility 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. MDM systems validate reads for billing; Data Workers keeps the data feeding analytics complete and governed, alongside the MDM.

The case for your CTO

What this replaces. Hand estimation after storms, outage analytics broken by firmware updates and quarterly transformer studies.

What your team gets back. A utility that runs billing and grid analytics on the same trusted data.

Integration effort. Connecting is configuration, not a migration. The agents attach over MCP to the warehouse, orchestrator, dbt project and source systems you already run, under the roles you already govern, inside your own infrastructure. Your engineers can read every tool the agents call in the open-source core.

Risk and control. Autonomy is set per domain. Everything starts at L1, observing only; reversible work moves up only when the receipts justify it; billing determinants stay at L2 with a named approver; and one org-wide stop halts all autonomous work.

Why now. DER growth and grid modernization need analytics now.

The first win. Per-collector gap detection at L2 for billing. 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, 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:

By month 12, more than 40% of agent actions run fully autonomously while billing determinants stay with a named approver.

FAQ

Does it replace our MDM? No; it works alongside it.

Can it change billing reads? Billing determinants are L2.

Does customer data stay 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 case: https://na.itron.com/w/unlocking-operational-value-with-ami-2.0-data-at-tampa-electric
• •Enterprise data analytics platform and AMI operations case study: https://asiagrowthpartners.com/case-study/enterprise-data-analytics-platform-and-ami-operations/c1263
• •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

Related: Best practices for agentic smart meter and grid data