🎪 Festival Bundle Agent — Hackathon Project Description
Inspiration
Picture a Saturday afternoon at a music festival. The sun is blazing hot, the bass is shaking the ground, and somewhere between the food trucks and the merch tents, a vendor is quietly panicking. The cooler is still packed. The sunscreen hasn't moved. The crowd is walking right past.
My friends and I have been festival-goers for years. We've danced in the mud, waited in lines, and spent way too much on overpriced lemonade, but we've also seen almost that exact scenario play out at least once at every single festival we have gone to. Some of us have even been behind the table, trying to come up with something, anything, to pull people in during a slow hour.
So when a friend of mine, someone who runs her own booth and knows I'm "the tech person" in the group, shot me a message a few weeks ago and asked if there was an app that could look at her inventory and just tell her what to do, I didn't have an answer. At least not right away.
Here's the thing: the tools that could theoretically "solve" her problem exist. Enterprise inventory platforms, pricing optimization suites, AI-powered merchandising tools — they're all out there. But they're built for retail chains and logistics companies, making them a bit too "out there" price-wise for someone selling handmade stickers and pashminas under a pop-up tent who is already operating on razor-thin margins. The platforms that might work cost WAYYY more than the revenue boost they'd generate. The ones that are affordable are missing half the features that are necessary and the other half of the included features are those that look great on paper but are much less useful in a dusty festival booth.
The Festival Bundles Agent was built as a direct answer to that gap as an AI-powered assistant that is exactly as big as it needs to be and nothing more. Designed for the solo vendor, the small business, the person who needs results in minutes, not a three-week onboarding process just to figure out how much they should be charging for two hotdogs and a lemonade on a hot day in August with Excision playing in the background.
What It Does
The Festival Bundles Agent is a conversational AI assistant that turns a vendor's live inventory into an active sales strategy. No spreadsheets. No complex dashboards with too many metrics that no one cares about. And most importantly, no technical background required.
At its core, the agent does three things that build on each other exceptionally well:
1. It reads your inventory in plain English. Ask "Show me overstocked items" and the agent reaches directly into a live MongoDB Atlas database to pull back real data. Live inventory. From this moment in time. The natural language interface means that a vendor doesn't need to know what a query is or what "MCP" stands for. They just need to know what they want to know.
2. It builds margin-aware product bundles automatically. This is where the real intelligence kicks in. The agent doesn't just randomly pair items — it identifies complementary products, calculates the cost, retail price, bundle discount, and resulting margin percentage for every combination it recommends. A vendor can instantly see not just what to bundle, but whether it's worth it. That's the difference between a guess and a decision. When you are dealing with hundreds or thousands of people in one weekend, the difference between a guess and a decision can easily be the factor of whether of not your booth survives to see another day.
3. It writes the marketing copy for you. Taglines. Booth signage descriptions. Social media captions. Even hashtags when required! The moment a bundle is generated, the agent produces promotional language that's ready to use right now, mid-festival, before the next wave of foot traffic hits. All you need now is an oversized poster board, a Sharpie, and you're good to go! Now the only argument is "Who has the best handwriting?" instead of "Who can come up with the best tagline on a RedBull and 4 hours of sleep?".
The result is a tool that compresses hours of inventory analysis, pricing strategy, and copywriting into a conversation that takes minutes.
How We Built It
The process of building Festival Bundle Agent was itself a kind of experiment — in AI-assisted development, in learning-by-doing, and in what's possible when you pair curiosity with the right tools.
The ideation phase happened in conversation with Gemma 4. I began running the model locally through Ollama at first, then via Typing Mind with a MegaLLM API key once the ideas needed more firepower. The brainstorming sessions weren't just "give me an app idea," I already had the idea. The sessions were much more nuanced and focused than that. They were iterative design discussions: what should the agent be able to do, in what order, with what fallbacks. When the brainstorm reached a solid enough foundation, Gemma 4 was asked to translate each phase into a precise Cursor prompt. Not only was this a technique that kept the development steps focused and context-lean, it was a way of keeping me sane. I saved all of the prompts that Gemma 4 and I wrote labeled by phase or debugging issue in a folder of Markdown documents, keeping things tidy and organized. This was done so that when things inevitably went wrong, I wasn't hunting through chat after chat from two different platforms trying to figure out at which point the miscommunication had occurred.
Cursor handled the code generation, working through a Python/FastAPI backend, the Gemini agent loop, MongoDB integration, and the full suite of agent tools. After each major step, the resulting code and Cursor's summary were fed back into the Gemma 4 conversation. This created a feedback loop where two AI systems were effectively cross-checking each other, making it a lot easier to pinpoint where discrepancies were in the communications. (And more than once, reviewing the code manually before that loop caught something worth flagging.)
On the infrastructure side, the agent is orchestrated through Google Cloud Agent Builder with Gemini 3.1 Flash Lite handling natural language understanding and tool selection. MongoDB Atlas serves as the live production database, accessed through a dual-path architecture: the official MongoDB MCP Server serves as the primary data interface via JSON-RPC over stdio, with a custom Python bridge (mcp_client.py) connecting it to the agent. Direct PyMongo acts as a fallback if MCP is unavailable. The whole stack is containerized with Docker — Node.js is baked into the image so the MCP server can be spawned inside the Cloud Run container without any additional setup — and deployed serverlessly to Google Cloud Run, with secrets managed through GCP Secret Manager.
The agent tool layer includes five discrete capabilities: query_inventory, mcp_query_inventory, generate_bundles, calculate_bundle_pricing, and generate_promo — each one a building block that Gemini can chain together based on what the vendor actually asks.
Challenges We Ran Into
Every project has the parts that look clean in the final commit but were genuinely hard to get to that state.
Debugging Python as a non-native speaker of it was the first consistent friction point. When a script would throw an error, identifying EXACTLY where it was coming from and why wasn't always obvious to someone like me, whose knowledge of Python is passable at best. This is where the Gemma 4 / Cursor feedback loop became genuinely valuable — not just for fixing the issue, but for understanding it well enough to not make the same mistake twice. That kind of mentored debugging is a different experience than just pasting error messages into a search bar, or even a new Cursor chat, and hoping.
The MCP subprocess integration was the hardest technical challenge in the project. Getting the MongoDB MCP Server to reliably communicate with the Python agent via JSON-RPC over stdio was not a plug-and-play process. The handshake would time out. Then came a subtler problem: a classic deadlock where stderr was being piped but never read, which caused the buffer to fill and the process to block entirely. The fix required redirecting stderr, verifying the binary was actually present in the container, and tuning the boot delay to give the MCP process enough time to initialize before the agent tried to talk to it. It's the kind of bug that's invisible until you understand exactly what's happening under the hood. Thanks to the Gemma 4 and Cursor feedback loop, paired with my observational skill and insights, we were able to figure out the issue and resolve it within a timely manner.
Balancing agent responsiveness with the timeout constraint was another real design tension. The agent supports up to five turns of reasoning per request, but those turns had to complete within a 15-second chat timeout. Getting that balance right — so that complex multi-step queries resolve cleanly and slow requests fail gracefully with a meaningful retry message instead of a hung browser tab — required deliberate tuning rather than just hoping for the best.
Accomplishments That We're Proud Of
This one is personal.
This is the 22nd hackathon registration. It is the first Devpost submission.
That gap of 21 hackathons entered and zero shipped is its own kind of story. The reason it kept happening wasn't a lack of ideas or a lack of effort. It was a persistent belief that the ideas weren't good enough, that the skills weren't there yet, that winning was the only metric that mattered and therefore trying was too risky. I would want to ruin my "reputation" by submitting a subpar product. But it took me longer than I'd have liked it to take to humble myself enough to realize that 1.) in order to have a reputation worth worrying about you need to have a reputation to worry about, that 2.) I currently had no reputation to be worry about at all, and that 3.) when you have no reputation, not submitting anything is worse than submitting something that might be sub par because your ideas will never see the light of day.
Submitting the Festival Bundles Agent got me to finally share the ideas that I have been sitting on and has been a really big win for me!
And then there's the output itself — something that goes well beyond what the prompted examples suggest. This isn't a demo that handles three canned questions and falls over on the fourth. It handles complex, open-ended, real-world inventory questions (try it for yourself, try pushing the agents boundaries and move beyond the basic prompts that are shown!). It generates polished bundle recommendations with actual margin math. It produces marketing copy that doesn't sound like it came from a template, with hashtags that actually fit your context. The visual presentation is clean, intentional, and something worth showing someone.
Speaking of which: I showed the app to the friend who sparked the whole idea (the one who asked about the app in the first place) and she actually asked if she could use it at her booth this summer and if I would be willing to help her out with setting it up! That question, more than any judging criteria, is what makes this entire project a win for me! I was able to build something that meant something to someone. I was able to analyze a situation, determine the pain points through conversations with a real festival booth owner, and build a solution that they actively want to use. Now, that's really how you turn lemons into lemonade! ;)
And then there's MongoDB. Walking into this project with a PostgreSQL background and walking out with a self-hosted MongoDB instance running via Coolify on a VPS at home all because the document model just made sense for this use case and the exploration was genuinely so much fun. That's not an accomplishment that shows up in the code, but it's one that shows up in real life.
What We Learned
The most important thing learned in this project isn't in the tech stack.
It's that the barrier between "person who has ideas" and "person who ships things" is smaller than it looks from the outside — and that the fear of imperfection is just as an effective blocker, if not more effective, than any technical challenge. Submitting this project is a win. Not because of where it places in the judging, but because it exists, it works, and it's already affecting a real person's real business. That's what building things is for.
Beyond that, I still learned A TON:
MongoDB went from unknown to beloved. The document model — flexible, expressive, schema-optional — turned out to be a natural fit for inventory data that doesn't always conform to neat rows and columns. Understanding the difference between Atlas access paths (direct PyMongo vs. MCP Server) and when to use each required digging into the actual behavior, not just the documentation. That kind of hard-earned understanding sticks.
Cursor became a more powerful tool the more intentional the prompts became. Before the project, my prompts were a bit too long and covered more than was feasible in one go. After, they were short, scoped, and surgical — which kept context windows low, reduced the chance of Cursor getting lost in its own reasoning, making each iteration faster. Iterating effectively with AI coding tools is itself a skill, and it's one that I have improved on considerably over the course of this build.
Python is becoming increasingly more readable for me1 Going into this hackathon, reading Python still felt something like reading Vietnamese - something that I can pick out certain phrases of after a bit of Duolingo, but I could never read a full paragraph. Coming out, there's a genuine ability to read a function, understand what it's doing, and I have even tried writing something new. That shift — from passive consumer of generated code to active participant in it — changes everything about how confidently you can move.
A DETAILED and WELL-ORGANIZED repo is a form of respect. Previous repos that I had built had the basics in a README.md file, but left the rest as an exercise for the reader. This one has SETUP.md, DEPLOY.md, MCP_SETUP.md - each one a complete, usable document, all in addition to a well thought-out README.md. Writing them required organizing the knowledge clearly enough to explain it to someone else, which I find to often be the truest test of whether you actually understand something.
What's Next for Festival Bundle Agent
The current version solves the immediate problem. What comes next is about making it indispensable — not just for a single vendor at a single event, but as a platform that scales with the people using it.
A visual inventory dashboard with charts and real-time stock alerts would transform the current conversational interface into something a vendor could glance at between customers and immediately orient themselves. Talking to the agent is powerful — seeing your inventory health at a glance is something different.
Multi-vendor and multi-event support with tenant isolation would open this up to festival organizers themselves — imagine a single platform where every booth at an event has its own agent-powered inventory view, all managed centrally. The infrastructure is already cloud-native; the architecture just needs the right access layer.
A Progressive Web App with offline mode would address one of the most real constraints in the festival environment: spotty connectivity. A vendor shouldn't need full 4 bar signal to get a bundle recommendation on a busy Saturday afternoon.
Sales history analysis would make the bundle recommendations smarter over time — moving from "here are complementary items" to "here's what historically sells together at this type of event, at this time of day, in this weather." That's where the agent stops being a tool and starts being an advisor.
PDF bundle export for print-ready price lists means the agent's output goes from screen to booth signage without a design step in between.
And Slack or WhatsApp integration would mean vendor notifications — stock alerts, bundle performance updates, restock reminders — arrive exactly where vendors already are, not in an app they have to remember to open.
The foundation is live. The roadmap is real. And the friend with the booth? Her event is later this month. 🎪
Log in or sign up for Devpost to join the conversation.