137,000 people, zero human decisions: agentic disaster response with Elasticsearch

Agent Builder is available now GA. Get started with an Elastic Cloud Trial, and check out the documentation for Agent Builder here.

Elastic just coordinated the automated evacuation of 137,000 military personnel across seven installations, with no human in the loop. A Category 4 hurricane hits the Hampton Roads coastline. Elasticsearch's geospatial enrichment identifies every facility in the impact zone at index time. A Kibana detection rule fires. A workflow starts an AI agent conversation. The agent reasons through capacity, distance and branch compatibility, then dispatches 16 evacuation and intake notifications in a single pass. From raw GDACS event to coordinated action, automatically.

Every year, natural disasters force emergency managers, military commanders, and public safety officials to make high-stakes decisions in compressed time frames. These decisions traditionally rely on phone trees, spreadsheets, and institutional knowledge spread across dozens of people. The coordination overhead alone costs critical time.

This post demonstrates how Elastic can power a responsive, agentic coordination system for disaster response that detects a threat, reasons through the logistics, and takes action automatically. To make it concrete, we built a simulation: a fictitious Category 4 hurricane threatening the Hampton Roads coastline triggers the automated relocation of over 137,000 personnel across seven military installations.

Disclaimer: This is an entirely fictitious scenario built for demonstration purposes. Hurricane ELARA-26 doesn’t exist. Installation locations are based on real, publicly available geographic data (the U.S. Department of Defense [DoD] Military Installations, Ranges, and Training Areas [MIRTA] dataset), but all operational data, like personnel counts, housing capacity, assets, contact emails, and mission profiles, are completely fabricated. Nothing in this demo reflects actual military readiness, capability, or operational procedures.

Why automated disaster response requires geospatial and agentic coordination

When a natural disaster threatens critical infrastructure, the coordination challenge is immediate:

• Which facilities are in the impact zone?
• How many personnel need to move?
• Where can they go, and do those facilities have capacity?
• Who needs to be notified right now?

These questions don't wait. Neither should the answers.

Deploy the pipeline: prerequisites and setup

Follow the instructions here in the example repo to deploy a local Elastic cluster with Elastic Inference Service (EIS) via Cloud Connect.

How the Elasticsearch agentic disaster response pipeline works

The pipeline has seven layers that work together end to end:

1. Data ingestion: Global Disaster Alert and Coordination System (GDACS) disaster events sent to Elasticsearch
2. Ingest pipeline: GeoJSON is ingested and normalized to Elastic Common Schema (ECS).
3. Geospatial enrichment: The event's affected area polygon is matched against indexed military installation boundaries.
4. Alerting: A Kibana detection rule fires when a disaster intersects any installation.
5. Workflow automation: The alert triggers a Kibana workflow that starts an AI agent conversation.
6. AI reasoning: The agent reasons through affected facilities, their assets, and nearest supporting facilities to determine relocation of all assets and personnel.
7. Email notifications: The agent dispatches emails to all recipients for incoming and outgoing personnel and or assets.

Let's walk through each layer.

Step 1: Indexing military installations with geo boundaries

The foundation is the DoD MIRTA dataset from source.coop/seerai/hifld. This dataset provides a geo_shape of type Point for each installation; centroid coordinates rather than full boundary polygons.

Each installation document in the mitra-facilities index is enriched with operational profile data (all fictitious), beyond what MIRTA provides:

This rich index is what enables the AI agent to make intelligent allocation decisions; not just "here are nearby bases," but "here are bases with available housing capacity, compatible mission types, and the logistics to receive incoming assets."

Step 2: Ingesting and normalizing GDACS events

GDACS publishes real-time GeoJSON for earthquakes, tropical cyclones, floods, wildfires, volcanoes, and droughts. We ingest this feed into a data stream (logs-gdacs.events-*) using a custom ingest pipeline that normalizes the raw GeoJSON to ECS fields.

The GDACS ingest pipeline does several things worth noting:

Geometry extraction: The centroid is stored as a geo_point for map display, and the impact polygon is stored as a geo_shape in gdacs.affected_area, which is the field used for intersection queries later.

Severity normalization: Each disaster type has a different severity scale. A tropical cyclone is measured in km/h wind speed; an earthquake in Richter magnitude. The pipeline maps all of them to a normalized 0–100 score:

The normalized severity score then maps to a severity_level label (low, medium, high, critical) used for alert severity mapping in the detection rule.

ECS alignment: event.kind: alert, event.category: threat, timestamps mapped to event.start/event.end, and a stable fingerprint-based _id for deduplication.

Step 3: Geospatial enrichment: Finding affected facilities at index time

Elasticsearch's geo_match enrich policy matches the disaster polygon against every installation boundary at index time, with no query-time join required. Instead of querying at search time, we use an enrich processor in the ingest pipeline to match the disaster's impact polygon against every installation boundary as the document is indexed.

The enrich policy is a geo_match policy:

The processor runs at the end of the ingest pipeline:

INTERSECTS catches any installation whose boundary touches or overlaps the disaster polygon and even partial intersections. The result is that every GDACS event document is stored with an affected_facilities nested array that tells us exactly which installations are in the impact zone. No join query needed.

Step 4: Detection rule: Alerting on facility impact

A Kibana detection rule watches the logs-gdacs.events-* data stream and fires when a GDACS event has been enriched with at least one affected facility:

The rule runs on an hourly schedule (covering a now-1h to now window) and uses dynamic severity mapping; the gdacs.severity_level field computed by the ingest pipeline drives the alert severity automatically.

Alert severity also drives the risk score via field mapping:

When the rule fires, it passes the full alert context, including the enriched affected_facilities array with installation names, types, and locations, downstream to a Kibana workflow.

Step 5: Workflow automation: Bridging alert to agent

Kibana Workflows handle the handoff from detection to response. The natural disaster response workflow is triggered by the alert:

The entire alert payload (disaster type, severity, affected area, and the list of impacted installations) is forwarded to the AI agent as its initial context. The agent takes it from there.

Step 6: The AI agent: From data to coordinated action

The mitra.response agent takes the full alert payload and, in a single agentic loop, assesses scope, finds receiving facilities, allocates personnel and dispatches evacuation and intake notifications, all without human intervention.

The agent has two tools available:

• mitra.nearest_facility queries the mitra-facilities index using a geo_shape query, sorted by distance from a given coordinate, returning up to 50 nearby active installations with available capacity.
• mitra.send_email iterates over a JSON array of facility objects and dispatches formatted evacuation or receiving notifications.

The agent's instruction set defines a clear workflow:

1. Assess the situation. Parse the alert, identify affected facilities, and determine disaster scope.
2. Inventory what needs to move. Personnel counts, critical assets, housing requirements per facility.
3. Find destination facilities. Call mitra.nearest_facility for each affected installation, filtering out facilities still in the danger zone.
4. Make allocation decisions. Reason through single versus multi-facility solutions, branch compatibility, housing capacity, asset support.
5. Send coordination emails. Dispatch evacuation orders to source facilities and intake notifications to receiving facilities.
6. Produce a summary report. Produces a short summary of all affected facilities, total personnel, assets moved, destination facilities, and any concerns to the chat for review.

The agent's allocation logic follows real-world constraints: Don't exceed housing capacity, prefer same-branch relocations when possible, use joint bases for multi-branch overflow, and prioritize distance to minimize transit time.

The nearest facility tool

The underlying workflow query uses geo_shape with a circle filter and _geo_distance sorting:

Available capacity is computed at query time via a script field which calculates housing capacity minus current personnel count. The agent uses this to allocate personnel across destinations without exceeding limits.

Hurricane ELARA-26: agentic coordination of 137,000 personnel, end to end

Hurricane ELARA-26 is a Category 4 storm (213 km/h maximum winds) projected to make landfall in the Hampton Roads area of Virginia. When the GDACS event is ingested, the affected area polygon intersects seven major military installations in the region. The detection rule fires. The workflow kicks off an agent conversation.

Within a single agentic loop, the agent:

• Identified seven facilities in the impact zone, with a combined 137,372 personnel.
• Called mitra.nearest_facility to find receiving facilities outside the storm track.
• Distributed personnel across nine receiving facilities based on available housing capacity and distance.
• Generated and dispatched evacuation orders to all seven affected installations.
• Generated and dispatched intake notifications to all nine receiving facilities.
• Produced a full coordination summary, similar to below:

Facilities evacuated:

Receiving facilities:

Assets relocated include transport vehicles, helicopters, patrol boats, medical units, engineering vehicles, generators, water trailers, shelter kits, and communication systems.

Automated email notifications

Once the agent finalized its allocation plan, it called mitra.send_email and dispatched 16 emails in a single pass; that is, evacuation orders to all seven affected installations and intake notifications to all nine receiving facilities. Each message included destination facility, incoming personnel count, assets to move, and a coordination contact. What would have taken hours of phone trees completed automatically the moment the agent finished reasoning.

Extending agentic disaster response with RAG and policy grounding

This demo is purely from structured data, like capacity numbers, distances, and operational status. Elastic's semantic search and retrieval augmented generation (RAG) capabilities can make the agent significantly smarter, with two additions:

Historical response retrieval: Index past after-action reports, Federal Emergency Management Agency (FEMA) incident summaries, and disaster response records as vector embeddings. When a new event fires, the agent can semantically retrieve how similar events were handled, informing allocation decisions with institutional knowledge rather than capacity math alone.

Policy and doctrine grounding: Index DoD emergency management directives, installation continuity of operations plans, and commander guidance. The agent can retrieve and cite the actual policies governing a response, ensuring every decision is grounded in doctrine rather than inference.

Both follow the same Elastic-native approach:; An inference pipeline generates embeddings at index time, and a semantic search tool is exposed to the agent. The coordination pipeline stays the same. The agent just gets smarter.

Why Elasticsearch is the right platform for agentic public sector response

This isn’t a chatbot. It isn’t a dashboard. It's a responsive agentic workflow system, one that detected a threat, reasoned through a complex logistics problem, and coordinated the relocation of 137,000 people without a human in the loop. That kind of outcome is only possible because every capability it depends on lives in a single, unified platform.

Elasticsearch's geospatial support (geo_point, geo_shape, enrichment policies, and distance-based sorting) handles the spatial reasoning that makes intersection detection and facility lookup possible at scale. Semantic search and vector embeddings ground agents in truth, ensuring AI reasoning is based on what's actually in your data rather than hallucinated assumptions. Kibana's detection engine, Workflows, Agent Builder, and Agent Builder tools wire it all together into a pipeline that goes from raw event to coordinated action with no external glue code required.

No other platform brings this together the way Elastic does. The combination of real-time indexing, geospatial precision, semantic retrieval, and agentic orchestration, all in one stack, with enterprise-grade security and observability built in, is what separates Elastic from tools that do one of these things well but require you to stitch the rest together yourself.

Agentic geospatial response for emergency management, fire, law enforcement and public health

The same architecture applies wherever people, facilities, and real-time events intersect. The specific data changes. The pipeline doesn't.

Emergency management: FEMA and state offices of emergency management can map shelter locations, staging areas, and vulnerable populations against incoming National Weather Service (NWS) severe weather polygons, triggering automated resource pre-positioning before a storm makes landfall.

Fire and emergency medical services: Fire departments can overlay unit locations and response zones against wildfire perimeters or structure fire clusters, automatically routing mutual aid requests to the nearest available units with the right equipment.

Law enforcement: Agencies can correlate active incident locations with school zones, critical infrastructure, and officer positions, triggering geo-aware lockdown notifications or resource dispatch without waiting for manual triage.

Public school safety: School districts can monitor real-time threat feeds against campus boundaries. When a threat intersects a school's perimeter, an agent can immediately notify administration, initiate lockdown communications, and coordinate law enforcement response, all before a dispatcher picks up a phone.

Public health: Health departments can match disease surveillance data or environmental hazard zones against clinic locations, population density layers, and supply depot inventories to route resources where they're needed most.

The data is different in every scenario. The underlying pattern of ingest, enrich at index time, detect intersection, trigger agentic response, and act is all the same. Elastic gives public sector organizations the platform to build it once and adapt it everywhere.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.