Take the outage report, match it to a known event, and tell the customer what the restoration organisation has confirmed — with its source, its time and the person who released it.
Stages 1 to 4 run unaided, and no estimate is stated at any of them — the agent is matching and drafting, and the duty officer's lane opens at the confidence gate.
5DecisionBranches at the confidence threshold
High confidence
Goes to the duty officer to release.
Low confidence
Adds an incident-command read first.
Duty-officer release
The message is held with its source record, its timestamp and the confidence.
Release · Correct · Send to incident command
Released — sent to the customer▼
6Outage systems updatedOnly where write access and release policy allow it
7Outcome evaluatedMessage accuracy, register contact outcomes, corrections and complaints
Corrections
Corrections sent after a message went out are counted too.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Issuing or changing an estimated restoration time.
Declaring an event, a circuit or an address restored.
Contacting a life-support or critical-care customer.
Closing any report that carries a downed-line hazard.
Automation boundaryAgent acts unaided
✓Take the outage report and match it to a known event on the system.
✓State the confirmed status, with its source and its time.
✓Serve the approved safety text without paraphrasing it.
✓Route a registered critical-care account to the personal-contact team.
Any write happens inside the boundaries agreed at implementation, never ahead of release.
Setting the crew fix rate an estimate is built on.
Notifying critical facilities and safety partners.
Telling a customer what compensation they are owed.
Changes to safety text, register or release rules.
Example output
One event message, annotated
Everything the agent drafts is attached to the record it was drawn from.
Outage-support output · single reportIllustrative example
Report
Line drafted
Event status
Source of record
Confidence
Release path
No power, whole street
Your street is on a known outage and a crew has been assigned to it
Confirmed outage
Outage management record
93%
Held for the duty officer
As receivedTaken from the outage record and the event log — nothing on this side is written by the agent.
Sources usedOutage management recordEvent log entryPremise and circuit data
Why this wordingIt states what the record confirms and stops — no estimate is released yet.
ActionReleaseCorrectSend to incident command
What the score decidesBelow the configured threshold the message picks up an incident-command read.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every reportFrom the outage record
03Answering
Answer from the event record
Draw on the outage management record, the event log and the approved text for hazards and advisories.
01Approved path
Tell them what is known
Confirmed status and approved safety text come back without waiting in the storm queue.
02Human review
Send people where being wrong hurts
Register accounts, hazard reports and low-confidence drafts are marked, so the duty team reaches the customers where an error causes harm.
04Build an evidence trail
The message, the record it was drawn from and the person who released it stay on the event.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
A season's correction rate reads as one settled number; inside it, a major storm's early hours behave nothing like a single-premise fault. Nestack reports by slice, not in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Major storm, early hours
4.2%
3.5×
Review
Critical-care and life-support accounts
3.2%
2.7×
Review
Nested and partial restorations
2.3%
1.9×
Watch
Single-premise outages
1.0%
0.8×
Normal
Bar: message-correction-rate lift vs. single-premise baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
A cycle ends in a test, not a debrief
A cycle closes when the failure is a regression case the next release has to pass. That suite is what the next event through restoration is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Correction rate rises in one event class.
02Diagnose
The duty officer who picked the message up walks back through the event record with it until the cause narrows to one.
03Improve
The change ships against a version, with the events that exposed it attached.
04Verify
Release is blocked until the affected regression cases pass again.
05Learn
The case joins the permanent suite and the storm playbook.
Learn → DetectThe return edge. Detection next time runs against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, message workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Outage workflow discovery and boundary definition.
02OMS, CIS and channel source assessment.
03Register, safety-text and estimate-authority mapping.
04Report ingestion and event matching.
05Message drafting and source binding.
06Confidence scoring and hazard routing.
07Duty-officer release workflow.
08Outage and customer-system integration.
09Estimate and register cases.
10Guardrails and release controls.
11Message-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne territory, one channelProductionProduction outage systemsAdvancedMultiple utilities / regions
Introduced at Pilot
Answering from your event record✓✓✓
Duty-officer release✓✓✓
Message-accuracy baseline✓✓✓
Introduced at Production
Reporting by event class—✓✓
Release workflow in your systems—✓✓
Approved write-back—✓✓
Outage-system integration—✓✓
Introduced at Advanced
Multi-state notification rules——✓
Multi-stage storm approvals——✓
High event volume——✓
Multi-jurisdiction event controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your outage channels and event record structure→Report ingestion and event matchingWeek 1
02Representative event communications→Message baseline, source binding and approved-text extractionWeek 2
03Your approved safety and advisory text→Register, safety-text and estimate-authority mappingWeek 1
04Access to relevant APIs, feeds or exports→OMS, CIS and channel assessment, then integration setupWeek 2
05Messages you would not want sent→Estimate cases and failure-mode testingWeek 4
06What must reach a person before an estimate goes out→Confidence scoring, hazard routing, guardrails and release controlsWeek 3
07Named duty officers to release messages→Duty-officer release workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Each phase sits on the weeks it actually occupies, and week 5 carries both evaluation and launch work.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Outage-communication discovery, register mapping and the automation boundaryW2Source integration and the message baselineW3Message workflow, confidence logic and release controlsW4Evaluation suite, estimate cases and failure-mode testingW5Channel integration, pilot events and targeted correctionsW6One storm season answered under the duty team, then Agent Care handover
Reading the bandA bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
At the end of W6Validation closes on live events, and Agent Care picks up monitoring.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Energy & Utilities AI agent
Build an outage agent that carries the estimate instead of inventing one.
Show us your outage systems, your registers and who releases messages. Estimates that were early, confident and wrong have drawn fines and investigations, so the boundary gets set before a storm sets it.
