Why your bot needs a route, not just a model

A good service bot sounds like your most organised employee: it knows what was already said, never promises what it must not, and knows when to pass a case on. Most bots built on language models today sound like that for the first few minutes and come apart by the tenth. It is worth understanding why.

When the model is also the manager

In a typical bot the model gets a long instruction ("you represent the business, be polite, never promise refunds") plus the whole conversation so far, and decides on its own what to do next. It understands the customer, picks the next step, remembers what was asked, and writes the reply.

That works well in a demo. In a real conversation, with a customer who answers one question and opens two new problems in the same message, the long instruction starts to compete with itself. The model asks again for something already answered, skips a check that was mandatory, or soothes an angry customer with a promise nobody at the business approved.

What it means for the code to hold the conversation

botloop turns this around. The route of the conversation is written down: which topics exist, which steps each topic has, which details to collect, and what happens when something is missing. At every moment the code knows which topic we are in, which step, and what has already been said.

The model keeps two jobs, and it is excellent at both:

• Reading. What did the customer say? Did they answer the question, open a new topic, ask for a person, or write something urgent?
• Phrasing. Saying what the current step needs to say, in natural language and in the business's own tone.

The decision about where to go next stays in code. So the same question is never asked twice, a mandatory check does not disappear, and a promise that is not in the business's rules is never made.

Three results you see straight away

The bot does not get lost. A customer who jumps between topics does not erase what was already collected. The earlier topic waits where it was, ready to return to.

Every decision can be checked. The bot's diagram is built from the same files that run it. If the bot did something odd, you can see which stop it was at and what led it there, instead of guessing what went through the model's head.

A handoff with a case file. When the conversation reaches a person, they get what was collected and what was already tried. They do not start from "hello, how can I help?".

So why a model at all?

Because customers do not write in forms. They write "the machine's been making a weird noise since yesterday and the door won't close either", with no punctuation and two problems. Understanding that takes a language model. But understanding is not managing. Whatever manages the conversation should be something you can read, check and change.

The model understands and speaks. The code knows where we are.

If you are building a bot for a business, the first question is not which model to choose. It is who decides where the conversation goes.