Kestrel

Our own product: an operations OS for renewable energy

Kestrel is a product we designed without a client: an operations OS for wind, solar and storage portfolios, built around AI agents. The agents detect underperformance, investigate the cause with evidence and coordinate maintenance. People approve anything that spends money, sends a crew or changes a setpoint. We sell it as a Figma kit for teams building renewable energy and asset management software.

Energy operations is a good test for agent design. The data never stops, a fault costs money every hour it runs, and the people in the control room have every reason to distrust a model that sounds sure of itself. So every screen had to answer the same question: why should an operator believe this?

The command center leads with the gap

The command center opens with a briefing the agents write from the live signals. In the example the portfolio is 4.5 GWh below expected this month, one site explains most of it, and one tripped turbine needs a crew decision today. The decisions waiting sit right under it.

The centre of the screen is a 3D twin of the portfolio, with each site’s live state pinned to it and the agents’ latest finding pinned where it happened. Around it sit live output against installed capacity, net generation, the energy gap broken down by cause with an estimate of the revenue lost, performance against target, and the incident pipeline.

From a tripped turbine to verified recovery

An incident moves through seven stages, from detected to resolved, and the page shows all of them. In the example, six turbines at one site sit 9.6% below their power curve. The diagnostics agent proposes a probable cause: a controller firmware update that changed the yaw offset on exactly those six turbines, while 42 sister turbines on the previous version stayed normal.

The finding is labelled as not yet verified, carries a confidence of 86% calibrated on past confirmed cases with the same evidence pattern, and has a button to challenge it. A cutaway of the turbine shows where the fault sits. An incident only closes once the recovery has been verified against criteria, so a fix that looks done is never mistaken for one that worked.

A plan with its impact, risk and rollback

Approving a plan means reading exactly what will happen next. Restoring the yaw offset is three steps: snapshot the controller parameters, write the change one turbine at a time, and roll back on its own if the vane error passes three degrees. The expected gain, the risk and the time to roll back sit above the button, along with who will be told when it starts.

Twenty action states cover the rest of the decisions an operator makes: reject with a reason, edit the plan, challenge a finding, pause execution, roll back one action or all of them, nudge an approver, or resolve with an exception and an audit note.

Five agents, one written policy

Five agents share the work: detection, diagnostics, maintenance, data quality and a recovery verifier that confirms output is back before anything closes. Each shows its actions this month, how many stayed within policy, and how many it escalated or rolled back.

The policy is written down and versioned, and some things are never automated. Setpoint changes roll out one turbine at a time with automatic rollback, every action is logged with its evidence and its approver, the agents pause when the plant data goes stale, and curtailing or stopping a turbine stays with people.

Ask why, get an answer with evidence

Ask Kestrel answers in the operator’s terms. Asked why a site is behind this month, it checks four sources, gives the gap in one sentence, and splits it into downtime, underperformance, curtailment and what it cannot yet explain. It lists the incidents driving it, the sources behind each number, and suggested next steps with their value, each waiting for the right person to approve.

Every site and asset, down to one bearing

The sites screens go from the portfolio to one site with its twin and turbine grid, then to the asset register, then to a single turbine with its bearing temperature and the health of each component. That is the screen an engineer opens before deciding whether to send a crew.

Sixteen renders in one style

The renders are part of the product, not decoration. Sixteen isometric 3D renders of wind, solar and storage sites, cutaways and individual assets were made for it, all lit and shot the same way, so the twin on the command center, the turbine cutaway in an incident and the site cards read as one product.

A system built for live energy data

The file runs on 99 variables in three collections, primitives, colour, and spacing and radius, with severity and incident stage colours as tokens of their own so status reads the same on every screen. There are 18 component sets with 84 variants plus 23 standalone components, and 24 text styles in General Sans.

The 42 screens run across ten sections, 22 product screens and 20 action states, with 95% of frames in auto layout and a read me page that indexes every screen. The kit is on our products page.