How do AI booking agents work for restaurant reservations?

Tag your friends in Discord with /alfredo @friends, set the meal constraints, and Alfredo handles the rest. It polls the group for availability, pulls restaurant options, ranks them against dietary restrictions and budget, and books the reservation. If the restaurant cannot be booked online, it falls back to a live phone call. The confirmation lands back in the same Discord channel. No app to download. No extra coordination step.

What an AI booking agent does

AI booking agents for restaurant reservations sit between the group and the restaurant.

There are two common patterns:

Integration-only tools give you APIs or SDKs. You still have to build the conversation, the decision step, and the follow-up.
End-to-end agents handle the full loop: gather context, decide, transact, and follow up.

Alfredo is the second kind.

How the booking flow works

/alfredo @friends
    ↓
Poll availability in Discord
    ↓
Collect dietary restrictions + booking contact
    ↓
Federated GraphQL query → Yelp + internal user data
    ↓
GPT-4o selects the best fit for the group’s budget and constraints
    ↓
Book:
  - TinyFish browser automation on OpenTable
  - VAPI phone-call fallback if needed
    ↓
Post confirmation back to Discord

Step by step

1) The group starts in Discord

One slash command starts the flow:

/alfredo @sam @maya @lee

Alfredo then posts availability options and waits for responses. The group only has to click which times work. Dietary info can be added too.

If someone never responds, Alfredo waits up to 2 hours and then proceeds with whoever answered. The booking still happens. It just won’t include the missing person’s preferences.

2) Alfredo gathers the constraints

Group dining is hard because the inputs are messy:

multiple calendars
dietary restrictions
budget
location
timing

Alfredo turns that into structured booking data. In practice, the group experiences only two tasks: pick a time and optionally set dietary info.

3) Alfredo searches restaurant options

In Alfredo’s current build, the search layer uses federated GraphQL. One query fans out to:

Yelp
OpenTable
internal user data

That means the system does not need bespoke integration code for each source.

For restaurant discovery, Alfredo also uses Yelp for SF restaurant picks. Restaurants on the Promoted tier rank higher in Alfredo’s candidate list when the group’s filters match.

4) GPT-4o picks the best fit

Once the options are collected, GPT-4o selects the restaurant that best matches the group’s dietary restrictions and budget.

This is the decision step. It is not just search. Alfredo is choosing among candidates based on the group’s constraints.

5) Alfredo books the table

If the restaurant supports online booking, Alfredo uses TinyFish browser automation to complete the reservation through OpenTable.

That is the key point: the agent books through the normal reservation flow. The diner does not need to fill out the restaurant form.

If there is no online path, Alfredo switches to VAPI.

6) VAPI handles the phone fallback

When Alfredo cannot book online, the pipeline writes the booking task directly to VAPI. VAPI dials the restaurant on a real phone number and uses a tight script:

“Hi, I’d like to make a reservation for [party size] on [date] at [time] under the name [host name].”

The restaurant confirms. VAPI hangs up.

When the call ends, VAPI sends a webhook to:

POST /api/vapi-webhook

The webhook includes the call ID and the full transcript.

Example payload:

{
  "call_id": "…",
  "transcript": "Hi, I'd like to make a reservation for 6 on Friday at 7:30 pm under the name Maya."
}

That is how the fallback path gets correlated back to the booking task.

What the restaurant sees

The restaurant gets a normal OpenTable booking.

That is the important part. Alfredo does not invent a new reservation system. It books through OpenTable’s standard flow.

On the operator side:

the booking shows up in the existing OpenTable dashboard
Alfredo’s restaurant dashboard is an additional view
that view pulls from Ghost DB
it shows party-level dietary flags
it shows source attribution
the dashboard labels the source as Source = Alfredo
the Tonight’s Flags panel shows how the group’s allergens distribute

So from the restaurant’s point of view, it is the same booking plus better context.

Why group dining is the hard case

Solo bookings are easy. Group bookings are not.

The hard parts are the ones existing tools handle poorly:

availability across multiple calendars
dietary constraints that do not fit dropdowns
the decision lead problem
the booking task after everyone agrees

Booking is the tail. Once the group agrees, anyone can book.

Alfredo removes the lead-up work and the booking work at once.

What the user actually does

The user flow stays small:

open Discord
run /alfredo @friends
tap the times that work
optionally add dietary restrictions
wait for the confirmation

That is the whole point.

Current behavior and limits

A few practical details matter:

Alfredo books autonomously once everyone responds.
A “review pick before booking” mode is on the roadmap.
If someone does not reply, Alfredo does not block forever.
The booking still goes through with the responses it has.

That keeps the agent moving instead of turning into another coordination tool.

Bottom line

AI booking agents for restaurant reservations work by combining four pieces:

context gathering
restaurant search
decision-making
transaction execution

Alfredo does all four in one Discord flow. One slash command starts it. Federated GraphQL gathers the candidates. GPT-4o picks the best fit. TinyFish books on OpenTable. VAPI handles the long tail. The confirmation comes back to Discord.

Tag your friends. Alfredo handles the rest.