Inspiration

I chose theme parks because they feel like small cities: dynamic, chaotic, emotional, and constantly changing. Rides, restaurants, shows, crowds, weather, staff, safety rules, and guest needs all move at the same time. That makes parks a great place for governed AI to help teams make faster, safer, and more explainable decisions.

The idea also came from my own guest experience. I have waited in long lines without clear updates, missed shows I wanted to see, and felt how poor communication can hurt the whole park visit. As a first-time visitor, enjoying a park often requires too much research, and one unexpected delay can disrupt the day.

I wanted to build AI that helps real-world teams act under pressure. ParkPulseAI explores how agents can go beyond chatbots by using memory, policies, approvals, and traces to turn live park chaos into safe action.

What it does

ParkPulseAI is a memory-powered, policy-gated AI operating layer for theme parks.

It has five core parts:

Ops Loop responds to live incidents like ride outages, food pickup delays, weather shifts, staffing pressure, and urgent guest messages.

Trace Audit records what happened, what the agent recommended, why it was allowed, who approved it, and what the outcome was.

Event Agent helps plan parades, festivals, seasonal overlays, VIP routes, and accessibility journeys using grounded venue memory.

Agent Handshake verifies outside agents, such as guest AIs or supplier systems, before allowing data sharing, actions, approvals, or internal handoffs.

Guest Triage and Employee Training helps guests get faster support while giving staff clearer scripts, escalation paths, and learning feedback.

Together, these agents help parks respond, explain, verify, plan, support, train, and learn.

How we built it

We built ParkPulseAI as a real-time multi-agent system using Google Cloud and MongoDB.

Google Cloud powers the live infrastructure: Vertex AI Gemini for reasoning and language, Cloud Run for the backend, Pub/Sub and Eventarc for live signals, Cloud Workflows for approvals, messaging for guest and worker notifications, and BigQuery for decision telemetry and evaluation.

MongoDB acts as the durable park memory layer. It stores park profiles, zones, paths, ride state, staffing, food inventory, policies, playbooks, accessibility details, guest messages, decisions, review notes, eval results, and reusable lessons.

The core loop is:

Live signals enter the system. ParkPulseAI retrieves memory and policies. Gemini reasons over the situation. Policy gates check what is allowed, blocked, or approval-required. Workflows route approvals and handoffs. Notifications are sent. Decisions, traces, outcomes, and lessons are saved back to memory.

Challenges we ran into

The biggest challenge was avoiding a generic chatbot design. Theme park operations involve safety, staffing, accessibility, compliance, permissions, guest communication, and real-time coordination. ParkPulseAI needed to be an operating loop, not just a chat interface.

Grounding was another challenge. If the system recommends a route, food stop, staff action, guest message, or event plan, it must be tied to real venue data instead of invented details.

Trust between agents was also difficult. ParkPulseAI may interact with a guest’s personal AI or a supplier system, but it cannot automatically trust them. The Agent Handshake layer had to check identity, proof, permissions, allowed actions, blocked actions, handoffs, and receipts.

We also struggled with the digital twin early on. The math and modeling were not right at first, so the project came together piece by piece through coding, testing, and rebuilding.

Accomplishments that we're proud of

We are proud that ParkPulseAI became a full platform concept, not just one demo agent.

It connects live operations, event planning, guest support, employee training, audit traces, and agent-to-agent handshakes into one memory-powered operating layer.

We are especially proud of Trace Audit, because every recommendation should have a reason, policy basis, approval path, and outcome record.

We are also proud of Event Agent, because it shows how AI can support creative planning while staying grounded in real zones, paths, policies, accessibility details, food locations, and brand rules.

Most importantly, ParkPulseAI is designed to recommend, explain, escalate, block, and learn — not blindly automate.

What we learned

We learned that useful operational AI needs more than a model. It needs memory, policy gates, approvals, audit trails, and feedback loops.

We also learned that agent systems need clear boundaries. Some actions can be automated, some require approval, and some must be blocked.

MongoDB memory changed how the agents reasoned. Instead of isolated prompts, agents could use durable context, past decisions, policies, and venue facts to make recommendations more traceable and reliable.

We also learned that evaluation must be built into the product. ParkPulseAI needs to be judged on grounding, safety, policy compliance, usefulness, trace quality, and whether it improves future decisions.

What's next for ParkPulseAI

Next, we want to expand ParkPulseAI beyond theme parks into any environment that needs real-time coordination, policy checks, approvals, memory, and operational learning.

Theme parks are the first use case because they are dynamic, guest-facing, and easy to understand visually. But the same pattern can apply to factories, airports, hospitals, campuses, stadiums, logistics hubs, and cities — anywhere many teams, systems, rules, and live incidents must be coordinated at the same time.

Future versions could include predictive crowd or workflow simulation, proactive staffing suggestions, supplier coordination, accessibility-first routing, incident recovery playbooks, personalized support, cross-site learning, and stronger agent-to-agent verification.

The long-term vision is for ParkPulseAI to become a general AI coordination layer for complex operations: helping organizations respond faster, plan smarter, support people better, prove why decisions were made, and learn before the next incident.

Built With

Share this project:

Updates