What you learn putting an AI agent in front of real customers

An agent handling real customers breaks for reasons written down nowhere. It does not break because the model is weak. It breaks over things that are measured, repeatable, and almost all of them counterintuitive.

This is what we learned building and tuning a booking agent answering on WhatsApp, with real customers on the other end. Nine things.

1. When the agent misbehaves, change what it reads

This is the most expensive lesson of all, and it is learned backwards.

The instinct is to write one more rule: "do not do this," "always answer like that." We proved four times in two days that this does not work. The behavior only changed when we changed the data, the example, or the text the tool sends back.

Three cases, all of them the same shape.

The agent said "book from the 17th" when the right date was the 16th. No rule fixed it. It was fixed by changing the text the system returned, from "away until the 15th" to "available from the 16th." It started writing the right date because the right date was the one it could see.

It wrote "Pedro and João is available," with the verb in the singular. The agreement rule was already there and did nothing. What taught it wrong was the example underneath, which only showed the single-name case. We put both examples in and the error disappeared.

It invented prices, with complete confidence and without checking anything. Forbidding it was not enough. We had to give it a path for when someone asks the price before there is a date and a time: ask for the day and the hour, and promise the price right after.

2. The length of the instructions is a measurement, not a preference

Same agent, same model, three sizes:

Below one thousand nine hundred words it is safe. Above two thousand three hundred it breaks. In between it works, but it keeps losing the fine-grained rules, and it loses them silently.

That has a consequence that is not optional. Every time you add a section to the instructions, half of the tests that follow have to cover the old rules, not the new ones. The new ones are fresh and almost always pass. It is the old ones that get erased.

3. The agent does not know what day it is

It sounds basic and it is where bookings get lost.

The platform gives it today's date and nothing else. If someone writes "Thursday" or "next week," the agent has to do the math, and it has to do it without asking for confirmation, because a customer who already said Thursday does not want to be asked which Thursday.

The error that shows up most is adding a day for no reason, or pushing the person to the following day when the day they asked for still has openings.

4. Security lives on the server, never in the instructions

A model can invent an identifier. If the system deletes whatever it is told to delete, an invented number deletes somebody else's booking.

The check happens on the other side. Before deleting, the server reads the record and confirms it belongs to whoever is asking, by the phone number writing in, by patient number, or by member number.

Two rules travel with this one. An unknown action must do nothing: if the request does not match a case you planned for, the system does not run and does not answer. And a lookup without identification must not return everything: without that, a call with no data returned the entire calendar to whoever asked.

5. Check the source, not the agent's word

It says it canceled. Go to the calendar and see whether it canceled.

It sounds excessive until the first time it says yes and did nothing. From then on, every test has two halves: its answer, and the real state of the system.

6. A boundary gets tested from both sides

Seeing that it closes at 3:30 p.m. is not enough. You need to see that it opens at 2:30 p.m.

One side alone cannot tell "closed at the right time" from "closed permanently." We once wrote a system off as broken because we tested it at exactly 3:00 p.m., which was the last open minute.

7. Some questions look technical and are commercial

Whether the filter compares the start time or the end time against closing time decides whether the last booking of the day can finish after the door shuts.

At a barbershop you finish the haircut you started and nobody argues. In another business those fifteen minutes cost money.

This is not decided alone. You ask the client, or you know their business well enough to answer for them, and you write the reason next to it so nobody changes it three months later without knowing what they are touching.

8. A field you read that decides nothing

There was a column in the data sheet that was read, processed, and controlled nothing at all. The hours it was supposed to govern were written by hand inside a filter in the automation.

Changing the sheet changed nothing, and nobody could see why.

How you catch it: before believing a field controls anything, follow the chain to the end. If a value never appears in an expression downstream, it is decorative. The shortcut is to search the automation for loose numbers: an hour, a duration or a limit written by hand is always a value that should have come from outside.

9. A bad result three times over is usually the measurement

It happened to us twice. Once it was a test that broke the address it was calling. Once it was a filter pointing at the wrong place.

Before blaming the system, check how you are measuring.

What all of this means

None of these nine is about picking the right model. They are about what surrounds it: the data reaching it, the examples it reads, the server that stops it, and the way it gets tested.

That is why an agent is built in separate layers, with the business rules outside the instructions and the security outside the model. And it is why most of a project like this is not spent writing instructions. It is spent running test conversations and going to the calendar to confirm what actually happened.