Chatbot, RAG and AI agent: the difference is who gets to book

You've seen it. The box in the bottom right corner that says "Hi! How can I help?" and then offers four buttons: Opening hours, Book a table, Prices, Contact. Press "Book a table" and you get a link to a form. Type anything free on Thursday around seven instead and it says "Sorry, I didn't understand. Please choose one of the options below."

That box is still sitting on most restaurant and clinic websites. It is three generations behind what the technology can do.

RAG is having a moment right now, mostly discussed as though it were the same thing as "AI that can answer questions about our company". That's true, and it's still only the middle step. The difference that decides whether a guest actually gets helped sits one step further on, and it has nothing to do with how well the system understands the question. It's about what the system is allowed to do about it.

Generation one: the tree

The classic web chat is a decision tree. Somebody sat in a builder and drew it: if the visitor types something containing "open" or "hours", reply with the opening-hours text. If they press button two, show the form. Nothing in that chain understands language. It matches keywords against a list and falls back to "please choose an option" when the match misses.

It works exactly as long as the guest asks the question the way somebody anticipated. The trouble is that guests don't. They write "there's four of us, any chance tonight or are you full", which contains neither "book" nor "table". They write "how late are you open Saturday". They call and talk for two sentences before getting to the point. A tree that covers all of that needs hundreds of branches, and somebody has to maintain every one.

Which is why most of these chats ended up being an expensive link to the contact form.

Generation two: RAG

RAG stands for retrieval-augmented generation. Fetch first, then answer. The idea is simple and it's a good one.

You upload your own text: the menu, the price list, the terms, the FAQ, maybe the whole site. The system cuts it into chunks and turns each chunk into a vector, a long row of numbers standing for what the chunk is about. When a guest asks something, the question is converted the same way, and the system pulls the chunks sitting closest to it in that number space. Only then does the language model get to work, with the guest's question in one hand and the retrieved chunks in the other, and instructions to answer from them.

That fixes two real problems at once. The model doesn't need to have learned anything about you, and it doesn't need to invent. The text is right there in front of it.

In our case that index lives at ElevenLabs, one per venue. The phone agent reads from it mid-call. Web chat, SMS, email, Messenger and Instagram read from the exact same index through a call that runs the agent's own retrieval without starting a conversation. That's the entire point of having only one: an owner who uploads a new wine list in the portal shouldn't have to wonder which channels got it.

Retrieval ranks hits by vector distance and we pass on the five nearest, capped at 6,000 characters. The raw response is a lot bigger. A normal query comes back with around twenty chunks and roughly 40 kB of text, which would swamp a fast model and make the reply slow and rambling. Throwing most of it away is part of the job.

So far RAG is excellent. And so far the system still can't do anything.

What RAG will never be able to answer

Retrieval answers questions whose answer is written down somewhere. That's a larger set of questions than people expect. Opening hours, allergens, parking, cancellation terms, whether you have a high chair, what a hygienist appointment costs. All of that is text, and text can be retrieved.

A free table at seven on Thursday is not text.

It isn't in any document, it changes while the guest is typing, and the only place the truth exists is the booking system. A RAG chat asked that question has three options, and two of them are bad. It can say it doesn't know, which is honest and also exactly why the guest picks up the phone instead. It can find the nearest chunk in the index, say "we're open until 10 on Thursdays", and answer from that, which sounds helpful and doesn't answer the question. Or it guesses.

The third one is the dangerous one. A language model told to be helpful, with no way to check a fact, will sooner or later write "of course, Thursday at seven works, I've booked you in". Nothing has been booked. The guest turns up anyway.

This isn't a theoretical risk and it isn't something you prompt your way out of. It's what happens when you ask a system that can only produce text to perform an action.

Generation three: the agent that can reach into your systems

The step that actually solves it is to stop asking the model to answer the question and give it tools instead.

When somebody asks about a time, Kim doesn't write a reply. Kim calls check_availability, which goes on to the venue's booking system: BokaMera, EasyPractice, GastroPlanner, easyTable, a calendar, or our own table. The system answers with the times that exist. Only then does the model form a sentence, and that sentence can only contain times the system itself just approved.

If the guest wants one of them, create_reservation is called and the booking is written for real. The guest gets a confirmation. Staff see it in the system they're already looking at.

The rule underneath is the hardest one we have, and it's written into our own spec: never confirm a booking without a real availability check. That's why the choice of model is something we test rather than have opinions about, and why we run a regression suite against the voice agents looking for exactly this failure: replies that sound like a confirmation without a booking behind them. We grade the way it fails, not the score.

Why "book it" is harder than it sounds

There's a reason chat vendors stop at linking to your form. Actually booking means taking responsibility for two guests not getting the same table.

Two people can type at the same time. One calls while another chats. Both ask about Thursday at seven, both are told it's free, both say yes. If you check availability and write the booking as two separate steps, the second conversation slips in between them.

So in the database, every booking takes a lock on the venue, re-reads how many covers are already booked in that time window, compares against the maximum, and aborts with over_capacity if it doesn't fit. Only then is the row written. Every call also carries an idempotency key, so a network error that sends the same booking twice produces one booking rather than two.

None of that has anything to do with language models. It's ordinary database discipline. But it's the line between a system that talks about bookings and one that makes them, and it's the line your customers notice.

RAG is still there, and it still bites

The point isn't that retrieval is obsolete. We run it alongside, because it answers everything that's written down, and that's most of the questions. The tools answer the things that change.

Two things are worth knowing if you're setting this up yourself.

The quality of the index is the quality of the answers, and the index never complains. We found in August that a URL returning 404 gets swallowed as a document anyway: the page is scraped, the error message is indexed, and a 109-character document reading "This page doesn't exist" then sits there competing to be retrieved. Everything looked fine in the interface. One mistyped address in the portal is enough to put nonsense in front of guests on every channel.

And a tool that can never return anything useful is worse than no tool. If a venue hasn't added any sources, we don't expose the search function to the model at all. Otherwise it sits there searching, gets zero hits, and loses the thread in a conversation where the guest is waiting.

The short version

Three technologies, three different questions they can answer.

The decision tree answers what somebody anticipated. RAG answers what you've written down. An agent with tools answers what's true right now, and can do something about it.

If you're comparing vendors, only one question actually separates them: when the guest says yes to Thursday at seven, is the booking in your system by the time the conversation ends? Everything else is a matter of degree.

If you want to see it on your own business, book a demo or read what happens in your booking system.