🚑 Dispatch — Real-Time Multi-Agent Disaster Response

Inspiration

When a natural disaster hits, information doesn't arrive in one place instead it comes in fragments. A tweet about rising floodwater. A satellite thermal anomaly over a city block. A 911 call about a nursing home that can't evacuate. There are too many urgent signals, too many decisions, and too little time for operators to act effectively. This lack of coordination and efficiency often results in many deaths that could have been prevented. We built Dispatch to solve this problem. We use a multi-agent system built on Google ADK that consists of four specialized agents that automatically gather data from social media, satellite imagery, and 911 transcripts, analyzes every incident and assigns a severity score, and acts by computing the most optimal path for each agent. Our system essentially ingests chaotic, multi-source disaster data into a single source and quickly routes vehicles without a single human decision. This efficiency leads to significantly less deaths and accidents.

What It Does

Dispatch is a real-time disaster response coordination system. When a city-wide emergency occurs, three independent AI agents process data from different sources: Social Media Agent — parses posts for location-tagged distress signals Satellite Agent — analyzes imagery detections for flood zones and thermal anomalies 911 Call Agent — transcribes and classifies emergency call reports Each agent scores incidents on a 0.0–1.0 severity scale. Once all incidents are collected, a route optimizer classifies them by type (fire, medical, general) and dispatches the nearest appropriate vehicle using real road routes from OSRM. Everything streams live to a React frontend via Server-Sent Events: incidents appear on the map one by one as agents finish. The routes of each aid vehicle can then be viewed by clicking on it. The vehicles are then dispatched once the dispatch button is clicked

How We Built It

The pipeline is built using Google ADK and it chains the three data agents so each one's output is available in session state before the next runs. The route optimizer then reads all aggregated incidents, groups them by type, uses a nearest-neighbor algorithm to assign vehicles, OSRM to assign real road routes from the public OSRM API for each route. The frontend consumes the SSE stream and progressively renders each incident and route as it arrives, allowing us to view updates in real time.

Challenges We Ran Into

The hardest problem we ran into was getting routes from the route agent to the frontend. The agent was computing all 9 routes correctly, which we could see in the logs, but they were never making it to the map. The issue turned out to be a fundamental limitation of using an agent as a transport layer for large structured data. Each route object contains hundreds of OSRM geometry coordinates, and when the model tried to return all of that in its text output, the JSON was either truncated or mangled, so our parser was unable to handle it. We spent hours debugging what looked like a parsing problem before realizing the real issue was architectural: the thousands of coordinate pairs in its response made the response too huge for the agent to return. The fix was to bypass the text output and store the computed routes directly in ADK session state from inside the tool, then read them out in the backend after the pipeline finished. The agent only needed to return a simple status confirmation. Once we made that change everything worked immediately.

Accomplishments We're Proud Of

• Built a working end-to-end multi-agent pipeline in under 24 hours that processes disaster data and produces road-following vehicle routes
• All incidents across three independent data sources are correctly aggregated and assigned to the appropriate vehicles
• Live SSE streaming allows us to watch incidents and routes appear in real time as each agent finishes Severity scoring is meaningful, not arbitrary (imminent life-threat incidents consistently surface at the top).

What We Learned

At the start of the hackathon we had never used Google ADK before so the process of learning how to set up a multi-agent pipeline from scratch was new. We learned how to use the Google ADK workflow method for chaining agents, and how to store the output of an agent into the session state using an output_key as well as using ToolContext to access the information stored in the session state and add it. We have never used OSRM either. We learned all of the proper formats for submitting coordinate strings to the routing API as well as how to handle the response geometry. We also learned how to handle real-world edge cases (like submitting duplicate coordinate values) which caused the GIS API to silently fail when it is invoked. We also learnt to incorporate retry logic with exponential back-off, which allowed us to make the external API calls to be resilient and mitigate the API failure from crashing the pipeline.

What's Next

• Real data ingestion — connect to live social media APIs, real satellite feeds, and integrate live 911 cals
• Dynamic re-routing — update vehicle routes as new incidents come in mid-dispatch
• Capacity constraints — implement vehicles limits
• Multi-city support — swap OSRM endpoints per region for nationwide coverage
• Dispatcher UI controls — let human operators override, reprioritize, or reassign routes

Built With

• fastapi
• google-adk
• leaflet.js
• osrm
• python
• react