Firestore and google cloud run- completed successful run.
WFAD UI communication chat between user and agent.
GOOGLE Cloud Run doing its thing.
Firestore first run Complete
The WFAD Workflow with the Google products used at each step.

Inspiration- Weather does not wait for a prompt. Broadcast weather still does.

I am a meteorologist in Western New York. The job on a busy desk is still a race against the clock. Someone has to pull the National Weather Service data, write the briefing, decide who needs it, and send it. That loop is slow when the weather is not. Severe summer storms have been showing up more often in places I have lived my whole life. Winter still belongs to lake-effect. Either way, the public is waiting on a human voice, and that voice is often one person doing four steps by hand. I already built Doc Weather AI at whatsupdoc.fyi as a hub for forecasts, maps, and research. Twenty-plus feeds. (NWS. NASA. G maps, Openweather, AWN, Weatherunderground, USGS, to name a few). How we built it It did not solve the first problem on a broadcast shift: getting a usable alert to the meteorologist before everyone else has the same information. That is why WFAD exists. I wanted an agent that watches conditions, writes the hit, and taps the desk first. Not to replace the meteorologist. To give them a head start.

What it does- WFAD is Watch, Forecast, Alert, Disseminate. One root agent. One pass. No babysitting.

A trigger fires from Pub/Sub, Cloud Scheduler, or a POST to Cloud Run. The agent watches National Weather Service data for a location. It writes a briefing a desk can actually read. It scores urgency as ROUTINE, MODERATE, HIGH, or CRITICAL. It routes the package and writes a receipt. Today that package lands as email. The meteorologist validates. Then they go. Doc stays the hub. Leesa stays the social liaison. Neither of those is this app. WFAD is the early-warning assistant that gets there first. Live proof is Rochester, NY. A scheduled briefing runs on Cloud Run, watch_conditions succeeds in the ADK UI, and Firestore shows the run in collection wfad_runs.

How we built it

Four boxes. Trigger. Pub/Sub topic wfad-triggers, Cloud Scheduler job wfad-scheduled-briefing, or HTTP POST /trigger with a location and a reason. Root agent. Google Agent Development Kit. Gemini 3.5 Flash. Cloud Run at https://wfad-agent-kbahexw6ca-uc.a.run.app. Vertex in deploy so the console is real. AI Studio key as local fallback. Tools. Watch is a thin NWS client adapted from Doc. Forecast formats an on-air script and a social blurb. Alert applies a deterministic rule table for severity and recipients. Disseminate writes Firestore and sends one outbound channel. Output. Firestore database wfad, collection wfad_runs, plus one email when SMTP is set. The repo is public at https://github.com/Scrum723/WFAD. Architecture is one agent and four tools, not a five-agent fleet.

Challenges we ran into- The hard part was not the model. The hard part was keeping the agent honest.

Watch had to stay grounded in api.weather.gov. Points, active alerts, latest station observation, four forecast periods. No invented radar. No pretty lie. Alert could not be vibes. Severity is a rule table so ROUTINE does not become CRITICAL because the prose got dramatic. Disseminate had to prove a real send without pretending Doc or Leesa were this submission. Judges score the video, the repo, the write-up, and Google Cloud proof. Stills live in the demo folder. They are not the entry. Local machines did not have gcloud. Secrets had to live in two env files. Vertex had to be the deploy path so the video shows a Cloud console, not a laptop demo. The other challenge is time. Severe weather does not care about a hackathon clock. The product had to be a finished loop, not a mockup of one.

Accomplishments that we're proud of- The loop actually runs.

A Rochester scheduled briefing writes a live Firestore document. The ADK UI shows watch_conditions succeeding with a .run.app address in the bar. Cloud Run is up. Pub/Sub topic wfad-triggers exists. One real outbound email already landed with subject WFAD ROUTINE, Rochester, NY. That is the Taskmaster bet. Not a chatbot that talks about weather. An agent that finishes the chore a human used to drive by hand. We also kept the boundary clean. Doc is the hub. Leesa is a tool. WFAD is the briefing agent. The architecture diagram says that out loud so nobody has to guess.

What we learned- An agent that takes action needs receipts. Firestore wfad_runs is not decoration. It is how you prove the run happened when the video is over.

Gemini 3.5 Flash is enough to orchestrate this loop if the tools are thin and the rules are deterministic. The model should route and write. It should not invent the atmosphere. Google ADK plus Cloud Run plus Pub/Sub is the right shape for a desk that cannot sit in a chat window all shift. Event in. Package out. Scale to zero after you have the recording. Most of all: the meteorologist still has to validate. The win is minutes, not autonomy theater.

What's next for WFAD- Watch, Forecast, Alert, Disseminate

Keep the submitted repo, video, and .run.app frozen through judging. After August 31 at 5:00 p.m. PT, new work goes on a fork. Next on the product: richer outbound channels, phone and desk chime, tighter coupling to Doc for the verify step, then a dissemination package with custom graphics and short-form video as our own IP. Watch can grow past a thin NWS client without dragging twenty APIs into this agent. Alert can learn desk preferences without giving up the rule table. The job stays the same. Get there first. Hand a human a briefing they can trust. Let them take the story.