Main site

Energy AI agent · Wildfire & water

Wildfire, Storm & Water Analytics AI Agent

Assemble the inputs behind an ignition, spread, storm or water-system score, return the score with its confidence and the direction of its error, and hold the decision for a named incident commander.

Typical delivery
4–6 weeks
Deployment
Your stack
Commander signs
Score only
After launch
Agent Care

What this agent does

Builds the score, never the decision to cut power

In

  1. 01

    Weather feeds, fuel-moisture readings, telemetry and circuit records, from supported sensor, GIS and outage sources.

  2. 02

    Field names, units and timestamps, normalised, with each value carried forward under the source it was read from.

Reason

  1. 03

    An ignition, spread, storm-impact or water-system score, produced with its confidence and the direction of its error.

  2. 04

    Your own thresholds, circuit segments and basin definitions, applied as configured and versioned when they change.

  3. 05

    Every input behind a score — the reading, the record and its age — bound to it, so a reviewer can take it apart.

Decide

  1. 06

    Measured results and actual events, marked apart from anything modelled, because duties run on facts, not on scores.

  2. 07

    Scores, routed to the named incident commander who decides, with nothing acted on ahead of that decision.

Out

  1. 08

    The score, the inputs, the decision and the reason, retained under the retention rules your owner approved.

  2. 09

    Write actions only inside the boundaries agreed at implementation — never to a switch, a valve or a notification.

Product statement

The agent produces a score; a commander decides. A score does not shrink the utility's liability, and once it exists it is discoverable.

Example workflow

One score, input to decision

  1. 1Inputs receivedWeather feed, fuel-moisture reading, sensor telemetry or a laboratory result
  2. 2Inputs assembledCircuit and basin records, asset history, terrain and field observations, each with its source
  3. 3Score producedScore, confidence and direction of error
  4. 4Controls appliedInput-freshness checks, validated-range checks, measured-fact separation and confidence threshold

No human action required

Stages 1 to 4 run unaided, and nothing is switched, notified or declared at any of them — the agent is scoring, and the commander's lane opens at the confidence gate.

5DecisionSplits at the confidence threshold
High confidence

Goes to the incident commander.

Low confidence

Adds a risk-engineering read first.

Commander decision

The score is held with its inputs, its error direction and the confidence.

Accept · Set aside · Send to risk engineering

Accepted — the commander acts

  1. 6Decision record updatedOnly where write access and approval policy allow it
  2. 7Outcome evaluatedScore calibration, set-aside rate, what the commander did instead and what actually happened

Set aside

Every score the commander set aside is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • De-energising any circuit, or restoring one to service.
    • Issuing a public notification to customers or an agency.
    • Declaring a system, a circuit or a basin safe.
    • Deciding that a notification duty is not triggered.

  • Automation boundary

    Agent acts unaided

    • ✓Assemble the inputs behind a score from the sources on file.
    • ✓Produce the score with its confidence and the direction.
    • ✓Surface the measured results and events that duties actually run on.
    • ✓Flag when inputs fall outside the tested range, and hold the score.

    Any write happens inside the boundaries agreed at implementation, and never to a switch or a valve.

    • Changing a risk threshold or a retention rule.
    • Categorising a service line for the inventory.
    • Running on when it is outside its validated range.
  • Changes to the model, the prompt or its configuration.

Example output

One score, annotated

Everything the agent scores is attached to the inputs it was drawn from.

Risk-score output · single circuit segment

Illustrative example
Segment
Wind-exposed feeder
Score produced
Ignition risk elevated on the upper span, spread footprint wide
Input age
22 min
Error direction
Runs small and slow
Confidence
71%
Validated range
Inside the tested range

As received

Taken from the weather feed, the sensors and the circuit record — nothing here is written by the agent.

Inputs used

  • Fuel-moisture reading
  • Wind forecast
  • Circuit inspection record

Why this score

Spread error is not symmetric — when the model is wrong, it runs small and slow.

What the score decides

Below the configured threshold the score picks up a risk-engineering read first.

Action

AcceptSet asideSend to risk engineering

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every score

From the feeds and sensors

03Scoring

Build the score

Draw on weather feeds, sensor telemetry, circuit and basin records and the thresholds on file.

01Approved path

A score is not a decision

Routine scores and the inputs behind them arrive already assembled.

02Human review

Send the read where the model is

Out-of-range and low-confidence scores are marked, so the commander's read starts where the model is least tested.

04

Build an evidence trail

The score, the inputs behind it and the incident commander who acted on it stay on the record.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Weather and fire risk

    • NWS
    • NOAA HRRR
    • RAWS
    • Synoptic Data

  • GIS and asset data

    • Esri ArcGIS
    • Smallworld
    • Maximo
    • Copperleaf

  • Grid sensing

    • SCADA
    • ADMS
    • Line sensors
    • weather stations

Agent

Wildfire, storm and water analytics

  • Reads the inputs
  • Produces the score
  • Holds for the commander

  • Water systems

    • SCADA historian
    • LIMS
    • Service-line inventory
    • CMMS

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the model and the switch

The controls sit inside one another. What none of them catches is set out below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modePull the agent back to observation-only when evaluation or production signals degrade.Roll back
L5Version monitoringModel, prompt, thresholds and retention rules are pinned; changes are authorised and tested first.Track
L4TraceabilityRecord the inputs, the score, the error direction, who decided and when.Record
L3Commander decisionHold scores for the named commander; it governs what is put up, not whether a score is sound.Gate
L2Range and duty rulesTest scores against the validated range and the measured facts on file; a failure returns the score.Restrict
L1Confidence thresholdsRoute low-confidence scores to a risk-engineering read before the commander sees them.Require review
Model coreScore produced — value, confidence, direction of error and validated range
L1 – L2
Test whether a score may stand
L3
Puts the decision in a commander's hands
L4 – L5
Keep the score and the inputs behind it
L6
Narrows to observation reporting when signals degrade

How Nestack evaluates it

Evaluate the whole scoring path — not only the number at the end.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the score the commander sees

  1. E1Final-output evaluationDid the score carry its confidence and the direction of its error?
  2. E2Step-level evaluationDid the agent use current readings, the right segment and the thresholds on file?
  3. E3Tool evaluationDid it read the correct circuit, basin and sensor?
  4. E4Confidence calibrationDo low-confidence scores actually get set aside more often?
  5. E5Slice evaluationHow does performance change across specific segment and basin classes?
  6. E6Business outcomeHow often did the score run under what happened, and by how far?

Floor — the outcome the utility answers for

Failure modes

Where each failure originates in the agent

Seven ways a score goes wrong, placed at the stage it starts.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • JX-03

      Stale reading taken as current

      A sensor stops updating and the score keeps its last value.

    Stage gathers

    Weather, fuel moisture, telemetry and circuit records

  2. 02 · Reasoning

    2 modes

    • JX-04

      Spread footprint under-called

      The score says smaller and slower than the fire runs.

    • JX-06

      Score read as a duty check

      A score is taken as evidence that no duty is running.

    Stage proposes

    Score, confidence and direction of error

  3. 03 · Tool / write

    2 modes

    • JX-02

      Unreviewed de-energisation

      A score drives a switching action with no commander.

    • JX-05

      Score kept outside the rule

      A score is retained or shared against the approved rule.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • JX-01

      Error direction dropped

      A score is returned without which way it is likely wrong.

    Stage returns

    The score the commander weighs

  5. 05 · Change / Version

    1 mode

    • JX-07

      Silent threshold drift

      A threshold or model change moves what a score means.

    Stage tracks

    Model, prompt, thresholds and retention rules

  • Sev-1 · power cut without a commander
  • Sev-2 · a wrong score reaches a decision
  • Sev-3 · input degrades, the score is held
See the complete Energy & Utilities failure-mode catalogue

Affected slices

Overall calibration can hide one segment

Customers on ventilators and oxygen concentrators sit on few segments, and the aggregate never counts them. Nestack reports the set-aside rate by segment and basin, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Segments with medical-baseline load9.0%3.2×Review
Extreme wind and low fuel moisture5.9%2.1×Review
Storm damage estimation4.5%1.6×Watch
Routine seasonal scoring2.2%0.8×Normal

Bar: set-aside-rate lift vs. routine-scoring baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

A cycle ends in the suite, not the review

The cycle ends when a case exists in the suite, not when the miss was discussed. That suite is what the next score put to a commander is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Set-aside rate rises on one segment.

  2. 02

    Diagnose

    Read the score back against the inputs behind it, segment by segment, until one cause holds.

  3. 03

    Improve

    Changes carry a version and the events that prompted them.

  4. 04

    Verify

    Release is held until the affected cases pass.

  5. 05

    Learn

    The case is kept permanently, and the threshold notes move with it.

  6. Learn → Detect

    The return edge. Next season's detection is measured against a longer suite.

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, scoring workflow, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Risk-workflow discovery and automation-boundary definition.Week 1
  2. 02Weather, sensor and GIS source assessment.Week 1, Week 2
  3. 03Threshold, circuit-segment and basin definition mapping.Week 1, Week 2
  4. 04Input ingestion and normalisation.Week 2
  5. 05Scoring logic and input binding.Week 2, Week 3
  6. 06Confidence scoring and escalation routing.Week 3
  7. 07Commander decision workflow.Week 3, Week 4
  8. 08GIS, sensor and outage-system integration.Week 5
  9. 09Calibration and notice cases.Week 4, Week 5
  10. 10Guardrails and escalation controls.Week 4
  11. 11Score-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final 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 seasonProductionProduction risk systemsAdvancedMultiple territories / basins
Introduced at Pilot
Scoring from your data and thresholds✓✓✓
Commander decision✓✓✓
Calibration baseline✓✓✓
Introduced at Production
Reporting by circuit and basin—✓✓
Decision workflow in your systems—✓✓
Approved record write-back—✓✓
GIS and sensor integration—✓✓
Introduced at Advanced
Multi-state and multi-agency rules——✓
Approval chains across teams——✓
High sensor and event volume——✓
Multi-territory risk controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from build
Build 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.

  1. 01Your risk workflow and incident structure

    Input ingestion and score assembly

    Week 1

  2. 02Representative scored events

    Scoring baseline, calibration and input binding

    Week 2

  3. 03Your thresholds, segments and basin definitions

    Threshold, circuit-segment and basin definition mapping

    Week 1

  4. 04Access to relevant feeds, sensors or exports

    Weather, sensor and GIS assessment, then integration setup

    Week 2

  5. 05Scores you would not want acted on

    Calibration cases and failure-mode testing

    Week 4

  6. 06What must reach a commander before power is cut

    Confidence scoring, escalation routing, guardrails and approval controls

    Week 3

  7. 07Named incident commanders to work the pilot

    Commander decision workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

The bands follow the actual work, which is why the fifth week doubles rather than pads.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Risk-workflow discovery and the automation boundary

W2Source integration and the scoring baseline

W3Scoring workflow, confidence logic and escalation controls

W4Evaluation suite, calibration cases and failure-mode testing

W5GIS and sensor integration, pilot scoring and targeted corrections

W6One season scored under the incident team, then handover

Reading the band
A bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
At the end of W6
The season closes validation and Agent Care owns the running agent.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Energy AI agent

Build a risk-analytics agent around your incident process.

Show us your feeds, your thresholds and who commands an incident. Who signs the order to cut power, and what has to reach them first? We draw the boundary around that answer.

Typical delivery
4–6 weeks
Deployment
Your feeds and sensors
Commander signs
Score only
After launch
Agent Care available

Nestack Agents · Wildfire, storm and water analytics

AGT-EN-09 · Agent Care available after launch

Build a risk-analytics agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your risk work

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.