Industry: Energy & Utilities    |    Region: United Kingdom    |    Client Type: Enterprise (Regulated Utility)

About the Client

The client is a mid-tier UK energy utility managing 2.4GW of renewable generation capacity, offshore wind farms in the North Sea and solar installations across southern England. They operate in the GB electricity market, where generators must submit forecasts of their output to the grid operator (National Grid ESO) and pay imbalance charges when actual generation deviates from forecast.

The UK’s push toward net zero has made renewable forecasting a board-level concern. With offshore wind now contributing over 25% of UK electricity, the financial stakes of getting forecasts wrong have exploded.

The Challenge: £12M in Imbalance Charges and a 30-Minute Deadline

The GB electricity market operates in 30-minute Settlement Periods. Before each period, generators submit their expected output. After the period, the actual output is compared to the forecast. If you generated less than forecast, you pay to buy replacement power at the System Buy Price (often 2–5x the wholesale rate). If you generated more, you sell the excess at the System Sell Price (often 50–70% of wholesale).

Getting this wrong is expensive. The client was paying £12 million per year in imbalance charges. Their existing forecasting system, a statistical model trained on historical weather data, achieved 82% accuracy on a 4-hour horizon. That sounds reasonable until you realize that the 18% error translates directly into millions in charges, because errors during high-price periods (winter evenings, low-wind events) are disproportionately costly.

The real challenge was the multi-dimensional nature of the problem. Accurate forecasting requires integrating satellite imagery (cloud cover), numerical weather prediction models (wind speed and direction at hub height),turbine-level SCADA data (current output and availability), market price signals (when is it worth curtailing vs. generating?) and battery storage optimization (when to charge vs. discharge across 14 sites).

Agent Architecture: 3 AI Agents for Forecast, Position and Dispatch

┌─ SYSTEM ARCHITECTURE, Agentic Grid Balancing

┌─────────────────────┐    ┌─────────────────────┐
│ Satellite Imagery   │    │ NWP Weather Models  │
│ (EUMETSAT MSG)      │    │ (Met Office UKV)    │
└──────────┬──────────┘    └──────────┬──────────┘
           │                         │
           └─────────┬─────────────┘
                     ▼
┌─────────────────────────────────────────────┐
│  AGENT 1: WEATHER-TO-WIRE FORECASTING      │
│  Multi-modal fusion: satellite + NWP + SCADA │
│  Output: MW forecast per site (30-min res)   │
│  MCP → SCADA (turbine availability/output)   │
└──────────────────────┬──────────────────────┘
                      │ (A2A: generation_forecast)
           ┌─────────┼───────────┐
           ▼                    ▼
┌───────────────────┐  ┌───────────────────┐
│ AGENT 2: MARKET     │  │ AGENT 3: DISPATCH   │
│ POSITION AGENT      │  │ OPTIMIZATION AGENT  │
│ MCP → EPEX/N2EX     │  │ Battery + Curtail   │
│ MCP → Elexon BSC    │  │ MCP → BMS (14 sites)│
│ Optimal position    │  │ Real-time dispatch   │
└───────────────────┘  └───────────────────┘

  Claude Code multi-agent orchestration for reasoning layer
  Sovereign UK deployment (Azure UK South) per Ofgem reqs
  Full audit trail for BSC compliance and Ofgem reporting

Agent 1: Weather-to-Wire Forecasting AI Agent

This ai agent fuses three data streams to produce MW-level generation forecasts for each of the client’s 14 asset sites, at 30-minute resolution, across a 4-hour rolling horizon.

• Satellite imagery (EUMETSAT Meteosat) processed by a vision model for cloud cover analysis and movement prediction.
• Numerical Weather Prediction (Met Office UKV model) for wind speed at hub height (80–120m) and irradiance forecasts.
• Turbine-level SCADA data via MCP connector, which turbines are available, current output, any curtailment orders from National Grid.

The multi-modal fusion model learned that satellite imagery is the best predictor for solar output 0–2 hours ahead (cloud shadows move predictably), while NWP models are better for wind output 2–4 hours ahead. The agent dynamically weights data sources based on the forecast horizon and weather conditions.

Agent 2: Market Position AI Agent

The Market Position ai Agent reads real-time and forward pricing signals from the EPEX/N2EX power exchanges and Elexon BSC settlement data via MCP connectors. It determines the financially optimal market position based on the generation forecast and current prices. Sometimes the right move isn’t to generate maximum power, if the System Sell Price is very low, it may be better to curtail and save battery capacity for a high-price period later.

Agent 3: Dispatch Optimization AI Agent

The dispatch ai Agent translates market positions into physical actions: curtailment orders to wind/solar sites and charge/discharge commands to 14 battery storage systems. It connects to each site’s Battery Management System (BMS) via MCP connectors. Decision latency: 340ms end-to-end, well within the 30-minute settlement cycle.

Dextra Labs’ Workflow: Every 30 Minutes, Automatically

Step 1: Data Collection (T-60 min)

The Forecasting ai Agent pulls the latest satellite imagery, NWP forecast and SCADA data across all 14 sites. Processing begins automatically 60 minutes before the Settlement Period.

Step 2: Generation Forecast (T-55 min)

The multi-modal fusion model produces a MW forecast per site. The aggregate portfolio forecast is published via A2A to both the Market Position Agent and Dispatch Agent.

Step 3: Market Optimization (T-45 min)

The Market Position ai Agent evaluates the forecast against current EPEX prices, forward curves and historical imbalance prices for the time of day. It calculates the optimal declared position, which may differ from the raw forecast if market conditions favor over- or under-declaring.

Step 4: Dispatch Commands (T-30 min)

The Dispatch ai Agent sends curtailment and battery commands to all 14 sites. Battery dispatch decisions consider state of charge, cycle degradation and upcoming forecast periods (no point draining a battery at 6pm if the wind drops at 7pm and prices spike).

Step 5: Position Submission (T-15 min)

The declared generation position is submitted to Elexon via API before the gate closure deadline. Full audit trail logged.

Step 6: Settlement Comparison (T+30 min)

After the period, actual generation is compared to the declared position. Imbalance charges (if any) are calculated. Every cycle feeds back into the forecasting model’s continuous training pipeline.

Implementation Decisions

Decision Area	What We Chose	Why / Trade-Offs
Reasoning engine	Claude Code multi-agent orchestration	Claude Code’s agent teams feature allowed us to structure the three agents as subagents under a coordinator. The coordinator handles the 30-minute scheduling cycle and error recovery. Claude’s reasoning capability was used for market position optimization where the logic requires balancing multiple competing objectives.
Forecasting model	Custom multi-modal fusion over off-the-shelf weather-to-power models	Off-the-shelf models achieved 86% accuracy. Our multi-modal fusion (satellite + NWP + SCADA) achieved 94.7% at 4-hour horizon. The 8.7% improvement translates to £millions in reduced imbalance charges because errors during high-price periods are disproportionately costly.
MCP integrations	5 MCP connectors (SCADA, EPEX, N2EX, Elexon BSC, BMS)	MCP standardized all external system access. Critical benefit: new asset sites can be added by deploying a new MCP connector instance without changing agent logic. Reduced per-site integration time from 3 weeks to 3 days.
Deployment	Azure UK South (sovereign)	Ofgem data residency requirements. All generation data, trading positions and market intelligence stays in UK. The system is classified as Critical National Infrastructure-adjacent, requiring enhanced security controls.
Decision latency	340ms end-to-end over batch processing	The 30-minute settlement cycle seems generous, but the gate closure deadline means decisions must be made and communicated to 14 sites within minutes. Stream-based architecture ensures the system runs continuously, not in batch windows.
Battery optimization	Mixed-integer linear programming + Claude reasoning	Battery dispatch involves hard physical constraints (max charge/discharge rates, cycle degradation, SOC limits) best handled by MILP. But the decision of when to charge vs. discharge depends on market conditions that benefit from Claude’s ability to reason about price patterns and weather forecasts simultaneously.

Tech Stack

Claude Code (multi-agent orchestration)  ·  Claude 3.5 Sonnet  ·  PyTorch (vision model)  ·  XGBoost (wind forecast)  ·  MCP connectors (5)  ·  A2A Protocol  ·  Azure UK South  ·  TimescaleDB  ·  Python FastAPI  ·  Apache Kafka

Results

£12M → £3.2M Annual imbalance charges

94.7% Generation forecast accuracy (4-hour)

£8.4M Additional revenue from optimized dispatch

340ms Decision latency (end-to-end)

Imbalance charges dropped from £12M to £3.2M in the first year. The remaining £3.2M represents genuinely unpredictable weather events (sudden wind ramp-downs, fog events) where no forecasting system can eliminate error entirely.

But the bigger win was the revenue optimization. The Dispatch Agent’s battery optimization and strategic curtailment generated £8.4M in additional revenue by shifting generation and storage into higher-price settlement periods. The combined financial impact: £8.8M improvement per year + £8.4M revenue = £17.2M total impact on a system that cost under £1.5M to build and deploy.

“The system doesn’t just forecast better, it trades better. The battery optimization alone paid for the entire project in the first quarter.” – Head of Trading & Optimization, UK Energy Utility

Engagement Timeline: 14 Weeks

Weeks 1–3: discovery, data access agreements, Elexon/EPEX API onboarding.

Weeks 4–7: Forecasting Agent development (satellite processing, NWP integration, SCADA MCP connector).

Weeks 6–10: Market Position Agent (EPEX/Elexon MCP connectors, trading logic).

Weeks 8–12: Dispatch Agent (BMS MCP connectors across 14 sites, battery optimization).

Weeks 13–14: parallel running with existing system, calibration, production cut-over.