A household with a smart thermostat and central air conditioning can be enrolled in two demand response (DR) programs at once. The thermostat program counts its cooling load. A second program for heating, ventilation, and air conditioning (HVAC) counts the same load again. If different aggregators run the two programs, and nobody compares the two enrollment lists, the utility’s portfolio carries that load twice.

Double counting is a small symptom of a structural fact. Utilities typically built their demand response portfolios one program at a time, and each program was designed to stand on its own, with its own aggregator, its own staff, and its own data. Any question that spans them, such as how much verified capacity a constrained substation can call on, means stitching data sets together by hand.

That problem was the subject of Leveling Up: From Programs to Orchestrated Demand Response, a Codibly webinar held on September 24, 2026. Enoch Lenge, Codibly’s Head of US, Energy Practice, spent 13 years at Eversource before joining Codibly, working across energy efficiency, demand response, and electric vehicle (EV) charging programs. Stina Brock, CEO of Derapi, began her energy career in demand response at EnerNOC. Between them they covered both ends of the problem, coordinating programs once they run and getting customers into them.

Why each demand response program ends up in its own silo

Demand response began with large commercial and industrial customers, called on during summer peaks by day-ahead email and phone. That worked for occasional emergencies but strained in the West, Brock recalled, where heat events ran for days. Connected devices changed that. Two-way communication with thermostats, EV chargers, and batteries made control faster and data more frequent, and new programs followed each device type into households.

How each program gets created explains the rest. A regulatory framework comes first. The utility designs the program, runs a bid to select an aggregator or qualified vendor, launches, and then reports to the regulator. The cycle repeats for each device type: thermostats one year, EV chargers the next, then battery storage, then perhaps HVAC. Each round produces a program with its own staff and its own vendor, and no step in the cycle asks the new program to share data with the ones before it.

Nobody designed the silos. They are what a sound, regulator-approved process produces when it runs four times in a row.

Three things utilities now ask for across programs

Over the last six to eight months, Codibly has heard the same request from utilities running several of these programs: a way to orchestrate across the aggregators already operating in their service territory. Three reasons keep coming up.

Regulatory reporting. Regulators expect quarterly and annual reports on what each program delivered. Producing them means pulling data from each aggregator separately and sifting through each data set by hand, every reporting period. Utilities want that work automated.

Validation. The utility is the party that confirms what was delivered. With advanced metering infrastructure (AMI), it can compare what aggregators report against what the meters recorded. Validation also covers enrollment: the thermostat and HVAC overlap only becomes visible when enrollment data from both aggregators lands in one place.

Coordination between operations and programs. Operations staff watch constrained substations and circuits. Program staff run enrollment and events. Historically the two groups had no reason to talk, and in many utilities they never have. Flexible load spread across many devices gives them one, because it can relieve constraints that would otherwise call for projects such as a substation upgrade. Acting on that means agreeing what data to share, when, and why.

The third request is the hardest, and most of the difficulty is organizational.

Need In a portfolio of separate programs With a layer above the aggregators
Regulatory reporting Data pulled from each aggregator separately and sifted by hand for quarterly and annual reports Data from every aggregator mapped to one taxonomy; reports built from one source
Validation Reported delivery checked program by program Reported delivery reconciled against AMI meter and event data across programs
Duplicate enrollment Overlaps between programs stay invisible The same customer matched across programs; double-counted load flagged
Grid coordination Operations and program teams work separately Devices and aggregators mapped to constrained substations and circuits for event planning
Customer view Each program sees its own slice of the customer One customer across all programs, with enrolled load, devices, and incentives
What changes when a utility-side layer sits above the aggregators and reconciles what they report.

What an orchestration layer does above the aggregators

Codibly turned those requests into a proof of concept for what Lenge called an aggregator of aggregators: a utility-side layer that collects data from every aggregator’s system and gives the utility one view across programs. The webinar demo used a fictional utility and illustrative figures.

The layer maps each partner’s terms to one taxonomy, so capacity, availability, and event status mean the same thing whichever aggregator reports them. It reconciles reported delivery against meter and event data. It makes data quality explicit: how fresh each feed is, where the gaps are, and how much confidence the numbers deserve. And it gives one portfolio view of contracted, enrolled, and verified capacity, with load counted twice flagged separately.

The proof of concept also drills down: to the aggregators and device types in each constrained substation area, to events across programs with reported and verified results side by side, to one household across every program it joined, and to forecasts for event planning.

Each aggregator keeps its own platform, devices, and customer relationships. The layer reads from them through aggregator and optimizer integrations and replaces none of them.

Utilities can already buy distributed energy resource management system (DERMS) and virtual power plant (VPP) software from many good vendors. Brock, whose company partners with several of them, said as much after the demo, adding that every utility’s internal systems and goals differ, so a customizable option is increasingly useful. That is the case for a modular approach to DERMS and VPP software over one monolithic platform. Lenge had closed the demo with a caveat: orchestration needs collaboration as much as software, with the utility’s external partners and between its internal groups.

Where orchestration meets the grid

The substation view is where the coordination request becomes practical. When operations can see, for each constrained area, which devices are there, which aggregator manages them, and how much load they carry, the utility can decide where, when, and how to call an event with the grid in mind.

One audience question pushed this further: could a grid DERMS connect to several edge DERMS aggregators and dispatch them automatically, for flexible interconnection, based on grid needs? Lenge’s answer was that it is doable and a large piece of work. The technical integration is one half; collaboration between operations and program teams matters just as much. Flexible interconnection depends on the same capability, because a conditional connection only holds if dispatch reaches the right resources when the grid needs them.

Open standards make that integration easier to repeat. OpenADR and IEEE 2030.5 give utilities a standard way to collect device data and control devices, and many DR programs now require them. Codibly uses pre-built accelerators for OpenADR and IEEE 2030.5 as building blocks, so a new integration starts from existing code.

Without customers, there is no data

One question in the Q&A set data against people: which matters more, great data orchestration or customer trust? Lenge put the customer first. A thermostat was never meant to be a demand response device. Its owner needs a simple reason to take part, whether the environment, the grid, or a financial incentive, and an enrollment that feels smooth. Customers who have a bad experience burn out, opt out, and tell friends and family. Without customers, there is no data flowing and nothing to orchestrate.

Brock agreed, with an example from Derapi. One of its engineers noticed a customer’s battery sitting idle outside VPP events, when local rates would have let it earn the customer more. Derapi worked with the manufacturer to fix it, because a customer with a poor experience may opt out, and every opt-out removes capacity the system depends on.

Getting devices into programs is where Derapi works. Brock described it as a software connection hub: DR and VPP platforms connect once and reach integrations with solar inverters, batteries, EV chargers, smart appliances, and thermostats. She said Derapi has strong battery manufacturer partnerships and is starting to work with thermostat and EV charger makers, because program incentives only reach customers whose device type is approved.

Brock also set out Derapi’s Bring Your Own Distributed Capacity (BYODC) framework. Data centers and other large loads fund local distributed energy resources (DERs) that provide capacity and peak reduction where the grid needs it, and, according to Brock, the community gets lower energy costs, backup power, and local investment. For utilities, that means more DERs in specific places, funded by new parties, that someone has to coordinate against local grid constraints.

Where a utility can start

The first step involves no software. Lenge stressed the need for a champion: someone inside the utility willing to think collectively about customers across the service territory. Then list every program, its aggregator, and what each one reports, in its own terms. That list is the raw material for a shared taxonomy.

Make validation the first cross-program use case. Matching enrollment across aggregators and checking delivery against AMI data both answer a regulatory requirement the utility already has, so the business case does not wait for grid benefits.

Put operations and program staff on one constrained substation or circuit, and agree what data each needs from the other, when, and why.

Treat customer experience as a program requirement from the start. Education, a smooth enrollment, and value outside events decide whether the data keeps flowing.

And ask new aggregators and device partners for open standards, so each new program arrives as one more data source for the portfolio.

Codibly has spent 15 years building custom software and integrations for utilities, DERMS providers, aggregators, and equipment manufacturers, much of it for demand response programs. That work starts from the systems a utility already runs. If your programs have outgrown one-at-a-time management, talk to our team.