An AI that answers WhatsApp messages is easy to demo and hard to trust. The demo always works, because you ask it the question you had in mind when you built it. Trust is what happens on the message you did not anticipate, on a Friday evening, when a real customer's real appointment is on the line.
We build a WhatsApp booking assistant, so we have hit these failures on live numbers rather than in theory. Here are three that matter, with what we measured, and the design rules that came out of them.
Failure 1: it says it did something it never did
The customer asks to cancel. The assistant asks for confirmation. The customer confirms. The assistant replies, warmly and clearly, that the appointment has been cancelled.
It never called the cancel function. Nothing was cancelled. The appointment is still there, the customer believes it is gone, and nobody finds out until someone does not show up.
We saw this three separate times in one evening's live testing in July 2026, with a smaller and cheaper model tier. The same four scenarios were then run against a mid tier model, which passed all four on the first attempt. Model versions change quickly and any specific comparison ages, so the lesson worth keeping is not the name of a model. It is this: for an assistant that takes actions, instruction following is worth more than a lower price per message. The cheap model is not cheaper if one missed cancellation costs an appointment slot and a customer's trust.
The structural defence matters more than the model choice:
The AI never writes to the database. It can only call a small set of functions, and deterministic code decides whether each one is allowed to proceed.
If the model does not call the function, nothing happens in the system, which is bad. But the reverse, a model quietly writing a wrong record, is worse and is ruled out entirely. Every state change in the system has a log line with the tool call that produced it. "It said it cancelled" is never evidence, the log is.
Failure 2: it forgets what it just did
This one is subtle and it nearly stopped our launch.
A customer books an appointment. The assistant confirms it correctly. Then the customer sends the most common last message in any booking conversation: "thanks". The assistant re-checks availability out of reflex, sees that the slot the customer just took is no longer free, concludes it is unavailable, and tells the customer their appointment did not go through.
A perfect booking, undone by a thank you.
The cause was not the prompt. We tested that. The model was not being told to persist proof of what it had done: the machine readable result of the booking call was held only in memory during that one exchange, and never carried into the next turn. On the next message, the model saw its own earlier sentence claiming a booking, but no evidence, and it went to verify.
We ran an isolation experiment, one variable at a time, twenty runs per condition:
| Condition | Wrong "your booking is gone" replies |
|---|---|
| Baseline | 16 of 20 |
| Prompt rule reworded | 15 of 20 |
| Booking result carried into history | 0 of 20 |
Rewording the instruction changed nothing. Carrying the actual result of the action into the conversation removed the failure completely.
The lesson generalises well beyond our product. When an AI assistant appears to have a memory problem, look at what state you are actually giving it before you rewrite the prompt. Prompt wording is where these bugs are usually treated and rarely cured.
There is a second distinction hiding in that fix, and it is worth stating, because getting it backwards creates a new bug. Results of questions, such as "which slots are free", are snapshots that go stale within minutes and must not be replayed later. Results of actions, such as "this appointment was booked", are facts that stay true. Only the second kind belongs in the assistant's long term view of the conversation.
Failure 3: two customers, one slot
Two people ask for Friday at 5pm within the same second. Both conversations check availability, both see the slot free, both confirm. One customer arrives to a chair that is taken.
This has nothing to do with AI. It is an ordinary race condition, and it is solved the ordinary way: the availability check and the write happen inside a single database transaction with the relevant rows locked, so the second request finds the slot taken and is refused. The assistant then does what a receptionist does, apologises and offers the nearest alternative.
The reason to mention it in an article about AI is that it is easy to assume the model handles this. It cannot. A language model has no view of what another conversation did a millisecond ago. Anything that must be true for every customer simultaneously has to live in the database layer, not in the prompt.
What "trustworthy" actually means here
After all of the above, our working definition is narrow on purpose, and it separates two things that are easy to blur: what the system makes impossible, and what it merely makes unlikely.
Guaranteed by the code, not by the model:
- It cannot create, move or cancel an appointment that the database did not accept. Every write goes through a function call, and deterministic code decides whether it proceeds.
- It cannot double book, even under simultaneous requests, because the check and the write happen inside one locked transaction.
- Every action is visible in a log with the exact call that caused it, so a disputed appointment has an answer that does not depend on anyone's memory.
Steered, measured, but not guaranteed:
- Services, prices and available times are handed to the model from your data, and it is instructed to use nothing else. That makes an invented price unlikely and it is what we test for, but no prompt makes a sentence impossible. The guarantee is on the booking, not on every word of the chat.
- It hands the conversation to a human when the customer asks, and when it hits a case outside what it is allowed to do. It cannot recognise every situation where a person would have been better.
The first list is the one that matters. A trustworthy assistant is not a cleverer model, it is a model with a smaller blast radius. Be suspicious of any vendor whose two lists are the same list.
What it still gets wrong
Being honest cuts both ways, so here is the current state rather than the marketing version.
Our assistant occasionally asks one confirmation question more than it needed to, when the customer's intent was already clear. It errs toward caution. We have chosen to leave it that way, because the failure mode of an extra question is a slightly longer conversation, and the failure mode of less caution is a wrong booking.
It also handles a customer who changes their mind mid sentence less gracefully than a good receptionist. Real humans are better at conversation. The assistant wins on being awake at 11pm.
The takeaway
Do not evaluate a booking assistant by how well it chats. Evaluate it by what it is structurally incapable of doing wrong, and by whether the vendor can show you a log of what it did.
If you want to see one running, Rendezo is the self hosted script these rules came out of, and there is a live demo of the admin panel where you can read the conversations and the appointments they produced. The tool calls themselves are written to the application log on your own server, which is the point: on a self hosted install, the record of what the AI did belongs to you and not to a vendor's dashboard.