Powerbeat Guardian

• 

  A1

Inspiration

Solar-aware EV charging can hover near an operating threshold when generation and household demand fluctuate. The charger may repeatedly start and stop even though every individual decision appears reasonable. That churn is difficult for an owner to diagnose because the evidence is spread across current Power flows, forecasts, event history, and automation settings.

We wanted to test whether a narrowly scoped agent could investigate that evidence autonomously, explain a concrete correction, and stop at a deliberate human approval boundary.

What it does

Powerbeat Guardian demonstrates one fixed, reproducible workflow using synthetic data:

1. A site reports three EV charging transitions within twenty minutes.
2. The browser injects a charging_churn_detected event.
3. Cloud Run publishes the event to Pub/Sub and immediately returns 202.
4. Pub/Sub invokes an authenticated worker.
5. Gemini uses an allowlist of typed tools to read the site snapshot, short forecast, recent charging events, and active rule.
6. After collecting the required evidence, Guardian proposes increasing rule persistence from 300 to 600 seconds and creates an owner notification.
7. The interface displays structured tool activity and the exact before-and-after rule diff.
8. Human approval revalidates the expected rule revision and safe bounds before applying revision 2 and writing an audit record.

The autonomous task ends with a supported proposal and notification. Guardian never sends a device command.

How it works

The browser-facing API persists an idempotent run and publishes a compact event to the guardian-events Pub/Sub topic. Pub/Sub pushes the event to the same Cloud Run service at /internal/pubsub. Production code verifies both the OIDC audience and the exact push service-account email before claiming the run.

Gemini receives six typed functions through the official @google/genai SDK:

• read_site_snapshot
• read_short_forecast
• list_recent_charging_events
• get_active_rule
• create_rule_change_proposal
• notify_owner

The model can select tool calls only from that allowlist. Deterministic code requires all four reads, checks the live rule revision, restricts the fixed demo proposal to 600 seconds, and requires owner approval. Gemini cannot access Firestore directly.

How we built it

Powerbeat Guardian is a standalone TypeScript and Bun application packaged in a multi-stage Docker image for Cloud Run. Fastify serves the responsive interface and API. Pub/Sub provides asynchronous at-least-once delivery, Firestore transactions persist the single synthetic scenario and audit history, and Secret Manager supplies the judge passcode and session secret.

The live model path uses Vertex AI, the official @google/genai SDK, requested model gemini-3.5-flash, and resolved model revision gemini-3.5-flash. The application stores structured tool activity rather than raw prompts or hidden chain-of-thought.

Data sources

The demonstration uses a deterministic, fully synthetic dataset created for this project. It contains a site Power snapshot, a one-hour solar forecast, three charging transitions, and one automation rule. It contains no customer data, device credentials, vendor data, or production Powerbeat telemetry.

Safety and control boundaries

• one active run at a time
• 30 new runs per UTC day
• eight tool calls per run
• 90-second application timeout
• idempotent event enqueue and claim
• four required evidence reads
• proposal values bounded from 300 through 1800 seconds
• one fixed 600-second mitigation for the reproducible scenario
• base-revision checks at proposal creation and approval
• human approval before rule mutation
• visible persisted failure outcomes
• no direct device tool
• no raw prompt or hidden reasoning persistence

Challenges

The central challenge was preserving meaningful autonomy without delegating unsafe control. Gemini is allowed to choose and execute an investigation through typed tools, but deterministic policy code controls the write boundary.

Asynchronous delivery also required explicit idempotency because Pub/Sub may deliver a message more than once. Proposal approval required revision revalidation so a recommendation based on revision 1 cannot silently overwrite newer state. Finally, the demo needed to be transparent without exposing raw prompts or private reasoning, so the UI presents only structured tool activity and persisted outcomes.

Accomplishments

Publication gate: include the following only after all live acceptance checks pass.

We built and deployed a complete event-driven workflow in which one browser action produces an authenticated Pub/Sub delivery, a live Gemini investigation, a bounded proposal, an owner notification, and a revision-safe approval record. The deterministic scenario can be reset and repeated, duplicate delivery is idempotent, and failures remain visible as persisted run outcomes.

The result is intentionally narrow, but every visible model step in the submitted run corresponds to the frozen Google Cloud deployment rather than seeded output.

What we learned

A useful safety boundary does not make an agent less autonomous. In this workflow, the agent independently completes the difficult work of gathering evidence, diagnosing the problem, selecting a bounded correction, and notifying the owner. Human approval is the designed terminal action because changing an energy-control rule has consequences beyond the model's context.

Typed tools also produced better observability than free-form chat. A judge can see what data was requested, what proposal was persisted, and which policy checks ran without exposing hidden reasoning. Revision checks proved just as important as value bounds because even a safe value can become unsafe to apply when the underlying state has changed.

What is next

Future work could add more synthetic fault scenarios, offline evaluation of proposal quality, richer operational monitoring, and carefully permissioned integrations with real telemetry. Direct device control is intentionally outside this submission and would require a separate safety and approval design.

Pre-existing-work disclosure

Powerbeat's name, visual identity, broader product concept, and energy-domain experience existed before the competition period.

Powerbeat Guardian is a separate contest project. Its source code, synthetic dataset, Google Gen AI SDK integration, Google Cloud deployment configuration, architecture diagram, demonstration video, and submission materials were created during the competition period.

No source code from Powerbeat's pre-existing Agent runtime was copied into this repository. The project uses only the pre-existing Powerbeat identity and general energy-domain knowledge, with authorization.

The demonstration uses 100 percent synthetic data. It contains no customer telemetry, production credentials, vendor credentials, or physical device state.

Built With

• gemini-3.5-flash