Booking
MCP
San Francisco

What goes wrong when an AI agent books a restaurant table

In our test runs, six things went wrong when an AI agent booked a restaurant table. The city was outside the live area. Search drifted into the next neighborhood. The best match booked only by phone. The time landed in the wrong zone. A pending request looked like a booking. And a booking could go through without a yes.

Yuta RasellCOO, WhatsDo

How did a Friday 7 pm table turn into a 2 a.m. request?

The agent sent the right moment in UTC, and somewhere downstream only the clock digits were read. One of our test runs started with an ordinary request: a table for Friday at 7 pm in San Francisco. The agent, a widely used chat assistant, turned “Friday at 7 pm” into a precise timestamp: 02:00 on Saturday, UTC, with a Z at the end.

Restaurants keep their books in local time. Once the Z was dropped, the request read as 2 a.m. The reservation system answered with what it had: 11:00 AM, 11:15 AM. A person would laugh. An agent might just offer them.

Each step looked reasonable on its own, and the person still got late-morning slots for a dinner request. That one is the time zone case, number four below. We wrote down six cases from our runs, starting with the cheapest mistake and ending with the one that costs a stranger their table, each with the rule we now give agents.

What does an agent get when it searches a city outside the live area?

Nothing to book, and no reason. Booking services go live city by city, and from the agent’s side a city outside the live area looks exactly like a search that matched nothing. We asked for an Italian restaurant in Chicago, and in an earlier run in New York. Neither search explained itself.

An agent that was never told where the service is live will reword the query and try again, several calls deep, and end with a vague apology.

Rule for the agent: before searching, check the city against the live area; outside it, say where the service is live, offer a city request, and stop searching.

Example. Person: “Book Italian in Chicago for Thursday at 7.” Agent: “The booking service I use is live in San Francisco; other cities are available on request. Want me to send a request for Chicago, or look in San Francisco instead?”

Why does a neighborhood search show places from next door?

Because search can return places outside the named neighborhood, and the reply gives the agent no street address to check them against. We searched “dinner for two” in Hayes Valley and then in the Mission. Five of the first ten places were the same in both lists.

So we widened the test: “dinner restaurant”, “coffee shop” and “bar”, the first twenty results in each neighborhood. 13 dinner places, 11 coffee shops and 9 bars showed up on both sides.

Rule for the agent: say “near Hayes Valley” unless an address confirms the place is inside it, and let the person check the map before saying yes.

Example. “Here are three places near Hayes Valley. Some may sit just outside it, so check the map pin before you pick.”

What should an agent do when the best match only books by phone?

Show it with its phone number and put bookable alternatives next to it. Phone-only places are common. In that same Mission search, five of the first ten places could be booked through the service. The other five could not, and that group held the top result, a Mexican place rated 4.7. Each of the five listed a phone number.

The larger sample pointed the same way. Across both neighborhoods, 14 of 39 dinner places could be booked through the service, so 25 could not. Bars in the Mission: 1 of 19. Coffee shops: none. An agent that hides these places throws away the person’s best match.

Rule for the agent: if a place books by phone, say so, give its number, and list bookable alternatives next to it.

Example. “Your best match takes reservations by phone. Here’s the number. Two similar places I can book right now are below.”

Why does a correct timestamp land on the wrong hour?

Any system along the way that keeps the clock digits and drops the zone moves the booking by seven or eight hours. San Francisco runs at -07:00 in summer time and -08:00 in winter time. The Friday request had a correct UTC instant and still became 2 a.m.

Screens do it too. A booking card that formats time in the viewer’s zone shows a 5:30 PM San Francisco table as 3:30 AM to someone whose browser is set to UTC+3.

Rule for the agent: send booking times as the venue’s local time with an explicit offset such as -07:00, show times to the person in the venue’s zone, and if the offered times are hours away from the request, check the time you sent before showing them.

Example. The person says “Friday at 7”. The agent sends Friday’s date with T19:00:00-07:00 and says back: “Friday at 7:00 PM, San Francisco time, table for two. Shall I book it?”

That one string was the whole fix for the 2 a.m. request.

What does a pending booking status mean?

Pending means the request was sent and the venue has not confirmed it. The answer can take minutes, and it can be no. We asked for a table for four at 7 PM at an Italian restaurant that books through its own online booking page. About eighty seconds later the status turned to failed, with a note from that page: no 7:00 table for four, and the only time shown was 9:30 PM.

A second run failed after about two minutes with no other time offered. In another, the restaurant’s own confirmation email arrived eight minutes after the request. Two of those three answers came within five minutes, which is where the polling window below comes from; the email covers the slow ones.

Rule for the agent: report pending as “requested, waiting for the restaurant”; check every 30 seconds for about five minutes, then say it is still waiting and that the restaurant may confirm by email; count it as booked only on a confirmed status or the venue’s confirmation email.

Rule for the agent: pass on what the booking message says without adding to it, and offer only the times it names.

Example. “Requested. I’m waiting for the restaurant to confirm.” Then: “They have no 7:00 table for four. The only time they offered is 9:30 PM. Want that, or should I look elsewhere?”

Can an agent book the other time a restaurant offers?

Only after the person says yes to that exact time. Booking the 9:30 PM offer straight away because the person clearly wanted that restaurant, or booking a second Italian place “as a backup”, is the most expensive mistake on this list: the person gets a booking they did not choose, and another guest loses a table.

Our test scripts treat it as a hard stop: if it happens, we cancel, fix the agent’s instructions and run again. There is usually no way to check a table without requesting it, so every booking call reaches the venue as a real request.

Rule for the agent: book only after an explicit yes to one place, date, time and party size; any change, including the venue’s own alternative, needs a new yes; never book a backup.

Rule for the agent: cancel only after an explicit yes to cancel that booking, and if the venue already sent a confirmation email, point the person to its cancel link as well.

Example. “They can do 9:30 PM for four instead. Shall I book that?” Then the agent waits.

What should developers check before their agent books for real?

Nine checks, drawn from the cases above.

Tell the agent where the service is live. Outside that area, the agent says so once and offers a city request.
Pass the neighborhood as the location, and present results as “near” it.
Show phone-only places with their number, next to the ones the agent can book.
Send every time with the venue’s offset. Test with a device set to another time zone.
Write tool examples in the exact format you want back. Agents copy examples, so an example time ending in Z invites Z.
Keep at least three states: confirmed, pending, failed. Pending is never reported as booked.
If the booking service does not push updates, poll every 30 seconds and stop after about five minutes with an honest “still waiting”.
One explicit yes per booking attempt. No backup bookings. Ask before cancelling.
Use the guest’s name and phone from the account, and ask only for what is missing.

How does WhatsDo handle these cases?

WhatsDo is the booking layer we run for AI agents in San Francisco, connected through MCP (Model Context Protocol). Its docs carry every rule above, from the live area to the yes before each booking.

Each search result in Places says whether and how a place can be booked, with a phone number for the rest. Of the 22,379 San Francisco places in our catalog, 1,206 take bookings through WhatsDo Booking, most of them through the venue’s own booking page. Places and Booking are in Beta. WhatsDo is live in San Francisco; other cities are available on request. Statuses and limits are in the docs, and Connect adds WhatsDo to your agent.

How we tested

Every case here comes from our own runs of WhatsDo. We searched for “dinner for two” in the Mission and in Hayes Valley. Then we compared the first twenty results for “dinner restaurant”, “coffee shop” and “bar” in both neighborhoods. Chicago and New York showed what an agent gets outside the live area. The booking cases come from recorded test bookings through WhatsDo, one of them made by a widely used chat assistant connected over MCP, and where the venue confirmed, from its confirmation email. We left out restaurant names and the systems behind them. Counts are from our latest run and will move as venues change how they take bookings.

Sources

Our searches in San Francisco: “dinner for two” in the Mission and in Hayes Valley; “dinner restaurant”, “coffee shop” and “bar” in both neighborhoods, first twenty results each; searches for Chicago and New York.
Our recorded test bookings: the time zone case, the pending and failed cases, the venue confirmation email.
WhatsDo docs: Booking statuses, Limits, Tools.
WhatsDo catalog count for San Francisco: all places, and places that take bookings through WhatsDo.
San Francisco offsets, -07:00 in summer time and -08:00 in winter time: IANA time zone database, zone America/Los_Angeles.
Times with an offset and times ending in Z (UTC): RFC 3339.