VenueOps-Agent

Inspiration

VenueOps Agent was inspired by the operational pressure of large real-world venues: stadiums, fan zones, malls, airports, and retail complexes. During peak moments like a World Cup match, operations teams have to manage crowds, queues, inventory, staffing, facility incidents, tenant activity, and safety policies at the same time.

These signals usually live in separate systems. A gate queue may look like a crowd problem, but it can also affect staffing, digital signage, retail demand, restroom queues, and incident response. We wanted to build an agent that can connect those signals, reason over venue SOPs, propose a safe plan, and leave a clear audit trail.

What it does

VenueOps Agent is an AI operations copilot for retail and event venues.

In the demo, kickoff is 75 minutes away. Gate B is overcrowded, Food Court inventory is at risk, a restroom incident needs response, and staff need to be rebalanced. The operator gives the agent a mission: keep fans moving, avoid stockouts, and handle facility incidents safely.

The agent then runs an observe-analyze-retrieve-plan-confirm workflow:

1. It reads live event data from MongoDB Atlas.
2. It calls MongoDB MCP Server tools such as find, aggregate, count, and collection-schema.
3. It analyzes crowd pressure, queue wait, stockout risk, staffing gaps, and incident priority.
4. It retrieves relevant SOP evidence with Atlas Vector Search-first retrieval.
5. It uses Gemini on Vertex AI as the planning layer.
6. It creates five operational recommendations:
   • dispatch trained stewards to Gate B,
   • redirect arrivals from Gate B to Gate D,
   • request urgent restock for a high-risk SKU,
   • assign a facility team to the restroom incident,
   • draft a tenant campaign to pull traffic toward a lower-pressure retail zone.
7. It keeps every action in pending_approval until an operator approves or rejects it.
8. It writes tool calls, rationale, evidence, decisions, execution effects, and audit events back to MongoDB.

The dashboard shows real-time KPIs, a venue heatmap, top risks, pending actions, before/after impact, SOP evidence, and a visible Tool Trace panel.

How we built it

The frontend is a Next.js and React command center. It includes a live dashboard, zone heatmap, risk cards, editable agent mission input, action approval queue, SOP evidence panel, and MongoDB MCP tool trace.

The backend is a FastAPI service deployed on Google Cloud Run. It owns the agent workflow, risk scoring, simulation controls, approval logic, guarded writes, and audit trail.

MongoDB Atlas is the operational foundation. It stores venues, events, zones, telemetry, tenants, inventory, staff shifts, incidents, SOP documents, agent runs, pending actions, and action audit records. MongoDB is used as:

• the operational database,
• the agent memory layer,
• the analytics engine for risk scoring,
• the SOP retrieval layer,
• the audit and execution history store.

The hosted agent uses the official MongoDB MCP Server for database access. The Tool Trace panel shows calls like mongodb.find, mongodb.aggregate, mongodb.count, and mongodb.collection-schema, including transport: mongodb-mcp-server, so judges can inspect how the agent used MongoDB.

For SOP retrieval, the backend attempts Atlas Vector Search first over sop_docs, then falls back to deterministic local ranking only for offline/local judging. Gemini on Vertex AI is used as the planning layer, and the repo includes a Google ADK agent definition for Google Cloud Agent Builder / Agent Platform alignment.

All high-impact actions are guarded. The model does not directly mutate arbitrary database records. It creates proposed business actions, and operators approve or reject them before execution. Every approval, rejection, and execution effect is logged.

Challenges

The hardest part was making the project feel like a real operations agent while keeping it reliable for public judging. We needed realistic state changes, but also safe reset and simulation controls.

We solved this with a synthetic MongoDB Atlas demo database, reset and scenario simulation endpoints, allowlisted business tools, human approval gates, and an explicit audit trail.

Another challenge was making the MongoDB integration visible. We did not want MongoDB to be just a backend store. We made it central to the agent loop: live operational data, aggregation-based risk scoring, Vector Search SOP retrieval, MCP tool access, agent memory, and audit logging.

What we are proud of

We are proud that VenueOps Agent is not just a chatbot or static dashboard. It observes live data, reasons over risks and SOPs, proposes a multi-step plan, asks for confirmation, executes approved actions, verifies impact, and records what happened.

We are also proud of the visible Tool Trace. It makes the agent's database work inspectable and helps show that MongoDB MCP Server is part of the actual workflow.

Live event command center showing real-time venue KPIs, zone pressure heatmap, top risks, stockout warnings, and before/after operations impact for the World Cup demo scenario.

Human-in-the-loop action queue where the agent's recommendations remain in pending approval, with rationale, data used, risk level, expected impact, audit trail, and approve/reject controls.

Visible agent tool trace proving MongoDB MCP Server-backed reads, including find, aggregate, count, collection-schema, Atlas Vector Search SOP retrieval, Gemini planning, and guarded action writes.

Architecture documentation summarizing the observe-analyze-retrieve-plan-confirm-act-verify loop, Google ADK / Agent Builder alignment, MongoDB collections, and production guardrails.

What is next

Next steps include real SMS or Slack dispatch, live IoT/event stream ingestion, geospatial routing, multi-venue tenant management, richer permission controls, and production authentication around public demo reset/simulation endpoints.

Built With

• atlas-vector-search
• fastapi
• google-adk
• mongodb-aggregation
• mongodb-atlas
• mongodb-mcp-server
• next.js
• react
• typescript
• vertex-ai-gemini