Chatbot, assistant or AI employee: what is the difference?

Picture three things at the front of an office.

The first is a bell on the counter. You ring it, and a recorded voice reads you the opening hours. It is useful, it never gets tired, and it cannot do anything else.

The second is a helpful stranger in the waiting room. Ask them anything and they will give you a thoughtful answer. But they do not work here. They cannot open the files, they do not know how this office does things, and when you leave, nobody has a record of what they told you.

The third is a colleague at the desk. They have a job title. They follow the office’s procedure. They can open the system and update your record. Their manager can see what they did, and a few decisions go to the manager before they are made.

That is roughly the difference between a chatbot, an AI assistant and an AI employee. Vendors use all three words loosely, so this post pins them down in practical terms, then lists the parts an AI employee needs and which of them Wetel has today.

The short answer

A chatbot answers questions. An assistant helps the person in front of it think and write. An AI employee does a defined piece of work inside your systems, following a procedure you can read, with a person in your company in charge of it.

None of these is “better” in every case. If customers only ask where you are and when you open, a bell is the right tool. The trouble starts when a business buys a bell and expects a colleague.

A chatbot answers; it does not act

A classic chatbot matches a question to an answer. Newer ones use a language model and sound far more natural, but the shape is often the same: words in, words out.

What is usually missing is everything after the answer:

• It does not act in your systems. It can tell a customer how refunds work. It cannot look up their order, check the status or log the request.
• It has no procedure. There is no written sequence it follows, so there is nothing for you to read, review or correct when it goes wrong.
• It leaves no useful record. You may get a transcript. You rarely get “here is what it checked, what it found and why it said that.”

That is fine for a bell. It is not fine for work you would otherwise give to a person.

An assistant helps the person in front of it

An AI assistant is the helpful stranger: a general model you talk to, which drafts an email, summarises a document or explains a policy. It is very good at that, and many teams already use one daily.

But an assistant works for whoever is typing, one conversation at a time. It does not hold a job in your company. It does not run your procedure the same way every time. The person using it is the one who copies the answer into the real system, checks it and takes responsibility for it.

That is the key line: with an assistant, the person does the work and the AI helps. With an AI employee, the AI does a defined part of the work and a person supervises it.

An AI employee has a job, and a manager

An AI employee is closer to the colleague at the desk. It has a role, it follows a procedure, it works in your systems, and somebody in your company is in charge of it. That last part is not optional. An AI employee without a manager is just an automation nobody is watching.

If you want the vocabulary underneath this (tools, workflows, skills, agents), we wrote a separate guide: Tools, workflows, skills, agents: the words everyone uses differently.

The parts of an AI employee

It helps to think of an AI employee as a set of parts, the way you would think about a new hire: a job description, training, access, a desk, a manager. Here is each part, and its status in Wetel today.

1. A role. Who it is and what it is for. In Wetel, every agent has a name, a position, a persona (its identity, tone and limits) and a use case. The persona says who the agent is, not what steps it takes. Live today. (Agents)

2. A procedure you can read. The steps it follows, written as a workflow: a graph of steps such as “classify the request, look up the order, reply, end.” You can open it, read every branch and change it. A workflow does nothing until someone publishes it, so a draft cannot quietly go live. Live today. (Workflow overview)

3. Knowledge. Your own documents, so its answers come from your policies rather than general guesses. In Wetel this is a knowledge base attached to a step in the workflow. Live today. (Knowledge base)

4. Skills in your systems. The ability to do things, not just say things: look up a record, check availability, create a task. In Wetel a workflow step calls your system through a connection you register, either a tool server or a plain web address with your own credential. Wetel also keeps a catalogue of pre-checked operations for some business systems. Live today. (Connecting tools, certified operations)

5. Access, inside your own workspace. Every agent belongs to one workspace, and nothing crosses that boundary: a request for one workspace cannot see or affect another’s data. The credential you give a tool server connection is stored and never returned by any query. People in a workspace are owners or members, and some actions are for owners only. Live today. (Multi-tenancy)

6. Somewhere people can reach it. A web chat or avatar you embed, your own app through the API, or a messaging app connected directly. Voice notes can be turned into text and replies into speech. Live today for these. Phone calls are not built yet; they are on the roadmap. Only one messaging app is live today; the others are listed but not shipped. (Channels)

7. Supervision. A manager who can see what happened and step in where it matters. In Wetel today:

• A record of every run, step by step, so “done” can be checked against what actually happened. (Observability)
• An approval step you add to a workflow, where the run pauses until a workspace owner approves or rejects it. It is a step you put in, not a default; nothing pauses on its own. Notices are in-app; email notice is not available yet. (Approval node)
• A per-agent view of what each agent handled: runs by status, recovered failures, open questions waiting on a person, and a flag when an agent needs attention. (Agent activity summary)

Not built yet: how those numbers trend over time, and alerts that tell a manager an agent needs a person without them having to look. Approvers are workspace owners only today.

For where the line between “do it alone” and “ask first” should sit, read Supervised or autonomous? What an AI employee should be allowed to do on its own.

8. Work on a schedule. A real employee does not only answer when spoken to. In Wetel a workflow can run on a timer (every weekday morning, the first of the month) with no message involved. Each schedule is bounded by your plan, a monthly spend cap and an automatic stop after repeated failures. Live today. Starting work because something happened in another system (“when a record changes, run this”) is not built yet. A schedule that stops itself does not send a notice today, so someone has to check. (Scheduled workflows)

What an AI employee in Wetel is not, yet

Being honest about the gaps matters more than the list above.

• It does not ask first by default. It pauses only where someone has added an approval step.
• It does not carry working notes from one message to the next. By default only the conversation transcript carries over between turns; a step can wait for a specific answer, but there is no general memory of facts it worked out earlier. (How continuity works)
• It is not a replacement for your team. It takes on a defined piece of work, and a person stays accountable for it.

Which one do you need?

Ask what you want to happen after the answer.

• If nothing needs to happen, and the questions are always the same, a chatbot is enough.
• If a person on your team needs help writing or thinking, an assistant is the right tool.
• If a piece of work needs to be done in your systems, the same way every time, with a record and a manager, you are describing an AI employee. Start with one job, write down the steps, decide which steps need a person’s yes, and name the person.

If you already know which job that is, tell us which work you’d hand over first.

Related reference docs

• Core concepts: workspaces, agents, workflows and sessions, and how they fit together
• Agents: the role, persona and use case of an agent
• Workflow overview: the procedure as a graph of steps, and publishing
• Knowledge base: grounding answers in your own documents
• MCP connectors: giving a workflow tools in your own systems
• Approval node: a step that waits for a workspace owner
• Scheduled workflows: running work on a timer, with cost controls
• Roadmap: what is not built yet, including phone calls and event triggers