What agentic delivery changes in energy and utilities

There is a line running through every utility, and almost every useful statement about software delivery in this industry depends on which side of it you are standing.

On one side is operational technology: the systems that control physical equipment. Substations, generation, distribution, pipeline control. A wrong change here does not degrade a user experience, it operates equipment, and the failure modes involve physical consequences and public safety.

On the other side is an information technology estate that looks like any large enterprise: customer systems, billing, metering data, field service, outage management, trading, regulatory reporting. Large, valuable, and ordinary.

The mistake to avoid is treating these as one engineering organisation with one policy. They are two, and conflating them produces either paralysis on the IT side or something considerably worse on the OT side.

The operational side is not a delivery problem

I want to be direct about this rather than hedge across an entire article: agentic delivery, as described in this series, does not apply to control systems, and the reasons are not squeamishness.

Control systems are frequently vendor-supplied with limited source access. They are certified as configured, so a modification can invalidate the certification. Testing requires either physical equipment or a high-fidelity simulator, both scarce. Change is governed by processes that exist because of past incidents with physical consequences. And the systems often run software that is old by deliberate choice, because stability under known conditions is worth more than currency.

None of that is a constraint that better tooling relieves. There is useful work adjacent to the control estate, and it is mostly not modification: documentation of systems nobody has documented, analysis of historian data, building the simulators that testing depends on, and the engineering tooling around the control systems rather than in them.

The boundary itself is where the risk concentrates

The genuinely interesting engineering problem in this industry is neither estate. It is the interface between them.

Data flows from the operational side into the information side constantly: telemetry, meter readings, equipment status, historian archives. Commands and schedules occasionally flow the other way. That boundary is where the security architecture lives, and it is where an agentic pipeline needs the most careful treatment, because it is ordinary-looking software with extraordinary consequences.

A change to a data ingestion service that reads from the operational network looks like any other integration change in a diff. Its blast radius is not any other integration change. This is exactly the situation described elsewhere in this series as a category crossing, and the response is the same: mark the boundary explicitly in the codebase so a machine can flag when a change touches it, and route those changes to review by someone who understands the security architecture rather than relying on a reviewer recognising the service name.

Where the value actually is

The IT estate at a utility is large, old, and underserved, which is a good profile for this.

Billing and customer information systems are frequently decades old and carry enormous accumulated complexity. Meter data management processes very high volumes with well-specified transformation logic. Outage management, field workforce scheduling, asset management, regulatory reporting: all substantial, all conventional software, all chronically under-resourced because engineering investment goes to the operational side where the perceived risk is.

Regulatory reporting deserves particular mention. Utilities produce a lot of it, the requirements are precise, the deadlines are fixed, and the work is tedious. It is close to an ideal target: well-specified, mechanically verifiable, high volume, and nobody enjoys it.

Criteria matter more where physics is involved

One domain-specific point about acceptance criteria. In most software, a criterion describes a business rule. In utility systems, a meaningful share of criteria describe physical constraints, and those have a property business rules do not: they are objectively true and independently verifiable.

Voltage limits, thermal ratings, flow constraints, capacity bounds. These are excellent criteria precisely because there is no ambiguity about them and no negotiation. A change that produces a value outside a physical limit is wrong, and that is checkable without anyone’s judgement.

Teams often leave these implicit because they are obvious to the engineers involved. Making them explicit is unusually valuable here, because the implementer no longer has the domain instinct that made them obvious.

Implicit, and obvious only to a power engineer:
  "Calculate the transformer loading."
Explicit, and checkable by anything:
Given a transformer with a nameplate rating,
when loading is calculated,
then the result is expressed as a percentage of that
rating and a value above 100 raises an alarm
rather than being recorded silently.
And: a negative or absent reading is rejected as
invalid input, not treated as zero load.

Where this breaks down

Critical infrastructure regulation is real and varies by jurisdiction. Depending on where you operate and what you run, there may be binding obligations on how changes to certain systems are managed and evidenced. That is a conversation for your compliance function, and the honest engineering contribution is producing the evidence they need rather than opining on whether an obligation applies.

The OT and IT split is cleaner in writing than in a real utility. There are systems that sit awkwardly across it, and the awkward ones are usually the important ones. Anything touching the boundary should be treated as operational until somebody with the relevant expertise says otherwise.

Simulation investment is the honest recommendation and it is expensive. Where verification requires a model of physical equipment, that model is the constraint and building it is a capital project, not a tooling decision.

Legacy customer systems may not be in source control in a usable form. The same problem as banking and insurance: if the work of record is a change ticket rather than a commit, the ground-truth premise does not hold, and that needs establishing before anything else.

And nothing here is a security control for the operational network. Marking a boundary in a codebase helps a reviewer notice a change. It is not segmentation, monitoring, or access control, and it should never be presented internally as though it contributes to those.

The takeaway

Utilities are two organisations, and every decision starts with naming which side of the line the work sits on. On the operational side, delivery throughput is not the constraint and the useful contributions are documentation, simulation and analysis rather than modification.

On the information side, the estate is large, old and underserved, and it can adopt everything in this series normally. The layer that needs real care is the boundary between them, because it is ordinary-looking code with extraordinary consequences, and the only reliable protection is marking it so that recognising it does not depend on a reviewer’s familiarity.

If you take one thing into next week: list the services that read from or write to your operational network, and check whether a reviewer would know from the diff alone that they were looking at one.