FIFA 2026 Ground Zero

Real-time AI agent that monitors live signals across FIFA 2026 venues, clusters incidents, and routes them to human commanders for approval — built with Gemini, Elastic MCP, MongoDB, and Arize Phoenix

Comment

FIFA 2026 Ground Zero — Project Story

Inspiration

During Copa America 2024, the final at Hard Rock Stadium — one of the actual FIFA 2026 venues — was delayed over an hour because thousands of fans breached the gates. Security was overwhelmed. Nobody had a unified picture of what was happening across the venue.

FIFA 2026 is the largest World Cup in history — 16 venues, 3 host countries, 50,000 security personnel, and millions of fans. The same chaos cannot happen again. That gap between thousands of incoming signals and a commander's ability to act within minutes is what inspired Ground Zero.

What It Does

Ground Zero is a real-time incident intelligence agent that:

  • Ingests live signals from OpenWeatherMap, NewsAPI, and social feeds into Elasticsearch
  • Clusters related signals by gate, keywords, and time window — turning 12 fan posts into one P1 critical event
  • Escalates automatically based on signal velocity — P2 watch at 5 signals, P1 critical at 10+
  • Routes each incident to the right human responder with a pre-drafted action plan via Gemini
  • Dispatches volunteers from MongoDB roster on human approval
  • Logs every agent and human decision as an immutable audit trail

The human stays in control — the agent handles the noise, the commander makes the call.

How We Built It

Data Layer

  • Elasticsearch + Elastic MCP — primary partner integration. All signals are indexed in real time. The Gemini agent reads P1/P2 clusters and updates incident status exclusively through the Elastic MCP server, satisfying the MCP integration requirement meaningfully.
  • MongoDB Atlas — persistent state store for volunteer roster (50 volunteers across 5 venues), routing rules per incident type, incident log, and audit log.

Agent Layer

  • Gemini via Google Cloud Agent Builder — classifies incidents, looks up routing rules and available volunteers from MongoDB, drafts action plans in natural language.
  • Arize Phoenix — every agent decision logged as an OpenTelemetry span. Input (raw signal), output (drafted action), confidence score, routing target — all observable and traceable.

Human-in-the-Loop Layer

  • Streamlit — four-tab approval console: Pending approvals, Resolved incidents, Live volunteer roster, Full audit trail. Commander can edit the drafted action before approving. One click dispatches volunteers, updates MongoDB, resolves in Elastic.

Live Data Sources

Source Type Used for
OpenWeatherMap API Live Heat and storm alerts at all 5 host cities
NewsAPI Live Breaking FIFA 2026 news
Synthetic social feed AI-generated Simulates fan posts on X and Facebook
MongoDB volunteers Seeded Shift gaps, no-show detection

Challenges We Faced

Elastic Serverless mode — the initial index creation failed because serverless Elastic doesn't allow setting number_of_shards or number_of_replicas manually. Fixed by removing the settings block and letting Elastic manage sharding automatically.

Arize Phoenix authentication — the standard OTLP header api_key was rejected with a 401. Phoenix Cloud requires authorization: Bearer format via phoenix.otel.register() rather than raw OTLP. Switching to the arize-phoenix-otel library resolved this immediately.

Signal clustering vs. individual alerts — early versions created a separate incident for every signal, flooding the approval queue. Solved by clustering signals by venue + gate + incident_type before writing to MongoDB, so the commander sees one unified P1 event instead of 12 separate pings.

Human-in-the-loop design — the temptation was to auto-approve low- confidence incidents. We deliberately kept every incident requiring human approval regardless of confidence, because in a safety-critical environment like a stadium, the cost of a wrong auto-action is too high.

What We Learned

  • MCP is genuinely powerful — using Elastic MCP instead of the Python SDK meant the agent could describe what it needed in natural language and let the MCP server handle the query construction. This is what agent-native infrastructure looks like.
  • Observability is not optional — without Arize Phoenix, we had no idea why the agent was routing certain incidents incorrectly. The moment we could see the input/output traces, debugging became trivial.
  • Human-in-the-loop is a feature, not a limitation — judges and users responded more positively to "the agent waits for you" than to any autonomous capability. Trust is built through transparency.

What's Next

In a production deployment, Ground Zero would connect to:

  • FIFA's live operations API for real venue data
  • Meta Webhooks and X Firehose for actual social signals
  • IoT crowd density sensors at each gate
  • 65,000 FIFA volunteer devices for real-time status

The agent logic doesn't change — only the data source adapters. Ground Zero is built to scale from a hackathon demo to 16 venues on match day.

Built With

Share this project:

Updates