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.
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
AgentHuman
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.
5DecisionBranches at the confidence threshold
High confidence
Goes to the operations lead to approve.
Low confidence
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 required8 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 boundaryAgent 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 eventIllustrative example
Resource
Proposed action
Offered reduction
Authority on file
Confidence
Instruction
Residential battery
Discharge to the programme set point for the instructed window
4.2 kW
Signed enrolment
91%
RTO dispatch instruction
As receivedTaken from the enrolment record and the device telemetry — nothing on this side is written by the agent.
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 aggregateIllustrative 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 threshold2 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 stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Under-delivery rises in a resource slice.
02Diagnose
If the enrolment holds, the operator reads the telemetry, then the instruction, until one of them explains it.
03Improve
Changes ship against a version with the dispatches that caused them.
04Verify
A failing case blocks release until it clears.
05Learn
The case is permanent, and the enrolment rules move with it.
Learn → DetectThe 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.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Dispatch workflow discovery and automation-boundary definition.
02DERMS, metering and market assessment.
03Enrolment, authority and programme-rule mapping per market.
04Telemetry ingestion and normalisation.
05Dispatch logic and authority binding.
06Confidence scoring and exception routing.
07Operator approval workflow.
08DERMS and market-system integration.
09Baseline and authority cases.
10Guardrails and dispatch controls.
11Fleet-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 programme, one marketProductionProduction market systemsAdvancedMultiple 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 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 enrolment records and device inventory→Enrolment ingestion and authority mappingWeek 1
02Representative dispatch events→Dispatch baseline, telemetry mapping and authority bindingWeek 2
03Your programme rules and market registrations→Programme, market and enrolment-rule mappingWeek 1
04Access to relevant APIs, feeds or exports→DERMS, metering and market assessment, then integration setupWeek 2
05Dispatches you would not want called→Authority cases and failure-mode testingWeek 4
06What must be proved before a megawatt is offered→Confidence scoring, exception routing, guardrails and approval controlsWeek 3
07Named operations leads to approve dispatches→Operator approval 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 band covers the weeks it genuinely occupies, so the fifth week holds two kinds of work.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Dispatch workflow discovery, authority mapping and the automation boundaryW2Source integration and the dispatch baselineW3Dispatch workflow, confidence logic and approval controlsW4Evaluation suite, authority checks and failure-mode testingW5Market integration, pilot events and targeted correctionsW6One season dispatched under the operations desk, then handover
Reading the bandEach bar sits only on the weeks its work is named in. The week 5 overlap is real work, not padding.
At the end of W6Live seasons close the validation and monitoring moves to Agent Care.
DurationSix-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.
