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.

Answers you can trust, from Cited.md