Inspiration

People want to spend more time with the friends they already have. But wanting to meet up and actually making it happen are two very different things.

Even when a group wants to see each other, small logistical barriers add up: finding a time that works, staying within everyone's budget, figuring out transportation, choosing somewhere everyone likes, and simply being the person who reaches out and starts the plan. Too often, “we should hang out soon” never becomes an actual event.

Existing social-planning platforms like Partiful and Eventbrite largely begin after an event already exists: someone decides what is happening, when and where it will happen, and then invites people to join.

We wanted to reverse that flow.

Our goal is to use AI for the part of friendship nobody particularly enjoys: the logistics. By reducing the friction between “we should hang out” and “see you Friday,” we hope to make it easier for existing friendships to actually happen offline.

Sources of Inspiration: https://pmc.ncbi.nlm.nih.gov/articles/PMC11288408/

https://libarts.source.colostate.edu/are-americans-suffering-a-friendship-crisis-study-shows-we-dont-need-more-friends-just-more-time-with-those-we-already-have/

https://www.cnbc.com/2026/08/07/people-too-tired-to-reach-out-to-friends.html

What it does

Where Are We Eating? takes a group from “we want to meet up” to “we have a reservation” with as little planning overhead as possible.

An organizer creates an event and shares a link with their friends. Instead of coordinating through a group chat, each guest quickly submits their availability and preferences, including cuisine, price range, dietary restrictions, preferred distance, and atmosphere.

From there, our agent does the tedious work: it combines everyone's responses, identifies the group's constraints and preferences, searches for restaurants that satisfy them, negotiates conflicts, and decides on a restaurant and reservation.

How we built it

We built Where Are We Eating? as a full-stack web application centered around an agentic planning workflow.

Our frontend provides and interface for organizers to create events and guests to submit availability and restaurant preferences. We deliberately designed the interaction around quick selections rather than long prompts or forms, because the point of the product is to reduce the effort required from each person.

On the backend, we built APIs for creating events, collecting group responses, managing location information, and passing the group's combined constraints into the restaurant-selection workflow.

The agent sits between the group's preferences and the external services needed to act on them. Rather than simply generating restaurant recommendations, it uses structured information about the group to search for appropriate restaurants, reason about tradeoffs between different preferences, and move toward actionable reservation options.

We also integrated location data and restaurant information so recommendations are grounded in real places rather than generated from the model's internal knowledge.

Challenges we ran into

One of our biggest challenges was figuring out where the agent should make decisions and where humans should remain in control.

Group planning is inherently messy. One person may care most about distance, another may have a dietary restriction, and another may strongly prefer a particular cuisine. There isn't always a mathematically “best” restaurant. We had to think carefully about how to aggregate preferences without making the experience feel like a black box making decisions for the group.

Reservation automation presented another challenge. Restaurant reservation systems are fragmented across different platforms, and many don't expose open APIs for programmatic booking. Getting an agent from recommending a restaurant to actually completing a reservation therefore required us to think beyond a traditional API-only architecture.

We also had to balance collecting enough information to make useful decisions with our original goal of reducing planning friction. Every additional question improves personalization, but it also creates another reason for someone not to respond.

What we learned

One of our biggest takeaways was how difficult it can be to connect AI agents with technologies that were not designed for agentic interaction. Restaurant discovery was relatively straightforward, but actually completing a reservation was much harder. Many reservation platforms rely on closed APIs, browser-based flows, or integrations that require prior approval. We explored different approaches to getting our agent closer to completing this final step, rather than simply waiting for every service to expose an API or MCP designed for agents. This made us think more about the infrastructure needed for agents to interact reliably with existing software.

We also learned to be more deliberate about what information an agent actually needs to ask a user for. Our first instinct was to collect as many preferences as possible, but every additional question adds friction—the exact problem we were trying to reduce.

Instead, we started separating information into three categories: what the agent needs to explicitly ask, what it can reasonably derive from other inputs, and what can be treated as a general preference unless a user indicates otherwise. For example, dietary restrictions require explicit input, while factors like shorter travel distance and lower cost can generally be treated as preferable when two options otherwise satisfy the group's needs.

This shifted our approach from trying to collect a complete description of everyone's ideal plan to identifying the minimum human input necessary for the agent to make useful decisions. The challenge is not only making an agent capable of doing more, but deciding which decisions actually require a person in the loop.

What's next for Where are we eating ?

With more time, we would focus first on completing integrations with reservation platforms such as OpenTable and Resy through their APIs, MCPs, or other supported integrations. This would allow the agent to handle the entire process from gathering group preferences to confirming a reservation, rather than requiring a user to complete the final booking step.

We would also add user accounts and integrations with services such as personal calendars. Instead of repeatedly asking users when they are available, the agent could use information they have already chosen to share to identify overlapping availability and reduce the amount of input required each time a group wants to meet.

Finally, we would expand beyond restaurants. The same process of gathering a group's constraints, finding common availability, and selecting an option could be applied to other types of plans, such as going to a movie, attending an event, or finding an activity to do together.

Built With

Share this project:

Updates

Submission history