Agentic transmission planning: how AI agents run power-flow studies

A script follows a fixed procedure. An agent chooses the next permitted action after seeing an intermediate result. In a planning study that might mean loading a case, finding disconnected buses, asking for a missing assumption, running a contingency batch, tracing the elements behind a thermal violation and drafting a comparison of the options that remain.

Take an engineer asking, “How does a 100 MW connection at this bus change the stressed cases?” A useful agent turns that sentence into a defined injection or withdrawal, a balancing rule, specific case versions, operating conditions and monitored limits. It should resolve ambiguity before launching a large study rather than quietly picking the assumptions that make the request easiest to complete.

Three layers do the work. A language model interprets the request and plans. A tool layer, often an MCP server, exposes defined engineering functions such as case management, power flow and result queries. The established numerical engine (PSS®E, PowerWorld, pandapower, PowSyBl, MATPOWER) solves the network. The language model never calculates the network state itself.

Agents also follow up selectively. If a revised case changes the first limiting element, the agent can compare that element’s ratings, topology and dispatch with the earlier version and report why the answer moved. That is a more useful result than a paragraph saying the area is congested.

The pressure is volume. T&D World, citing Lawrence Berkeley National Laboratory, reports that more than 2,000 GW of generation and storage was seeking transmission interconnection at the end of 2025, and that projects reaching operation that year had waited a median of more than five years. Large-load requests from data centers are adding a second queue on top. In ERCOT alone, large-load requests reached about 410 GW in March 2026.

The rules have tightened at the same time. FERC Order No. 2023 moved interconnection to annual cluster studies, replaced the old “reasonable efforts” standard with firm study deadlines (150 days for an initial cluster study) and introduced penalties for transmission providers that miss them. The number of planning engineers has not grown at the same rate, so the work around each study has become the constraint.

That is the gap agentic planning tools target. AWS and Duke Energy are running agents inside Duke’s interconnection workflow, and Southwest Power Pool and Hitachi are building an AI tool for generator interconnection analysis. Here is what has been announced so far.

The AWS program, the pypowsybl-MCP architecture and the PNNL work describe broadly the same sequence. Each step leaves a record the next one can check.

The DC power-flow approximation simplifies an AC network by ignoring losses, treating every voltage magnitude as 1.0 per unit and assuming small angle differences. The result is a linear relationship between active-power injections and bus angles, which makes it fast enough to screen thousands of cases. “DC” here names the approximation. It has nothing to do with HVDC lines.

That speed makes DC power flow the standard tool for broad screening and distribution-factor work, such as estimating how much of a new injection flows over each line. It cannot tell you anything about voltage magnitude or reactive power. If a decision depends on either, the case has to go through AC analysis.

An AC power-flow calculation solves the full nonlinear active- and reactive-power balance equations, usually with Newton–Raphson, and returns voltage magnitudes, angles, reactive flows and losses. Converging is not the same as passing: MATPOWER’s documentation notes that a standard power-flow run does not enforce every generator, branch-flow or voltage limit, so limit checks are a separate step.

Optimal power flow, or OPF, adds an objective and decision variables. Power flow asks what electrical state follows from given conditions. OPF asks which settings of the modeled controls best satisfy an objective within the constraints. Its objective, permitted controls and acceptance checks belong next to its result.

A two-bus example shows the gap directly. Two buses are joined by a lossless line, with an 80 MW load at the receiving end and a fixed voltage at the sending end. The active-power transfer stays at 80 MW throughout. Only the load’s reactive demand changes.

At 40 MVAr of reactive demand, the AC solution puts the receiving bus at about 0.927 per unit, below a 0.95 per-unit lower voltage limit. Add 20 MVAr of reactive support at the receiving bus and the voltage rises to about 0.961 per unit. The active transfer is still 80 MW.

DC power flow returns the same 80 MW answer in both cases and has no voltage to report. An agent that stops at the DC screen would call the two configurations identical. Move the controls below to see where they diverge.

Contingency analysis is where agents change the size of the study a team can afford. Three demand cases, four dispatch patterns, 51 network states (the intact system plus 50 single outages) and three connection options make 3 × 4 × 51 × 3 = 1,836 power-flow solutions. Each needs consistent inputs, a convergence check, limit checks and a place in the final comparison.

An agent applies the same change across every case version, queues the runs, catches failed or incomplete solutions and compares results in the same units and against the same ratings. When a new rating, load forecast or project withdrawal arrives, it can identify the affected cases, rerun only those and report whether the conclusion changed.

The screening rule matters as much as the batch size. Contingency-analysis tools solve whichever outages you specify with whichever power-flow method you choose. If DC screening decides which cases get an AC run, that selection rule needs a justification and a check for missed problems. A voltage-sensitive outage should not drop out because its active-power flows look ordinary.

Here is the workflow on a network small enough to follow by hand. Cedar, Mesa and Ridge form a three-bus test network in Ask the Grid. Two case versions (summer and future) and two operating modes produce eight comparison rows: two candidate buses × two cases × two modes.

The agent first prepares an editable comparison draft naming the buses, the case files and the operating modes. The engineer reviews those inputs before anything runs. Preparing a study and executing it are separate actions with a review point between them.

The saved comparison requests 200 MW of generation or discharge and 150 MW of load or charging. In the summer case, Ridge’s generation screening limit is 110 MW and Mesa’s is 215 MW. The 200 MW request exceeds Ridge’s limit and fits within Mesa’s, and the result table shows that directly.

For Ridge’s summer generation row, the binding constraint is the Mesa–Ridge circuit under the loss of Cedar–Mesa. The evidence panel keeps the case version, source hash, normalized-model hash and calculation method attached to the number: lossless DC with linear distribution factors, Rate A ratings, three single-circuit outages and balancing against load in the same island.

Those settings define what the 110 MW means. It is an active-power screening limit under that method. Voltage performance and stability are the next studies, and the two-bus AC example above shows one way they can change the answer.

Download the inputs and results: summer case (RAWX), future case (RAWX) and the eight-row result export (CSV). The cases are released under CC0 1.0 and load in any tool that reads PSS®E RAWX.

Agents pay off where a team repeats structured work that still needs judgment between steps. The same flexibility creates failure modes a fixed script does not have.

A wrong case can still produce a convincing report. A changed slack assumption shifts flow patterns. A missed equipment-status field changes the topology. A well-formatted comparison can hide a scenario that never converged. The study record has to make each of those visible.

In Skill-Based AI Agents for Power-System Studies, PNNL’s Pavel Etingov and Shuchismita Biswas connect agents to PSS®E through an MCP server. The agents run power flow and dynamic simulation, extract results and carry out a play-in model-validation procedure. The architecture exposes defined engineering functions rather than asking a language model to calculate the network.

The authors describe it as an initial proof of concept rather than a statistical benchmark. Repeated runs were not evaluated systematically, and the compared setups used different foundation models. It shows that the procedures can be executed end to end, which is the necessary first result.

The RestoreBench preprint asks a narrower, measurable question: can agents restore power-flow convergence using a bounded set of controls? It compares chatbot, single-agent and multi-agent designs on two networks with 46 cases each. Tool-using agents generally beat the chatbot baseline, while extra multi-agent coordination does not consistently help and can raise cost.

Its success test is worth reading closely. Voltage magnitudes are excluded from the pass condition and reported separately, so “success” there means convergence, not acceptable voltage everywhere. Any agentic planning benchmark deserves the same check of what its passing condition includes.

Vendor material fills in the commercial picture. Siemens’ May 2026 announcement and a September Enlit interview make the case for agents around PSS®E. AWS reports task execution up to four times faster than manual analysis and up to 92% less engineer-active time. Those numbers use different denominators, and neither is the same as a shorter time to interconnection approval. An October 15 Utility Dive opinion piece by AWS’s Joseph Santamaria argues the broader case for AI in interconnection.

Start with a study your engineers can already reproduce. Freeze the case, permitted actions, monitored elements, limits and expected outputs. Include hard cases and known failures, not only the ones chosen for a demo.

Measure engineer-active time and elapsed time separately. Then check the result: did every intended scenario run, did each solve converge, were the limits checked, and does the report keep unresolved issues? A faster answer to a different or incomplete question is not an improvement.

The record should name the source case, every change, the solver and settings, numerical status, acceptance checks and reviewer decision, and keep any generated scripts needed to repeat the work. Every consequential sentence in the report should trace back to a run.

A converged power flow describes one operating point. Transmission planning also asks how the system behaves through faults and disturbances. NERC’s TPL-001-5.1 standard sets steady-state, stability and short-circuit requirements for planning assessments, and no single converged case satisfies it.

Agents can coordinate those studies too when the tools are exposed and the procedure is defined. The tool interface has to preserve model semantics, fault definitions and acceptance criteria. A successful API call means a command ran; the engineering result depends on the model and checks behind it.

The same boundary applies to interconnection. A screening result tells you which points of interconnection deserve a full study and how a project sits in the interconnection queue. The approved study still comes from the transmission provider’s process and its responsible engineers.

An agent chooses and coordinates actions. A neural solver learns a numerical mapping, or helps a numerical method converge faster. Our guide to neural power-grid solvers covers that second layer: candidate operating states, correction, verification and numerical fallback.

The two combine. An agent might call a conventional solver for one task and a qualified surrogate or warm-start method for another. The orchestration layer should record whether each result came from an approximation, a converged numerical solve or a verified optimization.

Public grid data plays a supporting role. Prices, mapped infrastructure, congestion and queue records help choose which scenarios to study, but they do not reconstruct a full planning model. Our guide to researching a site shows how those public records connect to the documents an analyst still needs.

Short answers to the questions planners and interconnection teams ask most often about agentic tools.