Inspiration

Once we got a $170 electric bill for a small apartment and couldn't explain it. A few appliances running at the same time had quietly pushed it up. Restaurants live with the same problem at a much bigger scale. On commercial tariffs, the single busiest 15 minutes of the month sets a demand charge, so one lunch rush where the oven, dishwasher, ice machine and AC all run together can cost more than the rest of the day. Owners only find out weeks later on a bill.

What it does

WattWise keeps a restaurant's power peak under the owner's cap without stopping service. Every appliance reports to one hub. Our engine bills the kitchen exactly like the utility, forecasts the next two hours, and quietly shifts flexible loads: it delays the dishwasher, makes ice earlier, or trims the HVAC for a few minutes, always inside the owner's rules. When no safe move is left, Claude weighs the engine's options with live weather, price and event context and picks one within the authority the owner gave it. Anything beyond that goes to the owner. Owners run everything from a chat in ASI:One, and everyone watching sees the same live kitchen in two lanes: without WattWise and with it.

How we built it

  • Engine (Python): a meter, forecaster and decision logic that compute every kW, kWh and dollar. The AI never produces a number.
  • Simulation and hardware: a browser kitchen of appliances and customers reporting through an ESP32 style hub, plus a real ESP32 simulating appliance control with Convex.
  • Fetch.ai: four agents on Agentverse. Weather, Grid (live CAISO prices) and Events agents gather context, and the Concierge talks to the owner in ASI:One over the Agent Chat Protocol, with Interactive Cards and a Payment Protocol plan in Stripe test mode.
  • Claude: explains every decision, answers questions, and resolves escalations by choosing one option the engine already evaluated.
  • Platform: SpacetimeDB for the shared live kitchen, Convex for records and the hardware bridge, FastAPI running the clock, a React frontend.

Challenges we ran into

  • Letting Claude make real judgment calls without ever inventing a number or acting outside the owner's limits.
  • Time at 120x speed: a slow AI call costs simulated minutes, so the engine escalates early and always keeps a safe default.
  • Three people building in parallel: we wrote contracts and shared fake data first, so nobody waited on anybody.
  • Getting our agents discovered and answering inside ASI:One, and keeping an alpha ESP32 library stable on venue WiFi.

Accomplishments that we're proud of

  • A complete loop from an owner's chat message to a physical device switching.
  • Agents that do real work together, not a chatbot wrapper.
  • Hard safety rules: always on equipment is never touched, refrigeration never drops below its food safety floor, and energy is moved, never deleted.
  • Every number on screen comes from tested code and is honestly labeled simulated, measured or recorded.

What we learned

  • How much of a commercial electricity bill one 15 minute window can decide.
  • AI is strongest at judgment and conversation, and the arithmetic belongs in tested code.
  • How to combine agent networks, real time databases and embedded hardware in one weekend.

What's next for WattWise

  • Real kitchens, with off the shelf smart relays in place of the simulated hub.
  • Real utility tariffs from the OpenEI rate database, and backtests on each restaurant's own meter data.
  • A pilot with a few independent restaurants in the Bay Area.

Built With

  • agentverse
  • arduino
  • asi:one
  • azure
  • azure-container-apps
  • azure-static-web-apps
  • caiso
  • claude
  • convex
  • esp32
  • fastapi
  • fetch.ai
  • nrel
  • open-meteo
  • platformio
  • pydantic
  • pytest
  • python
  • react
  • spacetimedb
  • stripe
  • tailwind-css
  • typescript
  • uagents
  • vite
Share this project:

Updates

Submission history