I built this Project for the Fortified Enterprise Fleet + Collaborative Partner track of the All Things Agentic Hackathon (Google Gemini + Google Cloud) — allthingsagentichackathon.devpost.com.

A worn hook on a single transmission tower on PG&E's Caribou-Palermo 115kV line. Nobody was looking at it on the morning of November 8, 2018. Eighty-five people didn't survive the fire it started.

That's not a hypothetical I picked for a pitch deck. It's the real corridor my project watches, because it's the clearest answer to the question every wildfire-tech product seems to dodge: why didn't anyone catch this in time?

The honest answer is that utilities inspect thousands of miles of line on an annual, sampled, human-eye cycle. A developing failure doesn't wait for its turn. It shows up in one photo out of the 99.99% nobody has time to review, or in one sensor reading buried in a stream nobody is watching live. The gap between when a failure starts and when a human notices is measured in years.

So I built Keystone: a fleet of AI agents that watches a transmission grid continuously, and — this took most of the work — refuses to raise an alarm it can't independently prove.

Why this had to be a fleet, not one model

A single model looking at a single image can flag an anomaly. It can't independently re-derive the physics behind that anomaly, argue against its own conclusion, rank the consequence across an entire network, negotiate a real response with three other organizations, and still leave the final high-stakes call to a human — all without one failure anywhere silently becoming everyone's problem.

That's a coordination problem as much as a detection problem, which is why Keystone is built as real ADK2 Workflow graphs with routed edges on the model's own output, not a single agent with a long prompt. Each stage is independently deployable, independently identity-scoped, and talks to the next one only through typed contracts and real data stores — never by reaching into another stage's internals. When a risk needs a response beyond Keystone's own authority, that same discipline extends outward over the real Agent2Agent protocol to other organizations' agents, not a webhook pretending to be one.

What Keystone Does

• Watches continuously, not on a schedule a human remembers to run. Satellite imagery and telemetry are triaged cheaply first, then only the tiles and readings actually worth a closer look get a real vision and interpretation pass.
• Fuses signals into one specific hypothesis — grounded in the asset's own history, not a generic anomaly score, and honest about what it doesn't yet know.
• Independently re-derives every finding with real engineering physics before it's allowed to escalate, then has a second agent argue against that result on purpose.
• Ranks consequence across the whole network, not just severity at one point, using an actual graph digital-twin of the corridor.
• Acts autonomously on the routine 99% — opening a governed work order or scheduling re-inspection — and stops being autonomous entirely for the rare high-stakes 1%.
• Turns the rare case into a guided conversation, not a raw alert — a real spoken session with an engineer, grounded only in that exact case, that re-runs the physics live when they question an assumption.
• Lets an engineer attach a photo of the actual asset and ask about it — a real vision call grounded in both the image and the case's own evidence, not a caption.
• Hands a confirmed risk to three outside organizations at once, live, and waits on one of them for real veto power before treating anything as cleared.
• Turns a fixed budget into a specific spending plan — an exact optimization over real risk scores and real public cost data, not a rule of thumb.
• Answers plain-language questions against its own live data, generating and running the actual query rather than returning a canned response.
• Keeps working with zero signal — a fully offline mode for a field engineer standing at the base of a tower with no connection at all.
• Improves its own instructions under supervision — proposes a rewrite when its behavior scores poorly against real test cases, and never applies one without a human approving it first.

The trust layer: proving it, not just flagging it

Point a vision model at satellite imagery and you'll get flagged anomalies. That's the easy part. The hard part — the part that actually earns an operator's trust — is what happens after the flag.

Every finding gets independently re-derived with real engineering physics: the actual IEEE-738 steady-state thermal model (the real heat-balance equation, convective and radiative loss against solar gain and resistive heating, solved numerically), a sag-vs-temperature model, and voltage-class clearance thresholds. Then — the piece I'm proudest of — an adversarial critique agent actively argues against that numeric result. Could it be a sensor artifact? A shadow? A condition the operator already reviewed and accepted? Only after surviving that argument does a finding get to call itself confirmed.

An operator who's been cried-wolf three times stops looking at the fourth alert. The fourth one is usually the real fire. So Keystone is built to be right first, and fast second.

The architecture

One root agent, backed by specialists that each own exactly one job:

• Controller → the only agent with tools; decides which real workflow to run and reads the actual results before deciding what runs next.
• Perception (imagery + telemetry) → cheap triage first, real detection only on what earns it.
• Diagnosis → fuses correlated findings into one grounded hypothesis.
• Physics Verification → independent numeric re-derivation, then adversarial critique.
• Network Risk → graph-topology consequence ranking across the whole corridor.
• Dispatch → the governed action layer — autonomy threshold, idempotent writes, a second independent policy check before anything actually happens.
• Deliberation → the human conversation layer — guided case, live what-if, photo Q&A, live voice.
• Mutual Aid → three real, independently-deployed peer agents over the real Agent2Agent protocol.
• Capital Planning → the budget-to-action optimizer.
• Self-Evolving loop → host → judge → router → proposer, human-approved only.

From "here's a risk" to "here's who's helping, right now"

The part of this build that turned it from a monitoring dashboard into something genuinely autonomous is what happens after a risk gets confirmed.

When a field engineer confirms a wildfire-risk situation, Keystone doesn't just log it. It hands the situation off, live, to three peer organizations over the real Agent2Agent (A2A) protocol: a mutual-aid utility that can commit line crews, a fire agency that can pre-position an engine, and a grid balancing authority that can approve, or block, the de-energization itself. Each of these is a genuine, independently-deployed AI agent with its own real Agent Card, discoverable the way any standards-compliant A2A agent is. All three calls run concurrently, and you watch each one go from pending to sent to responded live on screen, with real elapsed time, not a canned demo sequence.

The balancing authority's answer has real teeth. If it doesn't approve, Keystone shows an actual blocking warning, on the request and on the live map, and refuses to treat the situation as cleared. That's a different organization's AI agent changing what your system will let a human do. I haven't seen that demonstrated in many places outside a protocol spec.

Turning a risk ranking into a real budget decision

Utilities' own wildfire mitigation plans, filed with regulators, are largely reactive: fixed multi-year mileage targets, not a risk-optimized annual plan. Nobody's asking "given this year's actual budget, which specific miles buy down the most real risk?"

So I built that question into Keystone directly. Drag a real budget slider, and an exact 0/1 knapsack solver — dynamic programming, not a greedy approximation — picks which specific line assets to fund this year, and with which intervention (undergrounding, covered conductor, or vegetation management), to maximize total risk reduction. Every input is real: each asset's length comes from its own OpenStreetMap geometry, its risk score comes from a live network-risk ranking, and the per-mile costs and risk-reduction percentages are pulled straight from public utility filings. PG&E's own reported $3.1M/mile undergrounding cost and roughly 98% ignition-risk-elimination claim. SCE's own $430K/mile covered-conductor figure and the 65% risk-reduction number cited consistently across CPUC filings.

Deployment, and staying deployed

None of this is a local demo running on my own machine. The frontend and API are independently deployed Cloud Run services; the Controller runs on a real Vertex AI Agent Engine; a GKE Autopilot cluster sits at zero cost until a live fire hotspot bursts it into action for one specific asset. A real Cloud Build pipeline runs on every push to main: a secret scan, the full test suite, and a blocking quality gate that re-grades the fleet's own live instructions against real test cases before either service redeploys. The scheduled pipeline runs itself, unattended, on a real cadence — the fleet is watching whether or not anyone's looking at the dashboard right now.

What I learned building on the edge of a fast-moving stack

Almost every hard bug in this build showed up the moment something ran under its real, least-privileged identity instead of broad developer credentials. A scheduled job hit a real 403 because reading a table and running a query job turn out to need different IAM roles. A dispatch agent's brand-new Vertex AI session call needed a role nothing had ever granted it. Each one only showed up in production, under real constraints, and each one is now a permanent, documented fix.

Model discovery was its own kind of archaeology. The working model IDs for real-time voice, video generation, and music generation weren't the names you'd guess from naming conventions. Every plausible guess 404'd, and the real ID only turned up by checking the live model catalog directly, often in a different cloud region than everything else in the project.

The hardest bug of all had nothing to do with the cloud, though. Running an offline, on-device model for field engineers with no signal hit a hard memory-allocation ceiling on a real laptop with an integrated GPU. I confirmed via Task Manager it wasn't resource pressure, it was a genuine engine limit. The fix wasn't a bigger buffer. It was never allocating one large buffer in the first place.

Try it

Hackathon: All Things Agentic Hackathon (Google Gemini + Google Cloud) — allthingsagentichackathon.devpost.com

Built with: Google ADK (incl. ADK2 Workflow) · Gemini + Gemini Live + Veo + Lyria · on-device Gemma · Agent2Agent protocol · Model Context Protocol · Cloud Run · GKE Autopilot · BigQuery · Firestore · Cloud SQL · Vertex AI Agent Engine · Model Armor

Keystone has not been reviewed by a licensed power systems engineer. Transmission asset geometry, weather, and imagery are real public data; no public live SCADA feed exists for the demo corridor, so conductor telemetry is synthetic — driven by real weather through a documented, not random, heat-balance approximation.

I built it because the gap between "a developing failure" and "someone actually noticing" shouldn't be measured in years. It should be measured in the time it takes an agent to check its own work.

AllThingsAgenticHackathon