AI agent vs chatbot: decide what the software may do first

A supplier demo ends and the salesperson has said "agent" a dozen times. The previous vendor called a very similar product a chatbot. A third calls theirs an assistant. For an owner deciding whether to put any of them in front of customers, the names settle almost nothing.

What matters is narrower and easier to check: for each task, what is the software allowed to do? Reply from approved text? Look something up in your systems? Prepare a draft for a person? Carry out an action once someone agrees? Or carry it out on its own? Those five permissions, set task by task, decide both the usefulness and the risk. The product category decides neither.

Why the label misleads

The usual distinction is fair as far as it goes. A chatbot answers inside a conversation; an agent uses connected tools, carries information from one session to the next, works through several steps and hands over to a person when a decision matters. That is roughly where a comparison of chatbots and AI agents for SMEs draws the line.

In practice the line moves around. A product sold as a chatbot may read your booking calendar. One sold as an agent may be set up to do nothing but answer. And a single tool often belongs on both sides at once: fine to answer menu questions alone, not fine to confirm a booking without a person. Buying "an agent" or "a chatbot" does not settle any of these questions. Writing them down does.

Five permissions, from narrowest to widest

• Answer: replies from approved, fixed text. Opening hours, delivery area, what a standard package includes. It reads nothing from your systems and changes nothing.
• Look up: reads live information to answer. Is Thursday free? Is the order ready? It still changes nothing, but it can now reveal information, so what it may read matters.
• Draft: prepares a reply, quote or record update for a person to finish. Nothing leaves the business until someone sends it.
• Act with approval: sends the message, creates the booking or updates the record, but only after a named person agrees to that specific action.
• Act alone: carries out the action without a per-item check, inside limits you set, with a record of what it did.

Each step up saves more time and moves more of the risk off the screen and into the world. A wrong answer at "draft" costs a minute of editing. A wrong answer at "act alone" may be a booking you now have to honour, or a customer who has been told something you would never have said.

Add a sixth setting to every list: not permitted. Some tasks should sit outside the software's reach entirely, and saying so explicitly is part of the decision.

Worked example: a caterer's permission sheet

Take a fictional corporate caterer in Tai Seng with 14 staff. Enquiries arrive through a website form and a WhatsApp number, mostly from office managers ordering lunches and event buffets. The owner, Farah, is comparing two tools. Rather than asking which one is "really" an agent, she lists the tasks enquiries actually produce and gives each a permission:

1. Menu contents, labels on standard items and the delivery area: answer, from the published menu and a short FAQ.
2. Whether a date has kitchen capacity: look up, reading the production calendar only. It may say a date "appears to be open" but never confirm it.
3. Quotes for standard packages: draft. Prices come from the current price list; the sales coordinator checks the headcount and sends.
4. Custom menus, complaints and any allergy question beyond the printed labels: draft at most, flagged to Farah. The tool never answers an allergy question on its own.
5. Confirming a booking and requesting a deposit: act with approval. The coordinator approves each one.
6. Day-before delivery reminders for confirmed orders: act alone, from a fixed template, with every send logged.
7. Changing the menu or the price list: not permitted.
8. Refunds and credit notes: not permitted; a person handles them in the accounting system.

Nothing on this sheet depends on what either vendor calls its product. With the sheet in hand, Farah finds that Tool A handles tasks 1 to 3 well but cannot limit which calendars it reads. Tool B could cover all eight, but in the demo it sends replies without review. She now has one precise question for Tool B's vendor: can sending be held for approval task by task? The firm, its tasks and both tools are invented for illustration.

Questions that test permissions in a demo

Ask the vendor to show, not describe, each of these:

• What exactly can it read, and can we narrow that to particular calendars, folders or fields?
• What can it change or send, and can each action be set separately to off, draft, approval or automatic?
• Where do approval requests appear, and who is allowed to approve them?
• What record is kept of what it read, drafted and sent, and who approved it? Can we export that record?
• When it is unsure, does it hand over to a person, and with what context?
• Can we switch one task off without switching off the rest?

If the answers stay vague, treat the product as answer-only until they are not. A tool you cannot limit task by task forces a choice between too little and too much.

When answer-only is the right setting

The narrowest setting is sometimes the correct one. If most questions have one fixed answer, arrive through a single channel and never depend on live stock, calendars or order status, a scripted tool may be all you need. The same chatbot-versus-agent comparison makes this point: such a tool is simpler and more predictable, and there is nothing to approve because it cannot act.

Move a task up a level only when the step removes real work and you can see its mistakes. The test in our guide to a first AI pilot applies here: count the time spent checking, not just the time saved drafting. Then review the permission sheet whenever you add a task, change a system the tool reads, or find it doing something the sheet did not anticipate.

Common questions