Chatbot or assistant that can act: what’s the difference?

What is the difference between a chatbot and an assistant that can act?

The difference is structural, not a matter of how smart the software sounds. A chatbot’s job ends when it has produced a reply. Botify’s job ends when work is done: a ticket updated, a report ready, a draft waiting in the right inbox. To get there it decides which steps to take, calls connected systems, reads what they return and adjusts.

The word “chatbot” now covers two very different things, which is why the comparison gets muddled. The first is the classic rule-based bot: menus, keywords and a decision tree designed branch by branch. The second is a chat-only language model: fluent replies to anything, but only talk. Botify keeps the language model and adds tools, a controlled loop and guardrails.

A useful test: ask the system to do something that needs information it does not have and a change in another system. A rule-based bot sends you back to the menu. A chat-only assistant explains how you could do it yourself. Botify looks the information up, proposes the change and, if allowed, makes it, with a person signing off when the step is sensitive.

Rule-based bot vs chat-only assistant vs Botify: side by side

The table compares the three designs on the criteria that decide real deployments. No column wins every row: predictability and cost favour the scripted bot, while coverage and the ability to finish work favour a connected assistant.

How does Botify actually work?

Under the hood, Botify runs a loop around a language model. The model receives the request, the conversation so far and a list of tools, each described by a name and an input schema. Instead of answering straight away it can return a tool call, which the runtime executes and feeds back as a result.

Everything that keeps work safe lives outside the model: which tools it can see, who the request is on behalf of, which calls need a human decision, and what gets recorded. The model proposes; the runtime decides.

• Understand the request and the identity and role of the person making it.
• Choose a tool, for example search the mailbox, fetch an incident or query a monitoring system.
• Check the call against policy: run it, block it, or pause for human approval.
• Read the result and decide the next step, or stop if the task is complete.
• Answer with what was found and done, and record every step for audit.

When is a traditional chatbot still the right choice?

Rule-based bots are not obsolete. When the path is narrow and fully known, a scripted flow is cheaper, faster and easier to certify than any model. It also never improvises, which matters for flows where the exact wording is regulated.

• The task is a single fixed path: track a shipment by number, book a slot from a list, reset a password.
• Volume is very high and margins are thin, so a model call per message does not pay for itself.
• Every reply must be pre-approved wording, for example in some financial or medical disclosures.
• There is no system to act on and no written knowledge to answer from.

When do you need an assistant that reaches your systems?

A connected assistant earns its cost when the questions cannot be enumerated in a tree and the answer lives in systems, not in a script. IT operations is a typical case: “why did checkout slow down at 14:00?” requires pulling problems from monitoring, related incidents and recent changes, then lining them up.

• Requests are open-ended and phrased in many ways, including Arabic dialects and mixed Arabic and English.
• The answer requires looking things up across several systems.
• The job is only done when something changes: a draft is written, a ticket updated, a report produced.
• You already have written knowledge, such as policies, runbooks and support history, that can be retrieved from.

What changes when software can act?

A chat-only assistant’s worst outcome is a bad sentence. An assistant that can act has a worse outcome: a bad action, an email sent to the wrong person, a record changed, a customer called. That shifts the design question from “is the answer good?” to “what is this system allowed to do, for whom, and who signs off?”

The controls that answer it are familiar from any access-controlled system: identity on every request, permissions per tool, approvals for anything irreversible or external, and an audit trail. Botify applies these per tool: each tool carries a risk level (read, write, destructive or external_send) and an approval mode, so gmail.search runs directly while gmail.send always waits for an authorised person to approve or reject it.

A second risk is indirect prompt injection: an email or web page Botify reads can contain instructions aimed at the model. Treat everything a tool returns as data, not as commands, and keep approvals on actions that leave the organisation.

Can you combine a chatbot and Botify?

Yes, and mature deployments usually do. Keep fixed flows for the few high-volume or tightly regulated tasks where predictability is non-negotiable, and route everything else to Botify so people can look things up and get work done through conversation.

Design the seams deliberately. The scripted flow should hand over the context it already collected, and Botify should hand off to a person, with a summary, when it reaches the edge of its permissions or confidence.