Multi-agent AI platform for grid planning and large loads

Multi-agent system, 2026 to present. Built at UC Berkeley with support from a U.S. Department of Energy funded subcontract.

The problem

A single large load request, a data center asking for several hundred megawatts, sets off a chain of questions that no one specialist can answer alone: where the request sits in the interconnection queue, which network upgrades it triggers, which regulatory process governs it, and what the hourly system looks like once the load is energized. The answers live in queue data, planning studies, tariffs, and production cost models, and assembling them takes weeks of expert time. The queue keeps growing while that work happens.

What I built

I built a multi-agent AI platform that routes a question to the specialist that should answer it, then holds the pieces together into one answer. Four specialist agents cover interconnection, infrastructure, regulation, and power system analysis, coordinated by stateful routing that carries session and project context across a conversation rather than treating each question as new. Each specialist reaches structured domain datasets and engineering tools through schema-based tool calling, so numbers come from the tool that owns them instead of from the model’s recollection. Retrieval is hybrid, combining dense vectors in ChromaDB with BM25 keyword search and reciprocal rank fusion over a technical and regulatory knowledge base that keeps expanding.

How I know whether it works

I built an evaluation and regression harness alongside the system, because a copilot that sounds authoritative and is quietly wrong is worse than no copilot. It runs a fixed question set through multiple models, scores responses blind, and reports separately on retrieval quality, routing correctness, tool-use correctness, and response quality. Every change to the retrieval layer or the router is re-run against the same set, so regressions surface as a number rather than as a complaint weeks later.

The scoring itself has a failure mode worth naming: an LLM judge is least reliable exactly where the domain is hardest, on questions whose correctness depends on a unit convention or on a value that should have come from a tool call rather than from retrieved text. Those questions need a deterministic check, not a judge.

Limits

The platform supports the analyst who prepares a study. It does not replace a power flow study, an interconnection study, or the engineering judgment that signs off on either. Its answers are bounded by what is in the knowledge base, which is why coverage and freshness of that base, rather than model choice, is the thing I spend most maintenance effort on.