Main site

Energy AI agent · Control room

Control-Room Decision-Support AI Agent

Assemble the situational picture from your EMS and historian, put options and what each one would touch in front of the desk, and leave the command itself to a certified system operator.

Typical delivery
4–6 weeks
Deployment
Your stack
Operator signs
Options only
After launch
Agent Care

What this agent does

Assembles the picture, never the command

In

  1. 01

    Telemetry, outage schedules and procedure text, pulled from supported EMS, historian, OMS and document sources.

  2. 02

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

Reason

  1. 03

    A situational picture assembled — what changed, what is out, and how old the newest input actually is.

  2. 04

    Operating procedures and study cases matched to the condition on the board, quoted rather than paraphrased.

  3. 05

    Options and alternatives set out side by side, each with the elements it would touch and the limits it bears on.

Decide

  1. 06

    Evidence that would falsify an option, named alongside it, so the desk knows what to look at first.

  2. 07

    A validated-range check ahead of the option set, and a stop when inputs fall outside what the model was tested on.

Out

  1. 08

    The option set, the assessment behind it and the operator's action retained against the shift log.

  2. 09

    Write actions only inside the boundaries agreed at implementation — shift logs and notes, never a control system.

Product statement

The agent presents options; a certified system operator decides and issues any operating instruction, and the entity stays responsible.

Example workflow

One condition, board to log

  1. 1Condition detectedEMS alarm, SCADA point, historian trend or an operator's question
  2. 2Picture assembledTelemetry, outage status, ratings, limits and the procedures that apply, each with its source
  3. 3Options presentedAlternatives, what each touches, confidence
  4. 4Controls appliedInput-freshness checks, limit and rating checks, validated-range check and confidence threshold

No human action required

Stages 1 to 4 run unaided, and nothing is commanded at any of them — the agent is assembling options, and the operator's lane opens at the confidence gate.

5DecisionSplits at the confidence threshold
High confidence

Goes to the operator on shift.

Low confidence

Adds a shift-supervisor read first.

Operator decision

The option set is held with its inputs, its limits and the confidence.

Accept · Set aside · Send to supervisor

Accepted — the operator acts

  1. 6Decision record updatedOnly where write access and approval policy allow it
  2. 7Outcome evaluatedOption quality, deference rate, what the operator did instead and the system outcome

Set aside

Every option set the operator 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

  • Issuing an operating instruction to any party.
    • Changing the state, status or output of an element.
    • Discharging the real-time assessment obligation.
    • Determining a limit exceedance under your methodology.

  • Automation boundary

    Agent acts unaided

    • ✓Assemble the situational picture from the sources on file.
    • ✓Retrieve the procedure text that applies, quoted, with its source.
    • ✓Set out options, what each touches and what would falsify it.
    • ✓Flag when it is outside its validated range, and hold for the desk.

    Any write happens inside the boundaries agreed at implementation, and never to a control system.

    • Declaring an emergency or calling for load shed.
    • Taking part in the three-part communication loop.
    • Running on when it is outside its validated range.
  • Changes to the model, prompt or its configuration.

Example output

One option set, annotated

Everything the agent puts up is attached to the data it was drawn from.

Option output · single condition

Illustrative example
Condition
Post-contingency loading
Option presented
Redispatch the western path, or reduce scheduled interchange
Input age
8 min
Study basis
Study case on file
Confidence
88%
Validated range
Inside the tested range

As received

Taken from the EMS, the historian and the procedure on file — nothing here is written by the agent.

Inputs used

  • Telemetry snapshot
  • Outage schedule
  • Procedure step

Why these options

Alternatives to weigh, not a command — the assessment stays the operator's.

What the score decides

Below the configured threshold the option set picks up a shift-supervisor read first.

Action

AcceptSet asideSend to supervisor

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 condition

From the EMS and historian

03Assembly

Build the picture

Draw on telemetry, outage status, ratings and the operating procedures on file.

01Approved path

Options, never a command

Routine option sets and the procedure text behind them arrive already assembled.

02Human review

Send attention to the hard cases

Out-of-range and low-confidence option sets are marked, so the desk's attention starts where risk concentrates.

04

Build an evidence trail

The option set, the assessment behind it and the certified operator who acted stay on the log.

Integrations

Typical integrations

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

  • EMS and SCADA

    • OSI monarch
    • GE e-terra
    • Siemens Spectrum Power
    • Hitachi

  • Historian and time series

    • AVEVA PI
    • Canary
    • eDNA
    • InfluxDB

  • Distribution and outage

    • Schneider ADMS
    • Oracle NMS
    • Survalent
    • Milsoft

Agent

Control-room decision support

  • Reads the picture
  • Sets out options
  • Holds for the operator

  • Studies and logs

    • PSS/E
    • PowerWorld
    • CAPE
    • eLogger
    • shift-log systems

  • 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 desk

The layers sit one inside the next. What none of them catches is in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modePull the agent back to picture-only when evaluation or production signals degrade.Roll back
L5Version monitoringModel, prompt and configuration are pinned; changes are authorised and tested first.Track
L4TraceabilityRecord the inputs, the options, the deference flag, who acted and when.Record
L3Certified operatorHold options for the operator on shift; it governs what is put up, not whether an option is sound.Gate
L2Range and limit rulesTest options against the validated range and the limits on file; a failure returns the set.Restrict
L1Confidence thresholdsRoute low-confidence option sets to a shift-supervisor read before the desk sees them.Require review
Model coreOptions produced — alternatives, what each touches, limits and confidence
L1 – L2
Test whether an option may stand
L3
Puts the decision in an operator's hands
L4 – L5
Hold the assessment the options rested on
L6
Falls back to displaying raw telemetry when signals degrade

How Nestack evaluates it

Evaluate the whole decision path — not only the option that was taken.

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

Surface — what the desk is shown

  1. E1Final-output evaluationDid each option name what it would touch and what would falsify it?
  2. E2Step-level evaluationDid the agent use current telemetry, the right ratings and the procedure that applies?
  3. E3Tool evaluationDid it read the correct system, area and point?
  4. E4Confidence calibrationDo low-confidence option sets actually get set aside more often?
  5. E5Slice evaluationHow does performance change across specific event classes?
  6. E6Business outcomeHow often did the agent hold and defer when it should have, and how often did it not?

Floor — the outcome the entity answers for

Failure modes

Where each failure originates in the agent

Seven ways an option set goes wrong, placed at the stage it starts.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • QM-03

      Stale input taken as live

      A point stops updating and the picture keeps its last value.

    Stage gathers

    Telemetry, outage status, ratings and procedure text

  2. 02 · Reasoning

    2 modes

    • QM-04

      Option outside the range

      An option is offered for a state the model was never tested on.

    • QM-06

      Procedure text paraphrased

      A step is summarised instead of quoted, and the sense shifts.

    Stage proposes

    Alternatives, what each touches and confidence

  3. 03 · Tool / write

    2 modes

    • QM-02

      Reads as an instruction

      Wording is taken as a command rather than an option.

    • QM-05

      Deference not raised

      The agent runs on where it should have stopped and deferred.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • QM-01

      Falsifier omitted

      An option is put up without what would show it wrong.

    Stage returns

    The options the operator weighs on shift

  5. 05 · Change / Version

    1 mode

    • QM-07

      Silent version regression

      A model or configuration change widens what the agent will assert.

    Stage tracks

    Model, prompt, procedure sources and configuration

  • Sev-1 · acts outside the boundary
  • Sev-2 · a wrong option reaches the desk
  • Sev-3 · input degrades, the set is held
See the complete Energy & Utilities failure-mode catalogue

Affected slices

Overall quality can hide one event class

Degraded-telemetry hours are the slice the aggregate buries — few of them, and most of the set-asides. Nestack reports the operator set-aside rate by event class, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Degraded or stale telemetry9.6%3.5×Review
Storm and multiple outages6.9%2.5×Review
Cold-start after a restoration5.2%1.9×Watch
Steady-state operation1.6%0.6×Normal

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

2 of 4 slices over threshold

Evidence-linked improvement

Nothing closes until a test exists

The cycle ends in a regression case, not in a meeting about what happened. That suite is what the next option set put to an operator is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Set-aside rate rises in one event class.

  2. 02

    Diagnose

    The option set is the unit — each is read back against the inputs behind it until one cause holds.

  3. 03

    Improve

    Every change is versioned against the events that exposed it.

  4. 04

    Verify

    A failing case holds the release back.

  5. 05

    Learn

    The case joins the suite for good, and the option rules are revisited.

  6. Learn → Detect

    The return edge. The next detection is measured against a longer suite than this one.

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

Workstream

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

  1. 01Control-room workflow discovery and boundary definition.Week 1
  2. 02EMS, historian and OMS source assessment.Week 1, Week 2
  3. 03Operating-procedure, limit and study-case source mapping.Week 1, Week 2
  4. 04Telemetry ingestion and normalisation.Week 2
  5. 05Picture assembly and option logic.Week 2, Week 3
  6. 06Confidence scoring and deference routing.Week 3
  7. 07Operator decision workflow.Week 3, Week 4
  8. 08EMS, historian and log-system integration.Week 5
  9. 09Boundary and deference cases.Week 4, Week 5
  10. 10Guardrails and change controls.Week 4
  11. 11Decision-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 desk, one areaProductionProduction control-room systemsAdvancedMultiple areas / control centres
Introduced at Pilot
Options from your data and procedures✓✓✓
Certified-operator decision✓✓✓
Option-quality baseline✓✓✓
Introduced at Production
Reporting by event class—✓✓
Decision workflow in your systems—✓✓
Approved log write-back—✓✓
EMS and historian integration—✓✓
Introduced at Advanced
Multi-area and multi-entity rules——✓
Approval chains across desks——✓
High event volume——✓
Multi-area control 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 control-room workflow and shift structure

    Telemetry ingestion and picture assembly

    Week 1

  2. 02Representative logged events

    Option baseline, procedure retrieval and source binding

    Week 2

  3. 03Your operating procedures and limit sets

    Operating-procedure, limit and study-case source mapping

    Week 1

  4. 04Access to relevant interfaces, feeds or exports

    EMS, historian and OMS assessment, then integration setup

    Week 2

  5. 05Options you would not want followed

    Boundary cases and the evaluation suite

    Week 4

  6. 06What only a certified operator may do

    Confidence scoring, deference routing, guardrails and change controls

    Week 3

  7. 07Named certified operators to work the pilot

    Operator 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 real work, which is why evaluation and pilot share the fifth week.

Phase

W1

W2

W3

W4

W5

W6

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

Week focus

W1Control-room workflow discovery and the automation boundary

W2Source integration and the picture baseline

W3Option workflow, confidence logic and deference controls

W4Evaluation suite, guardrails and failure-mode testing

W5EMS and log integration, pilot shifts and targeted corrections

W6One operating period supported under the shift supervisor, 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 period closes validation and Agent Care assumes monitoring.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Energy AI agent

Build a control-room copilot around your operating procedures.

Show us your EMS, your procedures and how a shift runs. The certified operator on the desk signs, never the agent, and we draw the boundary around that.

Typical delivery
4–6 weeks
Deployment
Your EMS and historian
Operator signs
Options only
After launch
Agent Care available

Nestack Agents · Control-room decision support

AGT-EN-08 · Agent Care available after launch

Build a control-room copilot

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

About you
Your control room

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