GridShift

GridShift is an AI energy copilot that forecasts building peaks, coordinates batteries, EV charging and HVAC, and gives facility teams a clear plan to approve before action.

Comment

Inspiration

Commercial buildings can pay a significant portion of their electricity bill because of a small number of high-demand periods.

The problem is not simply that buildings use too much energy. The problem is that the information needed to respond — load forecasts, weather, electricity rates, battery state, EV charging needs, HVAC constraints, and operator priorities — often lives in different places.

By the time a peak is obvious, it may already be too late to react.

We built GridShift around a simple idea:

What if a facility team could see the peak coming, understand what flexibility is available, and approve a coordinated response before the peak arrives?

We also wanted to avoid a fully autonomous "black box." Building operators should stay in control of decisions that affect equipment, comfort, and operations.

What it does

GridShift is an AI-assisted energy decision system for commercial buildings.

It:

  1. Forecasts the building's upcoming electricity demand.
  2. Detects when demand is likely to cross a peak threshold.
  3. Lets an AI agent investigate the situation using building, tariff, weather, and device information.
  4. Coordinates flexible resources such as:
    • batteries,
    • EV charging,
    • HVAC.
  5. Generates an optimized action plan.
  6. Explains the recommendation to the facility manager.
  7. Requires human approval before any action is accepted.

Instead of only showing an energy dashboard, GridShift answers:

"A peak is coming. What can we safely move, when should we move it, and why?"

The dashboard lets users compare the original demand curve with the optimized plan, inspect individual device actions, review the agent's reasoning process, and approve or reject recommendations.

How we built it

We built GridShift as an end-to-end system connecting energy data, forecasting, optimization, an AI agent, and a visual dashboard.

For the building-energy foundation, we used a medium-office profile from NREL ComStock together with historical NOAA weather observations.

A forecasting model estimates future building demand and identifies potential peak periods.

When a peak is detected, a Gemini-powered agent gathers the relevant context rather than immediately making a decision. It examines information such as the forecast, tariff, battery state, EV requirements, and HVAC operating limits.

The problem is then passed to an OR-Tools optimization model, which determines how flexible loads can be shifted while respecting operating constraints.

The result is presented through a Next.js dashboard, where the facility manager can see:

  • expected demand,
  • peak risk,
  • the optimized demand curve,
  • battery / EV / HVAC actions,
  • the expected impact,
  • and the approval request.

The backend is built with FastAPI and Python, with PostgreSQL / Supabase supporting the building and historical data layer.

Challenges we ran into

One of our biggest challenges was making all parts of the system agree on the same operating picture.

The forecast, optimizer, AI agent, and dashboard all needed to reason about the same building, the same day, the same peak, and the same device constraints.

We also learned that reducing a peak is not as simple as "move electricity to a cheaper hour."

Sometimes reducing the demand peak means shifting energy into a more expensive time period. That creates a real trade-off between energy cost and demand charges.

Instead of hiding that trade-off, GridShift surfaces it to the operator.

Another challenge was keeping the system understandable. An optimization model can produce a mathematically valid answer, but a facility manager still needs to know:

  • What is changing?
  • Why is it changing?
  • What constraint is being respected?
  • What benefit should I expect?

That is why the human-approval workflow became a core part of the product rather than an extra feature.

Accomplishments that we're proud of

We built a working end-to-end flow:

forecast → detect → investigate → optimize → explain → approve

For our office demonstration, GridShift reduced the modeled peak from approximately:

522 kW → 385 kW

a reduction of about 137 kW, while still respecting the modeled operating constraints.

We are also proud that the product does not simply display an optimized number.

The dashboard shows the facility manager what the agent investigated, what devices are being used, how the demand curve changes, and what decision requires approval.

We also built the system so the same decision workflow can be demonstrated across different building profiles, including office, healthcare, warehouse, and residential scenarios.

What we learned

The biggest lesson was that peak management is fundamentally a coordination problem.

Forecasting alone is not enough.

Optimization alone is not enough.

An AI agent alone is not enough.

The useful product emerges when all three work together:

Prediction tells us what may happen.

Optimization tells us what is possible.

The agent helps translate that into a decision a human can understand.

We also learned that AI is most useful here as a decision-support layer rather than an unrestricted controller.

For high-impact physical systems, trust comes from making constraints and recommendations visible and keeping humans in the loop.

What's next for GridShift

The next step is to move from a hackathon building model toward real operational deployments.

That would include:

  • live smart-meter and building-management-system data,
  • real battery and EV charger telemetry,
  • live utility tariffs,
  • additional building types,
  • portfolio-level coordination across multiple sites,
  • continuous forecast retraining,
  • historical performance analytics,
  • and integrations with building-control systems.

The long-term vision is for GridShift to become an energy copilot for facility teams:

continuously watching demand, identifying flexibility, proposing the best response, and letting the human make the final call.

Built With

Share this project:

Updates

Submission history