The Coordination Gap

Bart in 't Veld | L |

the coordination gap

Walk through any energy trade fair in 2026 and you'll see a complete ecosystem of solutions for the home: smart meters, EV chargers with V2G capability, home batteries, heat pump controllers, dynamic tariff platforms, energy management systems with APIs to anywhere. The hardware is there. The protocols exist. The standards are maturing.

So why does my local grid still cry at 18:00?

Why scaling the energy transition behind the metre isn't a hardware problem

That question has nagged at me for a while. I work in software for the energy and e-mobility sector, and I get to watch how individual products perform inside their own boundaries (very well, usually) and then what happens when those products meet each other in the wild (less well, usually). The gap between those two states is, in my view, the most important problem in the sector right now. It is also the most undertheorised.

This is my attempt to put a name on it.

The paradox of individual excellence

Picture a Tuesday evening at six. EVs plug in the moment their owners arrive home. Heat pumps ramp up as thermostats register occupied rooms. Induction hobs come on. None of these devices is doing anything wrong. Every household is behaving rationally. Each appliance is operating exactly as designed.

The result is a coincident demand spike that exceeds local network capacity, not because any single appliance is excessive, but because every appliance is reacting to the same signal at the same time.

Annual energy figures hide this. The averages look fine. It is the fifteen-minute peaks that hurt. The stress in the system isn't spread across the year; it concentrates into a handful of brutal intervals driven by coincident demand.

Every party in the chain is doing a good job within its own domain. That is exactly the problem.

It isn't a technology gap

When pilots fail to scale, the reflex is to look for the missing component. A better battery. A cleverer optimiser. One more standard. I've sat in plenty of meetings where this reflex won.

It is, I think, the wrong reflex.

In a controlled pilot, with aligned stakeholders and well-defined boundaries, smart charging works. Demand response delivers measurable peak reduction. Local storage proves out. The technology performs in the small.

What stalls is the move from the small to the not-small. The equipment is ready. The urgency is acknowledged. Funding is often even in place. What is missing is the mechanism that turns a working pilot into a working neighbourhood, district, or city.

That mechanism isn't a piece of hardware. It is coordination.

The four upper layers

ElaadNL has a useful frame for this: a four-layer model of interoperability. The bottom layer: technical connectivity, is largely solved. Devices can talk. Data flows.

The three layers above it are where the work actually is.

Communication. Are the right messages exchanged in the right format at the right time? Bytes moving over a wire is not the same as parties understanding each other.

Organisation. Who has decision-making authority over which asset? Who orchestrates whom? Where do responsibilities sit when an EV, a heat pump, and a battery in the same house all want to do something at 18:00?

Legal and regulatory. Who carries the risk of a steering signal that misfires? Who is liable when a curtailment costs a consumer money? What contracts underpin the coordination?

When a pilot stalls at scale, the failure is almost always somewhere in those upper three. The systems communicate technically. They don't communicate organisationally. The bytes arrive, but the agreement about what to do with them is missing or contested.

This is what I mean by a coordination gap. It is the space between domains where no single party is responsible for system-level outcomes. The 18:00 peak doesn't arise inside any one domain. It emerges at the seams.

Rational actors, irrational outcomes

Each party in the chain follows its own logic. The EV driver wants comfort and a full battery in the morning. The supplier wants margin and retention. The grid operator wants network stability. The municipality wants policy targets met and citizens not annoyed. None of these objectives is unreasonable.

But pursued independently, they create a system in which nobody owns the outcome at the level that matters: the local low-voltage grid.

The evening peak is not a failure of any single actor. It is the predictable consequence of locally rational behaviour in a system whose seams nobody owns.

Trust has to be structural

At a neighbourhood level, trust is personal. You trust your neighbour because you know them. At a system level, with hundreds of parties and millions of devices acting autonomously, trust cannot rest on personal relationships. It has to be designed in.

I think structural trust rests on three pillars, and any coordination mechanism that lacks one of them will fail to scale.

Transparency. All parties can see what is happening in the system in something close to real time. Asset behaviour, grid conditions, the logic behind a steering decision.

Predictability. When a charging session is shifted or a heat pump is curtailed, the rule that produced that outcome is knowable, stable, and consistent. Surprise is the enemy.

Enforceability. Agreements are verifiable and, where necessary, enforceable. Commitments are auditable. "We said we'd do X" can be checked against "did X happen".

Without all three, the system relies on goodwill, which does not survive contact with scale.

Software as coordination infrastructure

Here is the reframing that I keep coming back to. In the energy domain behind the metre, software should not be thought of as a product that optimises a single device or a single actor's position. It should be thought of as coordination infrastructure: the shared digital layer that lets multiple parties act coherently.

The distinction matters because it changes what "good software" means.

A product mindset asks: does this optimise my asset, my customer, my margin? A coordination-infrastructure mindset asks: does this make it possible for me and the other parties on this grid to behave in a way that adds up?

The first mindset is how we got the 18:00 peak. The second mindset is how we get out of it.

Coordination infrastructure, in practice, does four things:

  1. Visibility. It makes the state of assets, grid capacity, and energy flows accessible to relevant parties in near real time.
  2. Predictable steering. It translates grid constraints and market signals into rule-based instructions that devices and operators can act on without guessing.
  3. Verifiability. It produces auditable records of who did what, when, and why.
  4. Testability. It lets coordination logic be simulated and stress-tested before deployment.

When software is built this way, it stops optimising individual assets and starts orchestrating system-level behaviour. It becomes the connective tissue that the fragmented energy chain currently lacks.

E-mobility has already done a version of this

I find the e-mobility precedent encouraging, because it shows that designed coordination is achievable in the real world. Two protocols have done most of the work.

OCPP, the Open Charge Point Protocol, standardises the conversation between a charge point and its management system: which messages are exchanged, when, in what format, with which responsibilities on each side. It is not just a data interface; it is a coordination agreement encoded in software.

OCPI, the Open Charge Point Interface, extends that to the ecosystem level — how operators, mobility service providers, and roaming platforms discover each other, share tariffs, authorise sessions, and settle.

Together, OCPP and OCPI deliver the foundations of the three pillars of structural trust I mentioned earlier. They define what is shared (transparency). They standardise how decisions are communicated (predictability). They create artefacts that can be audited (enforceability).

But, and this is the part the sector sometimes forgets, protocols are a necessary condition for coordination, not a sufficient one. OCPI tells you the shape of a session record. It does not, by itself, guarantee that the record one party sent and the record another party received represent the same session. That guarantee has to be built. It is a thing software does, not a thing a protocol is.

This is, full disclosure, the layer I work on day-to-day. At ENAPI we build an OCPI-native coordination layer between charge point operators and e-mobility service providers: the work that sits between "the protocol says this" and "the parties agree on what happened." I mention it because it makes the broader point concrete: in e-mobility the protocol alone wasn't enough. An entire layer of clearing, verification, and dispute resolution had to be built on top of OCPI for it to do what it promised.

The rest of the energy system behind the metre is going to need the same treatment. Heat pumps, batteries, solar inverters, smart appliances; they need the protocols, yes, but they also need the coordination layer on top of those protocols. The principle is proven. What remains is the work.

What I think comes next

If I had to compress this into three shifts the sector needs to make:

From pilots to scalable coordination. Pilots prove feasibility. They don't, by themselves, prove anything about scale. The goal cannot be another successful pilot; it has to be a replicable coordination framework that survives moving from twelve aligned stakeholders to twelve hundred unaligned ones.

From isolated optimisation to system accountability. As long as each party optimises only within its own domain, peak demand will continue to arise at the boundaries. The sector needs actors who accept accountability for system-level outcomes, and incentive structures that make that accountability worth accepting.

From adding technology to designing behaviour. The energy transition behind the metre is not waiting for a new device. It is waiting for designed rules of engagement that align the behaviour of devices, operators, and consumers. Technology is the enabler. Coordination is the catalyst.

Closing thought

The pieces are on the board. Smart devices are deployed in growing numbers. Open standards are maturing. Market interest is strong, policy support is increasing.

What is missing is the recognition that pieces do not assemble themselves. Every party doing a good job within its own domain is, paradoxically, the precondition for system-level failure. Grid congestion, stalled rollouts, and the 18:00 peak are not symptoms of immature technology. They are symptoms of an unowned coordination gap.

Closing that gap is, to my mind, the actual job. And it is mostly a software job — not in the sense of writing more clever optimisers, but in the sense of building the shared infrastructure that lets a fragmented sector behave like a coherent system.