A platform like ours is only as good as the data coming into it, and we integrate more than 30,000 assets across thousands of sites. The hard part is not only the optimisation (and the optimisation is hard enough!). It is also knowing, at any given moment, that each asset is still connected, still reporting, and still sending numbers we can trust.

‍

The approach: a team of AI agents across five layers

We treat integration health as a pipeline of five layers, each run by its own agent. Detection produces the alerts; clustering, interpretation, resolution and learning turn them into a short list of resolved problems, then feed what they learn back in. An agent runs each of the upper layers end to end.

‍

‍

Our platform relies on the data underneath each asset: that it is arriving, correct and current. Everything we do on top of it, from modelling costs to forecasting to steering assets on the market, assumes those numbers can be trusted. When that assumption breaks, everything downstream is working from bad numbers.

We work with multi-site, multi-asset systems: fleets of batteries, solar arrays, EV chargers and grid connections. Each asset reaches us through an integration, which is a data feed from a hardware vendor, an aggregator, a customer's own API, or a grid operator. Many assets deliberately send more than one stream: a second, independent feed we can cross-check against. That redundancy makes the whole thing more robust, but it also means there is more to keep an eye on. More than thirty thousand assets are connected today. Every one has to be integrated first, and kept that way.

No two integrations are the same. Some stream readings every few seconds over MQTT. Others push a batch file once a day. Some we poll from a REST API on a fixed schedule. Others arrive as a CSV dropped on an sFTP server. The granularity runs from sub-second to hourly, the update frequency from continuous to daily, and the protocols and formats vary just as much. That heterogeneity is most of the difficulty. "Is this feed healthy?" has a different answer for nearly every integration, so there is no single check that works for all of them.

And health is not only about whether data is arriving. For the assets we steer, there is a second question: is the integration quality good enough to switch steering on, and to take on the financial risk that comes with it, yes or no? That is a harder judgment than "did a number show up," and it adds a whole layer of complexity on top of the integrations themselves.

On top of that, things sometimes break quietly. A firmware update might change a unit without anyone being told. None of this throws an obvious error; the data just stops being useful. We cannot even try to catch this by having people watch dashboards and messages. That does not scale to 30,000 integrations. Our new agentic system does.

‍

Detection: first we made every silent failure visible

We wrote a set of monitors that run continuously across the fleet and turn anything suspicious into a timestamped, per-asset incident, tagged with the customer and the integration. Six of them feed one queue in incident.io, the incident-management platform the whole system is built on.

‍

‍

These monitors are not all on the same level. Some sit upstream of others: whether an asset is eligible to be steered, and whether its nomination is sane, come before whether it actually complies with its signal. A compliance alert is often just the visible symptom of an eligibility or nomination problem higher up.

‍

The volume problem

Once every silent failure turned into an incident, the queue filled up fast. Take a random ten-day rolling window: the monitors detected 1,044 incidents. That looks alarming, but most were not separate problems.

‍

‍

A single failing feed could generate dozens of incidents. In the worst case we saw, one supplier's API feed produced 86 incidents in ten days: one real problem (a feed that kept flapping), one obvious action (chase the partner), 86 separate tickets. Because the underlying monitor re-runs every fifteen minutes, each lapse opened a fresh incident.

It was not only repeat firing. The same underlying fault often shows up as several different alerts. A degraded feed trips a Connectivity alert, then a Consensus mismatch, then a Compliance alert as the effect spreads downstream: three alert types, but only one cause. A partner outage can light up every asset on that integration at the same time: one cause, many assets.

The mess is also rather concentrated. Once the merges and snoozes are stripped away, most of the distinct work sits in one layer of the stack, the integration data itself. The market-side alerts, compliance especially, are mostly downstream symptoms of something further up.

‍

‍

The goal: one real problem should be one incident

So we changed what we were counting. The thing that matters is not the alert, it is the action. If two incidents need the same fix, whether that is contacting the same partner or turning off steering on the same dead feed, they should be one incident. In practice the right grouping key is customer plus integration, because that is the unit of action.

‍

‍

A small team of agents

Layers two to five are run by a small team of agents, each with a single job on the live queue. Think of them as colleagues who never sleep: a Cluster Agent that groups duplicates into one incident, a Diagnosis Agent that finds the cause, a Dispatch Agent that decides the fix, dispatches the information to partners and customers, and hands it off in chat, a Recovery Agent that closes things out once they heal, and a Learning Agent that works to stop the problem coming back. The queue lives in incident.io, and the incident record there is the single source of truth they all work from. The loop runs on its own, pausing only for sign-off on the few steps that cannot be undone.

Getting 30,000 assets connected, and keeping them that way, is hard enough. For the ones we steer it gets even harder: we have to decide whether the data is good enough to stake real money on, and that decision happens continuously. - Erik Vandeputte, Engineer, Companion.energy

‍

‍

Why incident.io

We did not want to build the plumbing for an agentic system from scratch. incident.io gave us the right infrastructure: every incident is a durable, structured record that an agent can read, update and close through an API, so the queue itself becomes the shared memory the agents coordinate through. Rather than wiring together our own state store, task hand-offs and human escalation, we let each agent act on the incident and hand off to the next, with a person looped in over chat only for the steps that cannot be undone. That let us stand the team of agents up quickly and spend our time on the judgment calls that are specific to energy, not on the machinery of running agents.

‍

Reliable by design

For a platform whose value comes from thousands of distributed assets, integration health is key. An asset acting on a stale signal can lose money.

What a customer cares about isn't our monitoring. It's that their assets keep earning money. A stale signal can cause money to be lost. Both are invisible until you go looking. Having the agents surface and fix them the same day means I can tell customers their returns are actively protected, not just measured. - Andreas De Rijcke, Solution Engineer, Companion.energy

Catching these problems early, grouping them into a single thing to act on, and getting them to the right person the same day is what keeps the benefit we promise reliable rather than best-effort.

We went from silent failures nobody could see, to a loud queue nobody could clear, to a small set of real problems that each have a cause, an owner and a path to close. - Gert-Jan Braeckevelt, SRE, Companion.energy

‍

This runs across the whole fleet today, continuously tuning the noisiest feeds and cutting down repeat firing as it goes.