The model collects, the code decides

In one of the group's businesses, the WhatsApp line is answered by an assistant. It answers questions about the menu and events, looks up the customer's history and loyalty points, suggests music and takes reservations. It has eighteen tools in total, and none of them creates an order, charges anyone or moves money. That was the first rule, decided before it spoke to its first customer.

The second rule came later, from a mistake. One day the assistant turned down a reservation that was perfectly valid, because it applied the house cutoff time at the wrong moment. The conversation was polite, the reply was well written, and the decision was wrong.

The fix was not a better prompt. It was taking the decision away from the model. Today, for reservations, the model collects the details, reports what it understood and passes it on. Whether the reservation goes in is decided by code, which applies the house hours the same way every time. The instruction written for the model is short: do not refuse on your own.

The split goes well beyond restaurant tables. A language model is very good at understanding what a person meant, pulling scattered information together and explaining an answer. It is not the right place for a business rule that has to produce the same result every time, such as a cutoff time, a credit limit, a discount or a deadline.

When a company asks where to put an agent inside its ERP or its customer service, our answer starts with three questions:

1. 01Which actions can this agent take on its own, and which can it only suggest?
2. 02Where is the rule that checks the conditions before the action written down, and who owns it?
3. 03What is the simple way to stop the agent afterwards if something goes wrong?

If all three answers exist before the first customer conversation, the agent goes into production with brakes. If they don't, it goes in with the best of intentions and one day turns down a reservation that was fine.