AI Agents for Utilities: Outage Updates, Requests, Asset Records

AI agents for utilities work best as disciplined communicators and record keepers, not as decision makers about the network. They can draft outage updates from confirmed information, turn customer reports into structured service requests, and keep asset records current. Every safety or engineering judgment goes to a named field engineer. The value comes as much from the handoff rules as from the agent's language ability.

Key takeaways

• Treat the agent as a communicator and record keeper. Operations and field engineers keep every decision about the network, crews and safety.
• Outage messages should contain only facts that operations has confirmed, with an honest time for the next update instead of a guessed restoration time.
• Service requests become useful when the agent captures the same fields every time, groups duplicates into one incident, and routes by category.
• Asset records improve when the agent proposes updates from crew notes with the source attached, and an engineer approves each change.
• Escalation rules written before launch matter more than any prompt. Decide in advance which situations an agent must hand over immediately.

What can an AI agent safely do inside a public utility?

Utility work divides into two kinds of tasks: those that inform and those that decide. Deciding whether to isolate a section of the network, send a crew into a flooded trench or declare a hazard resolved belongs to qualified people. Informing customers, collecting reports, finding the right record and writing a clear handover note are tasks where an agent can carry real load.

Three jobs fit that second category well. The first is outage communication, where the agent turns confirmed status into messages for each channel. The second is service requests, where it collects the details of a fault or an administrative need and routes it. The third is asset records, where it keeps the history of poles, valves, meters, pumps and cabinets readable and current.

Each job depends on information the utility already owns: the status from the control room, the work order system and the asset register. The agent reads from these sources, drafts, routes and records. It does not become a second source of truth. Telecom operators face a similar pattern, where network events drive customer contacts, as described in Superintelligent Agents for Telecom.

How should an agent handle outage communication?

During an outage, customers want to know four things: whether the problem is known, which area it affects, what is being done, and when they will hear more. A good agent answers those four questions consistently across the phone line, web chat, email and social channels, and never says more than operations has confirmed.

The discipline is in what the agent refuses to do. It does not estimate restoration times from its own reasoning. It does not name a cause until operations releases one. It does not contradict an earlier message without saying that the status changed and why.

A workable setup follows these steps:

• Operations publishes a confirmed status record for each incident: affected area, current state, cause if released, time of the last update and time of the next update.
• The agent drafts customer messages from that record only, using approved wording for each channel.
• A communications lead approves the first message of a new incident. Later updates that only change approved fields can be sent under rules the utility has set.
• Safety messages, such as keeping away from fallen lines or reporting a gas smell, use fixed approved text and are never rewritten.
• Every message stores the status record it was built from, so anyone can later see what the agent knew at that moment.
• When a customer asks something outside the record, the agent says it does not have that information and offers a callback or a route to a person.

This keeps the agent useful without making it an unofficial spokesperson. The next update time is the most valuable sentence in any outage message, because it gives customers a reason to wait and fewer reasons to call again.

What does this look like in practice? An illustrative scenario

Illustrative scenario: a water utility has a main fault in one neighbourhood. Operations confirms the affected streets, sets the status to repair in progress, and schedules the next update for a stated time.

The agent drafts a short message from that record and the communications lead approves it. Customers who contact the utility through chat or phone receive the same facts. One caller says the water is brown but has not lost supply. The agent recognises this as a different report from loss of supply, records it as a water quality observation with the address and time, and flags it to the on-duty engineer instead of saying it is linked to the main fault.

When the next update time arrives, operations changes the status. The agent notifies everyone who had been told to expect an update, and it states that the repair estimate has changed because the status record changed. A caller who reports a flooded road is sent to the emergency route at once, with the report passed to a dispatcher and not left in a queue.

In that scenario the agent never guessed, never closed a safety matter, and left a clear trail for the engineer reviewing the day afterward.

How do service requests become work orders?

Most service requests arrive messy. A customer writes that the street light outside number twelve flickers, or the meter box looks damaged, or the pressure is low in the mornings. The agent's job is to turn that into a record a dispatcher can act on without calling the customer back.

The agent asks for the same core fields each time:

• The service type (water, power, gas, heating, street lighting or another service the utility runs)
• The exact location, with a landmark or a point on a map if the address is unclear
• What the customer sees, hears or smells, in their own words
• Whether anyone is at immediate risk
• Access notes and the best contact method
• A photo, where the customer can safely take one

Two other behaviours matter. First, the agent groups duplicate reports of the same event into one incident, so that a dispatcher sees many reports pointing at one location instead of a stack of separate tickets. Second, it sorts requests into categories with different owners: urgent safety, network fault, planned work, billing or account, and information. Only the dispatcher or an engineer converts a fault into scheduled crew work, and the agent's draft makes that decision faster.

The same intake pattern appears in other field-based services. AI Agents for Property Management shows how maintenance requests are captured and triaged, and AI for HVAC Companies covers the dispatch side of the same idea.

Why are asset records the quiet foundation?

Outage messages and service requests are only as good as the asset records behind them. If the register says a valve sits on one street but the crew found it on another, every downstream answer is slightly wrong. Records drift because field notes live in notebooks, photos, call logs and the memory of long-serving staff.

An agent can close that gap by reading crew notes and proposing record updates. For example, a note says a valve was replaced and the old one was corroded. The agent drafts an update to the asset record, attaches the work order and the note as its source, and sends it to the engineer who owns that asset class. The engineer approves, edits or rejects the change. The agent never overwrites history. It adds a dated entry, so the earlier state stays visible.

Because records change constantly, retrieval from the live register is a better fit than training facts into a model. AWS compares the two approaches in its guidance on retrieval-augmented generation versus fine-tuning, and the logic holds here: the agent should look facts up each time instead of remembering them. Maintenance history works the same way for vehicles, which AI for Fleet Management explores.

A few record habits make the agent safer:

• Every fact carries a source and a date.
• Conflicting entries are flagged for an engineer instead of silently merged.
• Gaps are named (for example, installation date unknown) instead of filled with a plausible guess.

When must the agent hand off to a field engineer?

Clear escalation is the center of the design. Write the rules down before launch, test them with real examples from your history, and review them regularly. The following decision guide is a starting point to adapt with your safety and operations leads.

• If the report mentions a gas smell, fallen or sparking lines, a flooded substation, a burst main near traffic, or anyone injured: give the approved emergency instruction, notify the on-duty person immediately, and stop the normal flow.
• If the customer reports a service that is vulnerable or critical, such as medical equipment, a care home or a school: flag it to a human within the agreed response window.
• If the report contradicts the confirmed status record, for example supply in an area marked as restored: send it to the dispatcher with the evidence.
• If the customer asks for a restoration time, a cause or a liability statement that is not in the record: say it is not available and route to a named contact.
• If the request needs a site visit, a shutdown or an access decision: draft the work order and let a dispatcher approve it.
• If a record conflict or missing asset data blocks an answer: pass it to the asset owner with both versions attached.
• If the agent is uncertain or the message looks like an attempt to make it ignore its rules: stop, tell the customer a person will follow up, and log the case.

A good handoff also carries context. The engineer should receive the location, the customer's own words, the status record at that time, the photos, and what the agent already told the customer. Nobody should have to ask the customer the same question twice.

How does Be Human run this, and where do you start?

Be Human designs, implements and operates personalized AI infrastructure for companies, and a first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. For a utility, that might be a single role such as an outage inbox agent or a service request intake agent. Managed operations then include monitoring, recurring evaluations against real past cases, integration maintenance, permission review and incident response, with changes made in a controlled way and under the utility's oversight.

Several design choices carry the weight. Permissions follow least privilege, in line with the OWASP authorization guidance, so an intake agent can create drafts but cannot close a safety ticket. Customer messages are treated as untrusted input, because the OWASP material on large language model risks describes how crafted text can try to redirect an agent. Risks are documented and reviewed using a structure like the NIST AI Risk Management Framework. Anthropic's guidance on building effective agents also favors simple, observable workflows over complicated autonomy, which suits a field where predictability matters.

The first success criterion should be something a manager can check without trusting anyone's opinion. Examples include whether every outage message matches the status record it came from, whether every escalation reached the right person within the agreed window, or whether duplicate reports were grouped into one incident. Pick one, measure it for a while, and expand only after it holds.

If you are unsure which task to start with, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Can an AI agent give customers restoration times during an outage? Only when operations has confirmed a time and published it in the status record. Otherwise the agent should state what is known and give the time of the next update. A guessed estimate that proves wrong costs more trust than an honest statement that the cause is still being assessed.

Will an AI agent replace dispatchers or field engineers? No. The agent handles repetitive communication, intake and record preparation, so dispatchers and engineers can spend their time on judgment and field work. Decisions about crews, shutdowns, safety and asset changes stay with qualified people who approve the agent's drafts.

What systems does an agent need access to? Usually a read view of the outage status record, the ability to create draft requests in the work order system, and read access to the asset register with a proposal path for updates. Start with the smallest set that supports the first role. Access should be reviewed regularly and removed when it is no longer needed.

How do we know the agent is working well? Define the measure before launch and check it against real cases. Useful checks include message accuracy against the status record, correct routing of escalations, and whether engineers need to correct the agent's drafts. Keep logs of what the agent read, said and routed, so problems can be traced and fixed.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.