How to design a bot properly, step by step (and why almost no one does)

The right order

1. First decide what the bot does NOT do

Before thinking about how it talks, decide which specific tasks it handles and — more importantly — where the boundary is: which situations always go to a person. A bot with a small, clear job works; a bot that "handles everything" handles nothing well.

What people get wrong: they want it to do everything from day one and define no boundary. So the bot ends up improvising in exactly the cases where it should never decide alone.

2. Write down your business rules before touching anything

Your services, your prices, your policies, what's only offered if asked for, what always goes to a person. All written down, in one single document. The bot reads from there.

What people get wrong: they don't write them. They discover them in production, every time a conversation blows up. They end up learning their own rules from the bot's mistakes.

3. Map the whole conversation before you code

On paper, map the paths: the easy one (all goes well) and, above all, the odd ones: the customer changes their mind mid-way, asks for two things at once, makes a mistake, or answers something you didn't expect. Here you decide something crucial: who holds the wheel, the AI or a fixed script. One of the two, not both.

What people get wrong: they map nothing. They code the easy path, see it work in a demo, and assume it's done. The odd paths — which are most of real life — they patch afterwards.

4. Decide where the state lives and which path actions go through

Before writing the first real line, answer two questions: in which single place is it stored where each conversation stands? Through which single path do the actions that matter (book, charge, cancel) go? It's the boring part, and it's exactly what separates a reliable bot from one that breaks on its own.

What people get wrong: they don't decide. The state ends up scattered across five places that don't match, and the same action written in three. Then they fix a bug and the same one reappears the next week in another corner.

5. Build the part that acts first, as if the AI didn't exist

The logic that books and charges has to work and be safe on its own, with no AI involved. The AI goes on afterwards, on top, as the thing that understands what the customer wants and calls that logic. Never the other way around.

What people get wrong: they put the AI in charge of executing directly. They hand the keys to the till to something that, by design, sometimes makes things up.

6. Tie the AI down so it can't assert what it hasn't done

Having that solid core underneath allows a golden rule: the bot can only say "done" if it actually did it and holds the proof in hand. Make lying impossible, not just unlikely.

What people get wrong: they let the AI say whatever it wants and then try to catch the lies with filters. They chase the error downstream instead of preventing it upstream.

7. Rehearse with real conversations before releasing it

Gather a handful of example conversations, including the odd ones, and run them through the bot before every change. If something breaks, you find out, not a customer.

What people get wrong: they test live. Their test bench is their customers.

8. Release it gradually and watch it

Don't switch it on for everyone at once. Start with a part, with a person watching and a place to see what it's doing. Expand when it holds up.

What people get wrong: they plug it into everyone on day one and learn about the problems from the complaints.

The pattern behind every mistake

If you look closely, the person who gets it wrong isn't foolish: they do exactly the opposite of the right order, and always for the same reason. They start with the flashy part — the bot that talks nicely in a demo — and skip the boring, invisible parts: the written rules, the conversation map, where the state lives, the safety net.

And there's a perverse logic behind it. The flashy part pays off in an afternoon and you show it off proudly. The boring part isn't visible, doesn't shine, and even seems to "slow down" the project. So people optimize for what looks like progress, not for what holds the bot up when the real customers arrive.

Is this a one-off or does it happen a lot?

Here's the honest part: it happens a huge amount. It's not the exception, it's almost the default path. And not because people are careless, but for four underlying reasons.

First, today's tools make the talking demo dead easy to build. When the easy, flashy thing is to start at the end, almost everyone starts there.

Second, the failures don't show up in the demo. They show up weeks later, with real customers and odd cases. By the time the problem teaches you the lesson, you're already suffering it in production. The learning arrives late, and that's why it repeats so much.

Third, whoever builds these bots often isn't a software architect: it's the business owner, someone from marketing, or a generalist tech wiring pieces together. They're not doing it wrong on purpose; it's that "where the state lives" or "a single path to charge" isn't anyone's job in the room.

And fourth, the "ship it now" culture rewards the visible demo over the invisible foundations. Nobody applauds foundations. Everybody applauds a bot that replies.

That's why, when you see ten bots with problems, it isn't ten separate strokes of bad luck: it's almost always the same causes repeating, because nearly all of them were built skipping the same steps. What looks like an isolated incident — "sometimes it confirms appointments that don't exist," "sometimes it charges twice" — is usually the same design hole surfacing in different places.

The good news, and why this isn't inevitable: the bots that are built in the right order don't give you these scares. It's not magic or a matter of budget; it's boredom well invested at the start. The tedious part — written rules, mapped conversation, state in one place, tests before releasing — is exactly what prevents most of the disasters. It's less exciting than the demo, but it's what keeps the bot standing six months later.

Our stance

When we build bots and automations, we do the boring part first: we define the boundary, write the rules, decide where the state lives and which path actions go through, and only then put the AI on top — as an interpreter, not a blind executor. Not because we're special, but because it's the order that avoids the trouble. A bot that talks, anyone can build in an afternoon; one that acts without giving you scares is built in the right order.