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.
Telemetry, outage schedules and procedure text, pulled from supported EMS, historian, OMS and document sources.
02
Field names, units and timestamps normalised, with each value carried forward under the source it came from.
Reason
03
A situational picture assembled — what changed, what is out, and how old the newest input actually is.
04
Operating procedures and study cases matched to the condition on the board, quoted rather than paraphrased.
05
Options and alternatives set out side by side, each with the elements it would touch and the limits it bears on.
Decide
06
Evidence that would falsify an option, named alongside it, so the desk knows what to look at first.
07
A validated-range check ahead of the option set, and a stop when inputs fall outside what the model was tested on.
Out
08
The option set, the assessment behind it and the operator's action retained against the shift log.
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
AgentHuman
1Condition detectedEMS alarm, SCADA point, historian trend or an operator's question
2Picture assembledTelemetry, outage status, ratings, limits and the procedures that apply, each with its source
3Options presentedAlternatives, what each touches, confidence
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▼
6Decision record updatedOnly where write access and approval policy allow it
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 required8 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 boundaryAgent 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 conditionIllustrative example
Condition
Option presented
Input age
Study basis
Confidence
Validated range
Post-contingency loading
Redispatch the western path, or reduce scheduled interchange
8 min
Study case on file
88%
Inside the tested range
As receivedTaken from the EMS, the historian and the procedure on file — nothing here is written by the agent.
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 aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Degraded or stale telemetry
9.6%
3.5×
Review
Storm and multiple outages
6.9%
2.5×
Review
Cold-start after a restoration
5.2%
1.9×
Watch
Steady-state operation
1.6%
0.6×
Normal
Bar: set-aside-rate lift vs. steady-state baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 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 stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Set-aside rate rises in one event class.
02Diagnose
The option set is the unit — each is read back against the inputs behind it until one cause holds.
03Improve
Every change is versioned against the events that exposed it.
04Verify
A failing case holds the release back.
05Learn
The case joins the suite for good, and the option rules are revisited.
Learn → DetectThe 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.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Control-room workflow discovery and boundary definition.
02EMS, historian and OMS source assessment.
03Operating-procedure, limit and study-case source mapping.
04Telemetry ingestion and normalisation.
05Picture assembly and option logic.
06Confidence scoring and deference routing.
07Operator decision workflow.
08EMS, historian and log-system integration.
09Boundary and deference cases.
10Guardrails and change controls.
11Decision-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 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 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 control-room workflow and shift structure→Telemetry ingestion and picture assemblyWeek 1
02Representative logged events→Option baseline, procedure retrieval and source bindingWeek 2
03Your operating procedures and limit sets→Operating-procedure, limit and study-case source mappingWeek 1
04Access to relevant interfaces, feeds or exports→EMS, historian and OMS assessment, then integration setupWeek 2
05Options you would not want followed→Boundary cases and the evaluation suiteWeek 4
06What only a certified operator may do→Confidence scoring, deference routing, guardrails and change controlsWeek 3
07Named certified operators to work the pilot→Operator decision 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
The bands follow the real work, which is why evaluation and pilot share the fifth week.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Control-room workflow discovery and the automation boundaryW2Source integration and the picture baselineW3Option workflow, confidence logic and deference controlsW4Evaluation suite, guardrails and failure-mode testingW5EMS and log integration, pilot shifts and targeted correctionsW6One operating period supported under the shift supervisor, then 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 W6The period closes validation and Agent Care assumes monitoring.
DurationSix-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.
