grid map
City grid
process of reducing consumption

Inspiration

The scale of data centers keeps growing every year; along with them, so does the power they consume. That power comes from the same grid everyone else relies on. Winter Storm Fern left over a million people losing power. The federal plan for the data centers then was to move the data centers onto backup diesel generators totaling 35GW. While this was happening, the grid operators started to require flexibility from the data centers.

Why does this matter

Regulators are starting to require data centers to cut power on command; Texas now mandates it for some data centers, and the eastern U.S. grid operator puts new ones first in line to be cut. Researchers estimate flexible data centers could trim 10 to 30% of their peak use. But there is no tool that makes the decision on which work to cut, asks people who own it, and proves the power dropped.

What it does

Griddy helps AI data centers use less power during grid emergencies by pausing the work that can wait and keeping the work that can’t. Griddy keeps an eye on the power grid and plans. Important work, a chatbot people are using, keeps running. Work that can wait, training an AI model, gets moved to later. When the power company asks the data center to use less power, Griddy cuts back right away. If that would make a job late, Griddy asks the person in charge of that job first. Then it measures the power to prove the cut really happened. In our tests, Griddy cut power by over 90% within 7 seconds.

How we built it

We built Griddy in Python. It pulls live grid data from the California and Texas grid operators, and plans the day with Google's OR-Tools. On the MacBook, Griddy controls a chatbot, AI model training, and processing a large batch of documents. Power is measured by the Mac's built-in power meter, not by our code. The AI assistant runs on Microsoft's Agent Framework and Azure AI Foundry, and can also run on Claude. Every AI decision is logged so it can be reviewed later.

Built for the Microsoft Challenge

We built Griddy for the real world. Power companies send their requests in plain words or in OpenADR, the industry standard, and Griddy reads both. The person who owns a job answers on their phone, in their own words. To show it is useful, we measured it: we sent the same request three times. Ignoring it stayed under the limit 0% of the time. Pausing everything stayed under 99% of the time but stopped all the work. Griddy stayed under 93% of the time and kept the training running. We designed it responsibly from the start: the planner decides, the AI only explains and talks to people, and a person approves anything risky. We reviewed Griddy with Microsoft's own Responsible AI and architecture reviewers (HVE Core) and fixed everything they found. The AI runs on Microsoft Agent Framework with Azure AI Foundry, signs in with Entra ID so no key is stored, and passed 137 of our 138 tests there. A one-page map from each judging point, and each of Microsoft's six Responsible AI principles, to the code is in docs/microsoft.md.

Built for Fetch.ai

https://youtu.be/k_RBe9xHOlo

Challenges we ran into

Our first test with the chatbot running failed. The power never dropped low enough because one chat reply used most of the computer's graphics chip. We fixed it by measuring more carefully and letting a human decide when to slow chat down. We also found our AI had quietly stopped working because of one bad setting, and only caught it by testing live. Additionally, our own test runs were throwing off the power readings, so now nothing else runs while we measure.

Accomplishments that we're proud of

The whole system works end to end on real hardware, from live grid data to a plan, real action, and measured proof. Griddy got under the power limit within 7 seconds. Compared with pausing everything, it got about 83 times more work done while still staying under the limit most of the time. A person's "no" always counts, and the AI can't override it. Griddy also blocked every prompt-injection attack we tested, and every measured number we report can be rechecked from the raw logs.

What we learned

We learned to measure before making promises. Our early assumptions about speed and power use turned out to be wrong, and real measurements showed us what was actually happening. We also learned to use AI only where it adds value. Wherever a simple rule could do the job, we used the rule instead, which made Griddy both safer and faster. Finally, we learned the value of being honest about scope. Griddy runs on a single laptop today, but the same approach is designed to scale to a full data center.

What's next for Griddy

Next, we want to bring Griddy closer to real-world use. Job owners will be able to approve requests directly in Microsoft Teams, where they already work. We plan to connect Griddy to a real utility using the industry-standard OpenADR protocol, so requests arrive automatically instead of being typed in. Finally, we want to run Griddy on a real data center’s GPUs, where it can manage power at full scale.