Every control room in a modern utility runs on the same triad: a SCADA system that shows the current state of the grid, a set of forecasting and optimization models that predict what happens next, and a stack of compliance workflows that document what the operators did. The forecasting side got very good over the last decade. The documentation side is still, in most utilities, a person with a template and a deadline.
The gap between "the model predicted this" and "an operator acted on it and wrote up why" is where LLM copilots are showing up. Not as autonomous grid controllers — nobody sensible is dispatching megawatts through a chatbot in 2026 — but as the translation and drafting layer that sits between the model output and the human decision.
What a grid operations copilot actually is
A scoped LLM agent connected to the utility's data model with three responsibilities:
- Explain forecasts and telemetry in plain language. When the load forecast for the next four hours climbs 12% above baseline with a widening uncertainty band, an operator needs to know what changed, not just the number. The copilot reads the model inputs and produces a paragraph the operator can actually use.
- Answer operator questions over grid data. "What was the ramp rate on unit 3 during the last similar event?" is a question that used to require a query to a data engineer. Now it's a sentence.
- Draft dispatch instructions, event logs, and regulatory reports. The unglamorous documentation work that eats hours per shift and is the actual bottleneck between an event and the next scheduled task.
Camus Energy's framing of AI as a utility copilot frames the scope correctly: the copilot is not the optimizer. The optimizer is the optimizer. The copilot is the interpretation and communication layer that makes the optimizer's output usable to a human running the grid on a twelve-hour shift.
What the agent actually does
Concretely, in a mature control-room deployment:
- Contextualizes forecast changes. When the day-ahead load forecast updates, the copilot doesn't just show the new curve. It highlights the delta from the previous forecast, flags which input drove the change (temperature, DER production, event forecast), and notes which similar historical days had similar profiles.
- Answers ad-hoc questions over the data model. An operator asking "when did we last curtail wind by this much on a rising-load day" gets a summary of the three closest historical events, with links to the incident logs, in seconds instead of a batch request to the analytics team.
- Drafts dispatch communications. For events that trigger operator action — a unit trip, a transmission constraint, a DER aggregation request — the copilot drafts the market notice, the internal shift log, and the outbound customer communication in the utility's standard format. The operator reviews and sends.
- Sequences compliance reporting. Every meaningful event has a NERC or ISO-level filing attached to it. The copilot drafts the initial submission from the event data, flags which fields need operator confirmation, and holds a running log that becomes the first draft of the after-action report.
- Handles the shift handover. At the end of every shift, the copilot produces a summary of what happened, what's pending, and what the incoming operator should watch. The quality of this handover is the single most-cited operational win in early deployments.
A Codewave overview of generative AI in energy utilities catalogs the workflow patterns — forecast summarization, work-order drafting, technician-facing Q&A, customer-service augmentation. The grid-operations copilot is the control-room subset of that broader pattern, and it's the one where the return per operator hour saved is easiest to defend.
Why it beats the pre-copilot workflow
The pre-copilot workflow was optimized for stability, not throughput. During a real event, the operator was simultaneously making dispatch decisions, coordinating with plant staff, updating the ISO, logging actions for compliance, and answering questions from management. The documentation was always the thing that slipped.
Two effects show up in every serious deployment:
The first is that the documentation stops being a queue. The copilot writes as the event unfolds, so the operator's cognitive load stays with the actual decision-making. The compliance filing that used to take three hours the following morning becomes a fifteen-minute review before end of shift.
The second is that junior operators perform closer to senior ones during unusual events. The copilot surfaces historical context — similar events, prior decisions, past outcomes — that used to live only in the senior operator's memory. An OSTI/NREL preprint on AI for grid operations frames the near-term inflection: the LLM layer is not replacing physics-based tools, it's making the outputs of those tools accessible to a broader set of operators in real time.
Where this is being built
The market is fragmenting into three layers.
The utility software incumbents — GE Vernova, Hitachi Energy, Siemens — are shipping copilot layers on top of their existing EMS/DMS/OMS platforms. The advantage is native access to the utility's operational data model. The disadvantage is release cadence.
The grid-specialist AI startups — Camus Energy, AutoGrid, Utilidata, and a growing set of DER-management platforms — are shipping copilots that sit alongside the incumbent systems and integrate through APIs. The advantage is speed and product focus. The disadvantage is data plumbing.
The hyperscaler-plus-utility partnerships — where a utility builds its own copilot on top of an LLM platform, wired to its own historian and incident record — are producing some of the most interesting internal deployments. These don't ship as products, but they set the bar for what "good" looks like inside the industry.
As distributed energy resources become a bigger share of the mix, the copilot's job spans control-room grid operations and utility-facing customer aggregation, and the vendors who can span both surfaces are the ones getting the deepest deployments.
How to evaluate a solution
Ignore the demo. Every vendor can walk through a canned "operator asks a question, copilot answers beautifully" scenario. The tests that matter for a control-room deployment are unglamorous:
- What's actually in the retrieval context? If the copilot only reads the current alarm and public information, it will produce generic answers. If it reads the state estimator, the historian, the incident log, and the market notices, that's when it becomes useful. Ask for the concrete list.
- How does it show its reasoning? For every recommendation or draft, the operator needs to see which data points fed it. A control-room copilot without a traceable citation trail is unusable for anything the compliance team will look at afterward.
- Where does drafting stop and human action begin? For dispatch and market communications, the boundary between "propose" and "send" has to be explicit. Ask specifically what the copilot can send without a human, and how that boundary is configured per event type.
- How is the false-summary rate measured? Ask the vendor how often the copilot's summary contradicts the underlying telemetry. If they don't measure it, that's the answer.
- What's the data lineage story for regulator-facing output? If a NERC or ISO filing draft is going to lean on copilot output, the compliance team needs a clear answer to "where did this sentence come from."
The utilities getting real value from grid-operations copilots in 2026 are treating them as a documentation and translation layer over the existing operational stack, not a replacement for it. The value is in the shift log, the market notice, the after-action report, and the answer to the question the operator would have asked a senior colleague. That was the part of the job that was actually eating the shift.