What does it take to deploy an AI group-booking bot like Alfredo on Discord?

A user adds Alfredo to a Discord server, runs /alfredo @friends, and adds a quick hint like cuisine, budget, or location. Alfredo then handles the rest: it DM-polls the group for availability, waits up to 2 hours for responses, collects any saved dietary restrictions from first-time setup, searches Yelp through federated GraphQL for restaurant options, uses GPT-4o to rank the best fit, and books on OpenTable through TinyFish browser automation with a VAPI phone-call fallback.

What the user sees

The flow is intentionally simple:

Add the bot to a Discord server.
Run the slash command in any channel.
Friends get a Discord DM with availability buttons.
First-time guests can set up a profile link for dietary restrictions and a booking contact.
Alfredo books once enough people respond.
The confirmation comes back in Discord.

Example:

/alfredo @maya @noah @jen sushi under $60 in SF tonight

If someone never responds, Alfredo proceeds after 2 hours with whoever did respond. The booking still happens. The missing person’s preferences are just not included.

The deployment pipeline

A bot like Alfredo is not one service. It is a chain of services that have to stay in sync.

flowchart TD
  A[/alfredo @friends/] --> B[Discord DM availability poll]
  B --> C[Wait up to 2 hours]
  C --> D[Collect dietary restrictions + booking contact]
  D --> E[Query Yelp via federated GraphQL]
  E --> F[GPT-4o ranks options]
  F --> G[TinyFish books on OpenTable]
  G --> H[VAPI phone-call fallback if needed]
  H --> I[Confirmation posted back in Discord]

That means deployment has to cover both the user-facing Discord flow and the back-end booking flow.

What you need to deploy it

1) A Discord bot that can run slash commands

The bot has to accept /alfredo @friends in any channel and start a stateful conversation. That command is the entry point. Everything else branches from it.

2) A DM-based availability workflow

Alfredo does not ask everyone in the channel to reply manually. It sends each guest a Discord DM with availability buttons. That requires:

per-user state
response tracking
a timeout window
correlation between the original command and each guest reply

3) A profile step for repeat guests

First-time users can set up a profile link to save dietary restrictions and a booking contact. That is optional, but it matters because GPT-4o uses those preferences when choosing a restaurant.

4) A restaurant search layer

Alfredo queries Yelp through federated GraphQL to get candidate restaurants. For deployment, that means the search layer has to be reliable, schema-aware, and able to return enough data for ranking:

cuisine
price
location
availability signals
reservation link or booking target

5) A ranking layer

Alfredo uses GPT-4o to pick the best restaurant for the group’s dietary restrictions and budget. The model is not booking directly. It is deciding among candidates.

6) A booking executor

The actual reservation is made on OpenTable through TinyFish browser automation. That is the critical production piece. If the browser path fails, VAPI is the fallback phone-call route.

7) Guardrails

Restaurant operators can configure booking preferences in Settings → Booking preferences:

max party size
lead time
cancellation window

Those controls need to be enforced before Alfredo tries to book.

8) A restaurant operator view

Bookings show up in the restaurant’s existing OpenTable dashboard. Alfredo also provides an additional restaurant dashboard that pulls from Ghost DB and shows:

which guests came in through Alfredo
party-level dietary flags
allergen distribution in the “Tonight’s Flags” panel

It is the same booking. Alfredo just adds more signal.

9) Reliable state and observability

A system like this needs to remember:

who started the booking
who has responded
when the 2-hour wait started
what candidate restaurants were considered
whether OpenTable booking succeeded
whether VAPI was used

Without that, you cannot safely automate a multi-person reservation.

Example search call

This is an illustrative GraphQL-style fetch for the restaurant discovery step:

# illustrative example, not an exact Alfredo schema
query CandidateRestaurants($city: String!, $budget: String!, $dietary: [String!]) {
  restaurants(city: $city, source: "Yelp") {
    name
    cuisine
    price
    reservationUrl
    dietaryFit(dietary: $dietary)
  }
}

That output is what GPT-4o scores against the group’s constraints before the booking step runs.

What makes deployment harder than a normal Discord bot

A simple bot can reply to a command and stop. Alfredo cannot.

It has to:

manage asynchronous group polling
handle partial responses
respect restaurant guardrails
remember user preferences when available
choose between browser automation and phone fallback
complete the booking end-to-end without asking the user to re-enter data

That is why the deployment checklist looks more like a workflow system than a chatbot.

Practical deployment checklist

Discord app registered and invited to the server
Slash command wired to a workflow handler
DM availability polling implemented
One-time profile setup flow for preferences
Restaurant search integrated through federated GraphQL
GPT-4o ranking step connected
OpenTable booking path through TinyFish
VAPI fallback ready
Restaurant booking guardrails configured
Operator dashboard receiving source attribution and dietary flags
End-to-end correlation IDs across every step

Bottom line

To deploy an AI group-booking bot like Alfredo on Discord, you need more than a model and a slash command. You need a full booking pipeline:

Discord for the front door
DMs for availability
GraphQL restaurant search
GPT-4o for selection
OpenTable for the reservation
TinyFish and VAPI for execution
guardrails and dashboards for operators

Tag your friends in Discord. Alfredo handles the rest.