GatherBite

Inspiration

Ordering food for a group sounds simple until everyone has different dietary needs, preferences, budgets, and restrictions. Finding something everyone can actually eat often means manually comparing menus and trusting information that may be incomplete or outdated.

We built GatherBite to explore a different approach: instead of asking an AI to simply recommend food, what if an AI agent could plan an order from live restaurant data and then independently verify that its recommendation actually satisfies the group's constraints?

What it does

GatherBite turns a group's requirements into a verified restaurant order.

Users provide:

• Number of people
• Maximum budget
• Delivery or carryout preference
• Location
• Dietary requirements such as vegetarian, vegan, gluten-friendly, dairy-free, or ingredient restrictions
• Optional food preferences

GatherBite then works through an agentic pipeline. A Planner proposes candidate orders using live public restaurant/menu information, while an independent Verifier checks hard constraints and supporting evidence before an option can be presented as verified.

If verification fails, GatherBite does not simply trust the Planner. It can reject the candidate and require another attempt. The user remains in control of the final decision and checkout.

How we built it

GatherBite is built with Next.js, TypeScript, React, Groq, and Vercel.

We designed the system around separate planning and verification responsibilities rather than relying on a single model response.

The pipeline includes:

1. Collecting structured group requirements.
2. Observing live public restaurant/menu data.
3. Generating candidate orders with an AI Planner.
4. Independently evaluating constraints and evidence with a Verifier.
5. Rejecting or adapting candidates that do not pass verification.
6. Presenting verified options and preserving the user's final decision.
7. Preparing a restaurant handoff without autonomously completing payment.

We also built automated evaluation cases covering different dietary, budget, evidence, and verification scenarios, along with extensive automated tests.

Challenges we ran into

The hardest part was making the system honest about uncertainty.

Restaurant data changes, dietary claims require evidence, and an AI-generated order that sounds reasonable is not necessarily a valid order. We therefore built fail-closed behavior throughout the pipeline rather than presenting uncertain results as verified.

Another challenge was working with real external systems and infrastructure. During final deployment testing, our live Planner request exceeded Groq's free-tier token-per-minute limit because the Planner receives a large live catalog context. Rather than silently weakening verification or fabricating successful rehearsal results, we preserved the verified architecture and documented the infrastructure limitation.

What we learned

The biggest lesson was that building an AI agent is not just about making the model generate a good answer. For real-world tasks, the system also needs evidence, independent verification, explicit failure states, and clear boundaries around what the agent is allowed to do.

We also learned how valuable it is to separate planning from verification. A Planner can be creative about finding solutions while a separate Verifier remains skeptical about whether those solutions actually satisfy the user's constraints.

What's next for GatherBite

Next, we want to reduce and selectively retrieve the menu context sent to the Planner, expand beyond Domino's to additional restaurants, improve live deployment capacity, and continue strengthening the evaluation suite.

Our goal is to make GatherBite a general-purpose group food agent that can find an option everyone can actually agree on — without asking users to blindly trust the AI.

Built With

• aiagents
• groq
• llm
• next.js
• node.js
• react
• typescript
• vercel