I wrote this post to document how I built Keystone, my submission to the All Things Agentic Hackathon (Google Gemini + Google Cloud), for the Fortified Enterprise Fleet track.
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.
The part everyone else skips: proving 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. Most wildfire-AI products stop right there.
Keystone doesn't. 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, and this is 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.
A grid 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.
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.
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
Keystone is live: a fully deployed, autonomously scheduled fleet, not a local demo. It re-verifies real transmission assets, ranks real risk, and, with an engineer's explicit word, coordinates real cross-organization response, all running on a real 15-minute cadence whether or not anyone's watching.
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.
