POC exploration
The Chatbot Was Harder Than the Queue Algorithm
93rd / 9,156 · 41 tests · live queue state
GateFlow was built for a physical-event challenge: help people choose an entry gate at a 50,000-person venue while conditions change around them. The queue algorithm was the contained part. The conversational assistant was harder because it had to speak naturally without becoming another source of made-up operational state.
The assignment logic stays deterministic. Instead of sending every request to the single least-loaded gate and creating a new herd, the system uses a power-of-two-choices pattern with proximity weighting. Arrival estimates are smoothed with an exponential moving average so one noisy update does not swing the recommendation. Firestore carries the changing queue state to the application.
Gemini sits above that machinery. It interprets questions and calls bounded functions that read the same live state used by the rest of the product. It does not calculate an ETA from prose or remember yesterday's gate status. That division made the assistant contextual without giving it ownership of the facts it was explaining.
The alternatives were simpler and worse in useful ways. A global minimum looks optimal one visitor at a time and unstable when thousands receive it together. A model-only recommendation is pleasant to demo but impossible to audit when the number is wrong. Periodic polling reduces infrastructure work while making the answer stale at the exact moment context matters.
The project finished 93rd out of 9,156 entries and carries 41 tests across the queue and conversational paths. Those are good signs for a time-boxed build, not evidence that it is ready to manage a real crowd. Production truth would need to come from scanners or turnstiles. Accessibility, closures, bad GPS, offline operation, and emergency overrides all need paths that do not depend on a chat response. Eventual consistency is acceptable for visitor guidance and nowhere near sufficient for safety decisions.
What I kept from the experiment is the boundary: the model handles language and context; code handles assignment and timing. The chatbot becomes useful because it can reach live state, not because it is allowed to invent it.
The decision
Keep assignment, proximity weighting, and ETA calculation deterministic. Let Gemini understand the question and call functions that read live state, but never let it choose a gate from memory.
Alternatives considered
- ·Send everyone to the globally least-loaded gate. Locally optimal for one request, but it can create oscillation as a crowd follows the same answer.
- ·Let the model recommend a gate directly. Conversationally smooth, but it has no reliable ownership of queue math or current state.
- ·Poll periodically for updates. Easier infrastructure, but stale queue state weakens both the recommendation and the conversation around it.
Tech stack
The challenge
Recommend an entry gate for a 50,000-person venue while queue load changes in real time, without creating herd movement or allowing a conversational model to invent an ETA.
Architecture approach
- ·Used a power-of-two-choices assignment with proximity weighting instead of chasing one global minimum.
- ·Smoothed arrival estimates with an exponential moving average so one noisy update did not jerk the recommendation around.
- ·Streamed queue state through Firestore and exposed it to Gemini through bounded function calls.
- ·Kept anonymous onboarding and the venue map light enough for a time-boxed public demonstration.
Results
- Ranked 93rd out of 9,156 entries in the build challenge
- Forty-one tests across the queue and conversational paths
- A live assistant whose answer can change with current venue state without inventing the underlying numbers
What I'd do differently at production scale
- ·A real venue needs scanner or turnstile events as the source of truth; browser presence is not a security-grade headcount.
- ·Location accuracy, accessibility, closed gates, and offline fallback need explicit operational paths before deployment at an event.
- ·The eventual-consistency window is acceptable for visitor guidance, not for emergency or crowd-safety decisions.