What a utility data agent actually does all day

When people hear "AI agent for utility data," they picture one of two things. The optimist pictures a magic button that cleans the whole network overnight. The skeptic pictures a hallucinating intern with write access to the asset registry. Both are wrong, and both are wrong for the same reason: they imagine the agent making decisions. It doesn't. It does something far less cinematic and far more useful — it pays attention, all day, to a model that no human has the patience to watch in full.

So let's drop the abstraction and follow one. Call it NV-1, a network validation agent assigned to a mid-size water utility's distribution model. No demo data, no happy path. Just a normal Tuesday.

The agent doesn't replace the editor or the reviewer. It replaces the gap between them.

What "agentic" actually buys you

07:30 — The shift starts before anyone logs in

NV-1 doesn't "wake up" and ask what to do. Its job is defined before it runs: watch the distribution network for edits, validate each one against the rules of a working hydraulic model, and surface anything that doesn't hold up. That scope is written down, not improvised.

agent: nv-1-network-validation
watch:
  layers: [mains, valves, hydrants, service_lines, pressure_zones]
  on: [create, update, geometry_change, attribute_change]
rules:
  - connectivity        # every main connects to something at both ends
  - flow_direction      # no impossible upstream/downstream loops
  - zone_integrity      # assets inherit the pressure zone they sit in
  - attribute_sanity    # diameter, material, status within valid domains
propose: [attribute_fix, connectivity_flag]
never:
  - commit_without_review
  - edit_geometry        # NV-1 flags geometry; humans move the line

Notice what's not there. NV-1 can't move a pipe. It can't delete anything. It can't commit. Its entire authority is: read the network, check it against rules, and propose. Everything it's about to do all day lives inside that box.

09:14 — An editor does something completely normal

A field-data editor named Dana adds a new service line off a recently installed main on Cedar Street. She snaps it to the main, sets the material, saves. Takes her ninety seconds. She's already onto the next work order.

This is the moment that matters, and it's invisible. Dana did nothing wrong by the standards of the editor — the geometry looks fine, the attributes are filled in, the save succeeded. There's no error dialog. There never is. Bad edits don't announce themselves.

But the main she snapped to was drawn just shy of the distribution main it was supposed to tie into — a two-foot gap that reads as "connected" to the eye and "dead-end" to the network.

09:14:06 — NV-1 notices

Six seconds later, NV-1 sees the edit land and does what it always does: it doesn't trust the save, it traces the network.

flowchart LR
    A[Edit lands:<br/>new service line]:::flow --> B[Trace connectivity<br/>from the new feature]:::flow
    B --> C{Reaches a<br/>source?}:::flow
    C -->|Yes| D[Pass — log and move on]:::good
    C -->|No| E[Dead-end detected:<br/>main has a 2 ft gap]:::risk
    E --> F[Draft a proposal,<br/>not an edit]:::human
    F --> G[(Log every check,<br/>pass or fail)]:::audit
    D --> G

NV-1 runs this on every edit, not a nightly batch. The gap is caught six seconds after it's created — not six weeks later in a fire-flow complaint.

The trace fails. Following the network downstream from Dana's new service line, NV-1 can't reach a source — the two-foot gap breaks the path. To a human scrolling the map at the wrong zoom, those two segments look joined. To a connectivity trace, they're two islands.

09:14 — What NV-1 does not do

Here's where NV-1's configuration does its job. NV-1 has found a real problem. It is certain the trace failed. And it still does not touch the network — because a broken connection on a live distribution main is exactly the kind of high-stakes finding this utility told it to escalate, never resolve alone (more on why that's a choice, and not the only one, further down).

It doesn't nudge the endpoint to close the gap. It doesn't "helpfully" re-snap the geometry. Moving a line is a geometry edit, and geometry edits are on its never list — because the right fix might be to move Dana's service line, or to extend the main, or it might be that the main itself was digitized wrong upstream. NV-1 can't know which. So it does the thing it's actually good at: it assembles the evidence and writes up the case.

{
  "proposal_id": "prop_2026_0623_0914",
  "type": "connectivity_flag",
  "trigger": { "edit": "service_line:SL-90233", "editor": "d.okafor" },
  "finding": "New service line traces to a dead-end; no path to source.",
  "root_cause_candidate": {
    "feature": "main:MN-4471",
    "issue": "endpoint 2.04 ft from MN-4470, below snap tolerance",
    "confidence": 0.88
  },
  "suggested_fix": "Extend MN-4471 endpoint to MN-4470 node (geometry — human).",
  "blast_radius": { "downstream_services": 1, "pressure_zone": "PZ-03" },
  "evidence": [
    "trace:TR-118840 (failed at MN-4471 endpoint)",
    "asof:2026-06-23T09:14:06Z"
  ],
  "status": "queued_for_review"
}

Read that the way a reviewer will. It names the edit that triggered it, the likely root cause (with a confidence number, not false certainty), a suggested fix, and the blast radius — exactly one downstream service, contained to one pressure zone. This isn't an alarm. It's a worked-up ticket.

09:31 — A human closes the loop

The proposal lands in a review queue. A GIS analyst, Marcus, opens it. He sees the failed trace highlighted on the map, the two-foot gap called out, and NV-1's suggested fix. He agrees, extends the main's endpoint to the node himself — because moving the geometry is his call, not the agent's — and approves.

The whole exchange took Marcus under a minute. The alternative — discovering this in a fire-flow analysis or a pressure complaint two months out, then back-tracking through edit history to find which of 4,000 June edits caused it — is a half-day investigation. That asymmetry, repeated dozens of times a week, is the entire economic case.

The rest of the day — mostly nothing, and that's the point

Between 09:31 and end of shift, NV-1 validates 1,847 more edits. It flags three: a hydrant assigned to the wrong pressure zone, a main with a diameter of 0 (a fat-finger), and a valve whose status went from open to blank. The other 1,844 edits pass clean and NV-1 says nothing about them — it just logs that it checked.

pie showData title The handful that mattered: 7 flagged edits
  "Connectivity break" : 2
  "Wrong pressure zone" : 2
  "Out-of-domain value" : 2
  "Missing required attribute" : 1

The 1,844 clean edits don't even make the chart — that's the point. NV-1 validates all of them so it can spend its attention on the 0.4% that would otherwise rot the model from the inside.

That ratio is the thing to internalize. People expect an agent to be impressive in proportion to how much it does. The opposite is true here. NV-1 is valuable precisely because it stays silent on the 99.6% that are fine and spends all its attention on the handful that aren't — the handful no human has the time or patience to catch in a stream of two thousand daily edits.

NV-1 is one configuration, not the only one

Everything above describes how NV-1 is configured — notify-only, hands off the network entirely. That's a deliberate stance this utility took for this model, not a law of how agents work. Risk tolerance is a dial, and where you set it is your call, not the vendor's.

A different team — or the same team on a different layer — might let the agent qualify risk and act on its own where the stakes are genuinely zero, while still routing anything consequential to a human:

The same engine runs all three. What changes is the policy: which findings the agent may resolve itself, which it must hand up, and where the line between them sits. NV-1 happens to treat every finding as review-worthy because connectivity on a live distribution main is the last thing this utility wants a machine deciding alone. Another model — a street-lighting layer, an internal asset catalog — might safely let the agent fix the trivial stuff and only bother a human for the rest.

Why "all day" is the whole pitch

You could do everything NV-1 did with people. Run a nightly validation batch, staff a QA team to read the report, chase down each flag. Plenty of utilities do. The difference isn't capability — it's latency and attention.

• Latency: NV-1 caught Dana's gap six seconds after she made it, while the context was fresh and the fix was cheap. A nightly batch catches it tomorrow. A quarterly QA pass catches it after fifty more edits have piled on top of it.
• Attention: No human reviews 1,851 edits a day with equal care to each. An agent does, because checking the 1,844 boring ones is the only way to be sure about the 7 that matter.

That's what a utility data agent actually does all day. Not magic, not menace — just relentless, narrow, well-bounded attention to a living model, turning the silent edits that break networks into reviewed decisions a human can stand behind.

A network model doesn't fail all at once. It fails one unnoticed edit at a time. The agent's job is to make sure none of them stay unnoticed.

The Nutility operating principle

Want an agent watching your network the way NV-1 watches Cedar Street — every edit checked, nothing committed without a human, all of it audit-ready? Talk to us.