ResilienceOS — From Early Warning to Early Action
Inspiration
Disaster-response systems are very good at answering one important question:
“Is something dangerous about to happen?”
But while researching existing resilience projects, we became interested in the question that comes immediately after:
“Now that we know, what should happen next?”
One project that strongly influenced our thinking was Acuífero·Vigía, the Global Resilience Prize winner from Google's Gemma 4 Good challenge. Its approach to flood resilience stood out to us because it treated connectivity failure as part of the problem rather than an edge case. Local observations, citizen reports, multimodal AI, and fallback logic were designed around the reality that infrastructure itself may fail during a disaster.
That led us to a broader problem.
A flood warning does not automatically coordinate an evacuation.
Someone still has to verify conflicting reports, determine which areas are at risk, check whether roads remain usable, identify available shelters, allocate limited resources, communicate with different groups, and continuously revise the plan as conditions change.
Those activities are distributed across people, agencies, dashboards, phone calls, spreadsheets, and separate information systems.
We wanted to explore whether an agentic system could help connect those pieces.
That became ResilienceOS.
ResilienceOS is an autonomous incident-coordination layer designed to turn early warnings into early action.
What it does
ResilienceOS takes incoming disaster signals and maintains a continuously evolving incident state.
Instead of stopping at:
detect → alert
our workflow is:
SENSE → UNDERSTAND → VERIFY → PLAN → DELEGATE → ACT → MONITOR → REPLAN
For our prototype, we focus on a flood scenario.
The system can receive evidence such as:
- water-level telemetry
- weather information
- river or street imagery
- citizen voice/text reports
- road status
- shelter and resource availability
Gemini converts this heterogeneous information into structured incident evidence.
From there, specialized agents collaborate around a shared incident state.
Sentinel Agent
The Sentinel watches incoming events and identifies signals that may represent an emerging threat.
Its job is not to independently declare an emergency. It creates an initial risk assessment and passes the evidence forward.
Verification Agent
Emergency information is often incomplete or contradictory.
A citizen may report that a road is flooded while an older map still lists it as open. A sensor may report rapidly rising water while another source appears stable.
The Verification Agent correlates independent sources and records:
- supporting evidence
- conflicting evidence
- confidence
- freshness of information
- source provenance
This prevents the rest of the system from treating every incoming message as ground truth.
Incident Commander
The Incident Commander maintains the overall response plan.
Once sufficient evidence exists, it decomposes the incident into operational tasks and delegates them to specialized agents.
For example:
- identify the affected zone
- determine viable evacuation corridors
- check shelter capacity
- allocate available resources
- prepare targeted warnings
- continue monitoring the incident
The important difference from a conventional assistant is that this is a persistent workflow.
The system does not wait for another chat message before continuing its work.
Response Agent
The Response Agent converts the incident plan into operational recommendations.
It considers information such as:
- blocked roads
- evacuation routes
- shelter capacity
- buses
- ambulances
- rescue resources
- vulnerable locations
If conditions change, its previous recommendation can become invalid.
That is intentional.
A disaster-response system needs to be able to change its mind when the world changes.
Communication Agent
The same emergency should not produce the same message for everyone.
A resident may need:
Avoid River Road. Use the western evacuation corridor toward the designated shelter.
An emergency coordinator may instead need:
Western corridor remains operational. Eastern access is unavailable. Resource allocation is being recalculated.
The Communication Agent transforms the shared incident state into audience-specific information while keeping the underlying facts consistent.
The moment we designed the project around
The most important part of our demo is deliberately not the initial flood detection.
It is what happens when the original plan fails.
During the simulated incident, the system may initially determine that Road C is the safest evacuation corridor.
Then a new event arrives:
ROAD C → BLOCKED
That event changes the shared incident state.
The agents must recognize that the existing plan is no longer valid, calculate an alternative, update the operational recommendation, and propagate the change to the parts of the system that depend on it.
No one should have to type:
“Please recalculate the evacuation route.”
The changing environment itself triggers the work.
That is the behavior we wanted from an agentic system.
How we built it
We designed ResilienceOS as an event-driven, stateful multi-agent system rather than a collection of independent prompts.
Our core Google stack is:
- Gemini for multimodal understanding and reasoning
- Google Agent Development Kit (ADK) for agent orchestration and delegation
- Google Cloud Run for backend/agent services
- Google Cloud Pub/Sub for asynchronous incident events
- Firestore for persistent incident state and agent memory
The architecture can be summarized as:
Cameras / Sensors / Weather / Citizen Reports
|
v
Pub/Sub
|
v
Event Processing
on Cloud Run
|
v
Gemini Reasoning
|
v
ADK Orchestrator
|
+------------+-------------+
| | |
v v v
Verification Response Communication
Agent Agent Agent
| | |
+------------+-------------+
|
v
Firestore
Incident State
|
v
Command Dashboard
Pub/Sub gives us an asynchronous event layer rather than requiring components to call each other synchronously.
Firestore provides persistent state so the system can remember what has happened instead of reconstructing an incident from a chat history.
ADK provides the orchestration layer for specialized agents.
Gemini provides the reasoning layer needed to interpret unstructured and multimodal evidence.
Cloud Run gives us a deployable backend for the workflow.
Multimodal incident understanding
One of the most interesting parts of the project was turning very different kinds of information into a common representation.
A disaster may generate:
IMAGE:
Water appears above the normal river boundary.
VOICE:
"Paani road ke upar aa gaya hai aur bahut tezi se badh raha hai."
SENSOR:
Water level +31 cm / 20 min.
ROAD STATUS:
Road C currently open.
These inputs have completely different structures.
The reasoning layer transforms them into something closer to:
{
"incident_type": "flood",
"risk": "high",
"confidence": 0.86,
"water_trend": "rapidly_rising",
"affected_zone": "Zone 6",
"road_c": "open",
"sources_correlated": 4
}
That structured state becomes the interface between agents.
This was an important design decision for us: agents should exchange operational state, not long conversational transcripts whenever possible.
Designing for failure
One of the biggest lessons from researching real disaster systems was that connectivity cannot be treated as guaranteed infrastructure.
The moment a flood, cyclone, wildfire, or earthquake becomes serious may also be the moment communication infrastructure becomes unreliable.
For that reason, our architecture separates two levels of capability.
Cloud-enhanced mode
When connectivity is available, the system can use:
- full Gemini reasoning
- multi-agent orchestration
- richer multimodal verification
- persistent cloud state
- live operational dashboards
Degraded / edge mode
If connectivity is unavailable, essential functionality should degrade rather than disappear.
The longer-term architecture therefore supports:
- deterministic local thresholds
- cached emergency information
- offline event queues
- local warnings
- synchronization when connectivity returns
We deliberately do not make an LLM the only component capable of recognizing an emergency.
For safety-critical systems:
AI should improve resilience, not become another single point of failure.
Human control and safety
Another challenge was deciding how autonomous an emergency-response agent should actually be.
Maximum autonomy is not necessarily the correct objective.
We instead use the principle:
AI proposes → policy validates → human approves when necessary
Low-risk actions can potentially happen automatically, such as:
- correlating sensor observations
- updating incident state
- detecting conflicting evidence
- recalculating recommended routes
- preparing localized messages
High-impact actions should remain governed.
For example, an official evacuation order should not be issued simply because a language model generated one.
The system is therefore intended to support emergency decision-makers, not silently replace their authority.
Challenges we faced
1. Making multiple agents actually useful
It is easy to create several agents that are really just several prompts.
We wanted each agent to have a clear operational boundary.
That forced us to ask:
- What state does this agent own?
- What tools should it access?
- What decisions can it make?
- What evidence does it require?
- What happens if it fails?
This led us toward fewer, more specialized agents instead of creating an unnecessarily large agent hierarchy.
2. Maintaining consistent state
Agents reasoning independently can easily produce contradictory conclusions.
A route considered safe five minutes ago may now be flooded.
We therefore treat the incident state as the source of truth, rather than relying on conversational memory.
New events modify that state, and dependent plans can then be reconsidered.
This became one of the most important architectural lessons from the project.
3. Handling uncertainty
Real emergency information is messy.
Sensors can fail.
Citizen reports can be wrong.
Images can be ambiguous.
Information can also simply be outdated.
We learned that the system should not hide this uncertainty.
Instead of producing only:
FLOOD DETECTED
we prefer representations such as:
Risk: HIGH
Confidence: 86%
Supporting evidence:
- rapidly rising water sensor
- visual river observation
- multiple citizen reports
- severe rainfall signal
Conflicting evidence:
- downstream gauge currently stable
The reasoning becomes inspectable rather than appearing magically authoritative.
4. Demonstrating a disaster system without a disaster
Testing emergency technology presents an obvious problem: we cannot wait for an actual flood to demonstrate it.
We therefore designed a simulation-driven workflow.
A scenario can progressively emit events such as:
T+0 Heavy rainfall
T+3 River level rising
T+6 Citizen reports street flooding
T+8 Road C becomes blocked
T+10 Shelter A reaches capacity
This lets us test whether the agents respond to changing conditions instead of demonstrating only a static happy path.
The simulator became more than a demo tool. It became a practical way to reason about failure cases.
What we learned
The biggest lesson was that agentic AI becomes most interesting when the environment can change without waiting for the user.
A chatbot typically follows:
request → response
An incident-response system follows:
event → decision → action → new event → revised decision
That difference changes almost everything.
It requires persistent state.
It requires asynchronous execution.
It requires specialized responsibilities.
It requires observability.
And it requires the system to recognize when its previous answer is no longer correct.
We also learned that resilience is not simply model accuracy.
A system can have an excellent model and still fail operationally if:
- the network disappears,
- its state becomes inconsistent,
- one bad report propagates everywhere,
- an agent has excessive permissions,
- or humans cannot understand why it made a recommendation.
For this problem, architecture matters as much as intelligence.
Why ResilienceOS
Acuífero·Vigía helped demonstrate an important principle:
AI for disaster resilience has to work under real-world constraints.
We wanted to explore the next layer.
What if the system did not stop after understanding the emergency?
What if specialized agents could maintain the incident, verify new evidence, coordinate a response, and continuously adapt as the situation changed?
That is what we are exploring with ResilienceOS.
Today, our prototype focuses on flooding because it gives us a concrete scenario where multimodal evidence, infrastructure failure, routing, resource constraints, and changing conditions all matter.
But the underlying model is broader.
The same incident-command architecture could eventually support specialized workflows for:
- wildfires
- cyclones
- landslides
- earthquakes
- industrial emergencies
The hazard-specific intelligence can change.
The operational loop remains:
Sense. Verify. Plan. Act. Monitor. Replan.
Our goal is not to build another system that tells responders something has gone wrong.
It is to explore what comes next:
From early warning to early action.
honestly, if u read the idea then idea is reallly good... just give us few weeks we are still in testing phase
Built With
- indevelopment
Log in or sign up for Devpost to join the conversation.