Energy AI agent · VPP fleet control
Demand-Response & VPP Fleet-Control AI Agent
Build each dispatch from the resources you have evidenced authority over, follow the market instruction and the customer's configured limits, and hold the offer for the operator who is accountable for it.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Operator sign-off
- Authority first
- After launch
- Agent Care
What this agent does
Executes the dispatch, not the decision to offer
In
- 01
Where a device is enrolled, ingest its terms, limits and telemetry from supported platforms.
- 02
Where identifiers differ across systems, normalise them and carry each resource forward with the enrolment behind it.
Reason
- 03
When the market issues an instruction, build the dispatch from the resources whose authority is evidenced and current.
- 04
Where a market and its regulator permit participation, apply the eligibility, tariff and programme rules configured for it.
- 05
Bind each offered megawatt to an enrolment record, and mark the capability the evidence does not support.
Decide
- 06
When a customer limit, an opt-out or a lost connection reduces a resource, hold that capability out of the offer.
- 07
Where an offer changes the registered capability, route it to the named operations lead for approval.
Out
- 08
Retain the enrolment evidence, the instruction, the telemetry and the approval against the fleet record.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
The agent proposes the dispatch; the named operations lead decides what is offered, and the officer who attests to the registration stays accountable for it.
Example workflow
One dispatch, instruction to delivery
- 1Market instruction receivedRTO dispatch signal, programme event or utility call
- 2Fleet assembledEnrolment records, device limits, telemetry and connectivity, each with its source
- 3Dispatch proposedResources, offered reduction and confidence
- 4Controls appliedAuthority checks, device-limit checks, per-market and state eligibility, and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is offered or dispatched at any of them — the operator's lane opens at the confidence gate.
Goes to the operations lead to approve.
Adds a market-compliance read first.
Operator approval
The dispatch is held with its enrolment evidence, its limits and the confidence.
Approve · Adjust · Send to compliance review
Approved — released to dispatch
- 6Fleet systems updatedOnly where write access and approval policy allow it
- 7Outcome evaluatedDelivered against instruction, override rates, telemetry gaps and settlement corrections after the event
Adjustments
Operator adjustments and post-settlement corrections are counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Offering capacity without evidenced authority over it.
- Dispatching anything outside the market instruction.
- Overriding a customer's opt-out or configured limit.
- Stating a verified saving for an individual site.
Automation boundary
Agent acts unaided
- ✓Build the dispatch from resources with evidenced authority.
- ✓Respect the comfort bands, floors and opt-outs configured per device.
- ✓Record telemetry, delivery evidence and customer overrides.
- ✓Hold the proposed offer for the operations lead,.
Any write happens inside the boundaries agreed at implementation, never ahead of approval.
- Changing a baseline, enrolment or registration rule.
- Raising consumption ahead of a measurement window.
- Declaring a resource unavailable or out of service.
- Enrolling a customer or opening a new programme.
Example output
One dispatch, annotated
Everything the agent proposes is attached to the enrolment it was drawn from.
Fleet-control output · single event
Illustrative example- Resource
- Residential battery
- Proposed action
- Discharge to the programme set point for the instructed window
- Offered reduction
- 4.2 kW
- Authority on file
- Signed enrolment
- Confidence
- 91%
- Instruction
- RTO dispatch instruction
As received
Taken from the enrolment record and the device telemetry — nothing on this side is written by the agent.
Evidence used
- Signed enrolment terms
- Device limit configuration
- Interval telemetry
Why this dispatch
The market instructed it and the enrolment conveys the right.
What the score decides
Below the configured threshold the dispatch picks up a compliance read before it.
Action
ApproveAdjustSend to compliance reviewValue
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 resource
From the enrolment record
Build from the enrolment
Follow the market instruction and the enrolment on file — the agent does not choose when the fleet dispatches.
Dispatch what you can prove
Routine events are assembled, checked and proposed without a person building them by hand.
Send review to the weak evidence
Thin authority, missing telemetry and barred markets are marked, so the operator's read starts where risk concentrates.
Build an evidence trail
The dispatch, the enrolment behind it and the operator who released it stay on the fleet record.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Market and programme
- RTO dispatch APIs
- OpenADR
- Utility programme portals
DER control
- DERMS
- aggregation platforms
- Inverter
- thermostat
- EV clouds
Metering
- AMI head-end
- MDMS
- Interval and telemetry feeds
Agent
Demand response & VPP fleet control
- Reads the enrolment
- Builds the dispatch
- Holds for approval
Enrolment and settlement
- CRM
- consent records
- Settlement 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 fleet
Each layer contains the next. What gets past the set is listed in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a dispatch may stand
- L3
- Puts the release in an operator's hands
- L4 – L5
- Keep the dispatch and the enrolment behind it
- L6
- Reduces to telemetry reporting when signals degrade
How Nestack evaluates it
Evaluate the whole dispatch workflow — not only the settled event.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the delivery the market sees
- E1Final-output evaluationDid the delivered load change match the instruction at portfolio level?
- E2Step-level evaluationDid the agent use the right enrolment, device limits and eligibility rules?
- E3Tool evaluationDid it read and write the correct resource and the correct set point?
- E4Confidence calibrationDo low-confidence dispatches actually under-deliver more often?
- E5Slice evaluationHow does performance change across specific resource classes?
- E6Business outcomeHow many events needed an operator adjustment or a settlement correction after the fact?
Floor — the outcome the aggregator answers for
Failure modes
Where each failure originates in the agent
Seven ways a dispatch goes wrong, by stage.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- NQ-03
Stale enrolment record
Authority read from a lapsed or superseded enrolment.
Stage gathers
Enrolment records, device limits, telemetry and market rules
02 · Reasoning
2 modes
- NQ-04
Overstated capability
Registered capability exceeds what the device limits permit.
- NQ-06
Baseline-affecting action
A proposal would raise load ahead of a measurement window.
Stage proposes
Resources, offered reduction and confidence
03 · Tool / write
2 modes
- NQ-02
Dispatch outside the instruction
A set point is sent that the market did not instruct.
- NQ-05
Double-counted resource
One device is offered into two programmes at once.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- NQ-01
Authority not evidenced
Capacity offered without a current right to control the load.
Stage returns
The dispatch the operator releases and
05 · Change / Version
1 mode
- NQ-07
Silent rule regression
A model or rule change widens what the agent will offer.
Stage tracks
Model, prompt, programme rules and market config
- Sev-1 · capacity offered without authority
- Sev-2 · a dispatch misses the instruction
- Sev-3 · telemetry degrades, dispatch routes to review
Affected slices
Overall delivery can hide one bad cohort
Under-delivery is uncommon fleet-wide, and that base rate is what hides it: a few resource classes carry most of it. A per-site saving is an estimate against a counterfactual, not evidence, so Nestack reports by slice at portfolio level.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Newly enrolled residential | 9.8% | 3.9× | Review | |
| Devices on consumer broadband | 5.8% | 2.3× | Review | |
| Behind-the-meter batteries | 3.5% | 1.4× | Watch | |
| Established industrial load | 1.8% | 0.7× | Normal |
Bar: under-delivery-rate lift vs. established-industrial baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
The loop closes on a case, not a cause
Nothing closes because it was understood. It closes when the next release has to pass a case, and that suite is what the next dispatch is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Under-delivery rises in a resource slice.
- 02
Diagnose
If the enrolment holds, the operator reads the telemetry, then the instruction, until one of them explains it.
- 03
Improve
Changes ship against a version with the dispatches that caused them.
- 04
Verify
A failing case blocks release until it clears.
- 05
Learn
The case is permanent, and the enrolment rules move with it.
Learn → Detect
The return edge. The next cycle starts against a suite that is 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, dispatch workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Dispatch workflow discovery and automation-boundary definition.Week 1
- 02DERMS, metering and market assessment.Week 1, Week 2
- 03Enrolment, authority and programme-rule mapping per market.Week 1, Week 2
- 04Telemetry ingestion and normalisation.Week 2
- 05Dispatch logic and authority binding.Week 2, Week 3
- 06Confidence scoring and exception routing.Week 3
- 07Operator approval workflow.Week 3, Week 4
- 08DERMS and market-system integration.Week 5
- 09Baseline and authority cases.Week 4, Week 5
- 10Guardrails and dispatch controls.Week 4
- 11Fleet-trail instrumentation.Week 5, Week 6
- 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 tier | PilotOne programme, one market | ProductionProduction market systems | AdvancedMultiple markets / programmes |
|---|---|---|---|
| Introduced at Pilot | |||
| Dispatch to your enrolment and limits | ✓ | ✓ | ✓ |
| Operator approval | ✓ | ✓ | ✓ |
| Delivery-evidence baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by resource class | — | ✓ | ✓ |
| Approval workflow in your systems | — | ✓ | ✓ |
| Approved dispatch write-back | — | ✓ | ✓ |
| DERMS integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-market and multi-state rules | — | — | ✓ |
| Multi-stage operator approvals | — | — | ✓ |
| High device volume | — | — | ✓ |
| Multi-market fleet controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom 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.
You bring
We build with it
01Your enrolment records and device inventory
→Enrolment ingestion and authority mapping
Week 102Representative dispatch events
→Dispatch baseline, telemetry mapping and authority binding
Week 203Your programme rules and market registrations
→Programme, market and enrolment-rule mapping
Week 104Access to relevant APIs, feeds or exports
→DERMS, metering and market assessment, then integration setup
Week 205Dispatches you would not want called
→Authority cases and failure-mode testing
Week 406What must be proved before a megawatt is offered
→Confidence scoring, exception routing, guardrails and approval controls
Week 307Named operations leads to approve dispatches
→Operator approval 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
Each band covers the weeks it genuinely occupies, so the fifth week holds two kinds of work.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Dispatch workflow discovery, authority mapping and the automation boundary
W2Source integration and the dispatch baseline
W3Dispatch workflow, confidence logic and approval controls
W4Evaluation suite, authority checks and failure-mode testing
W5Market integration, pilot events and targeted corrections
W6One season dispatched under the operations desk, then handover
- Reading the band
- Each bar sits only on the weeks its work is named in. The week 5 overlap is real work, not padding.
- At the end of W6
- Live seasons close the validation and monitoring moves to Agent Care.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Energy AI agent
Build a fleet-control agent around the authority you can evidence.
Show us your enrolments, your programme rules and who attests. Offering capacity you cannot evidence is where this sector's largest penalties have come from. We'll map the dispatch workflow and set the boundary.
- Typical delivery
- 4–6 weeks
- Deployment
- Your markets and DERMS
- Operator approval
- Authority first
- After launch
- Agent Care available
Nestack Agents · Demand response & VPP fleet control
AGT-EN-07 · Agent Care available after launch