AI agent vs chatbot vs copilot vs assistant: what happens after the conversation

The first explains the returns policy and asks for an order number.

The second helps an employee write a reply.

The third sits inside the support platform, pulls up the order, summarises what happened last time this customer got in touch, and suggests what to do.

The fourth checks the order, looks at the photographs, creates the replacement, updates the record and emails the customer to say it is on its way.

Same request. Same chat box, more or less. The last one changed your inventory and contacted your customer. The first one did not do anything at all.

That gap is the whole subject, and it is not a gap in intelligence.

The shortest version

A chatbot answers from a body of material it can search.

An assistant works on whatever you bring it.

A copilot does the same work, but from inside the tool you are already using.

An agent carries out multiple steps towards a goal, using systems it has been given access to.

If you remember one sentence, make it this one: the categories are not ranked by how good the answer is, they are ranked by what happens after it.

One more word belongs here, and it is not a fifth category. Agentic is a property, not a product: it describes whether a system decides its own next step or follows a path somebody drew for it. An agentic workflow can sit inside any of the four above, which is why seeing agentic AI on a pricing page tells you something about the behaviour on offer and nothing about which of these you are buying.

One request, four systems

Take the damaged order through each in turn. The scenario is deliberately ordinary, which is the point: nothing about it is exotic, and the tools in play sit on our customer support shelf.

Same message, same box, four different amounts of access.

The chatbot recognises this as a returns question. It gives the policy, asks for the order number, and either resolves the enquiry from a script or passes it to a human. It is working from a body of material it can search. It has not opened your order system, because it cannot.

The assistant is somewhere your employee goes. They paste in the customer's message, explain the situation, and ask for a reply that is apologetic but does not promise a refund. They get a draft. It is a good draft. It is still just text, and the employee still has to do everything else. An AI assistant is a place you go to and ask.

The copilot is the same help, delivered where the work already is. Nobody pastes anything, because the copilot is in the support platform and the ticket is already in front of it. It reads the order, notes that this customer has had one previous damaged delivery, and recommends a replacement rather than a refund. The distinguishing feature of an AI copilot is placement rather than capability: it starts with your work in front of it instead of asking you to describe it.

The agent is given the outcome rather than the task. Resolve this. It checks the order is real and within the returns window, looks at the photographs, decides a replacement is warranted, creates the replacement order, writes the case notes, and sends the confirmation. Somewhere in there it may stop and ask a person, if it was set up to. An AI agent is a system given a goal rather than a question.

Notice what changed between the third and the fourth. Not the quality of the reasoning. The copilot understood the situation perfectly well. The difference is that the agent had a login.

The set of things an automated system is permitted to do, decided by the access it holds rather than by the instructions it was given.

That sentence is the most useful thing on this page. Everything else is commentary on it.

Conversation is not the dividing line

It is tempting to sort these by how the conversation feels. Fluent and helpful must mean advanced; scripted and rigid must mean basic. That instinct is wrong often enough to be dangerous, because the chat window is the one part of the system you can see and the one part that tells you least.

All four categories can have the same interface. What varies is what sits behind it:

• whether it can look things up, and where
• whether it can generate content
• whether it is connected to your other systems
• whether it remembers anything between sessions
• whether it can plan a sequence rather than produce one output
• whether it can call tools and act on what they return
• what it is permitted to do with all of the above

A very articulate system with none of these is a chatbot with a good voice. A blunt, terse system wired into your CRM with write permissions is an agent, whatever it sounds like. Eloquence is not a capability.

What actually makes something an agent

An agent is a loop, not a feature.

The honest technical answer is a loop rather than a feature. A system that produces one answer and waits is not an agent, however sophisticated the answer. The agent loop goes:

1. take a goal
2. break it into steps that can be acted on
3. choose the next action
4. use a connected tool to carry it out
5. look at what actually happened
6. decide what to do next in light of that
7. stop when the goal is met, when a person needs to approve something, or when something has gone wrong

Step five is the one that matters, and the one to ask a vendor about. A system that fires off an action and assumes it worked is automation with a language model bolted to the front. A system that reads the result and changes its plan is doing the thing the word agent is meant to describe.

Step two is where a failure can begin. Task decomposition is where a goal becomes a sequence, and a bad split produces confident, well-executed steps towards the wrong outcome. The failure is rarely visible at the point it happens.

Why the labels do not help you

None of these words is defined by anyone with authority to define it. They are marketing categories, and they drift.

A product called a copilot may be an assistant in a side panel. A chatbot may quietly have agentic features, because it can now issue a refund. An assistant becomes an agent the moment somebody connects it to a system and grants it permission, with no change to the model. Protocols such as MCP exist precisely to make that connection easy, which means the boundary is one a customer can now cross without writing any code.

So do not buy the noun. The useful questions are behavioural, and there are six:

• What can it read?
• What can it change?
• Can it complete several steps without coming back?
• Does it wait for approval, and at which points?
• Can it tell that an action failed, and do something about it?
• Who is accountable when it gets one wrong?

Those questions have the same answers no matter what the product is called.

The ladder is autonomy, and autonomy is the risk

Each rung adds value and adds exposure, in the same movement. This is not a reason to stay on the bottom rung, but it is a reason to know which one you are on.

Answering questions reduces repetitive load. The failure is a confident wrong answer, and confident wrong answers are worse than no answer because they are acted upon.

Drafting work saves real time. The failure is plausible, unsuitable content that a busy person approves without properly reading.

Recommending actions improves decisions. The failure is a good recommendation from incomplete context, which is harder to catch than a bad one because the reasoning looks sound.

Taking actions automates whole workflows. The failure changes records, spends money, or contacts customers, and it does so at machine speed and machine volume.

What governs this is not a property of the model. Autonomy level is how much a system may do before it has to ask, and it is the single setting that moves both the value and the risk of running one. It is usually configurable, so it is worth knowing what yours is set to.

Which one does the job you actually have

The most useful advice here is unfashionable: most tasks do not need an agent.

Choose a chatbot when the questions are predictable and the job is to answer them consistently at volume. It is cheaper, it is easier to test, and its worst case is an unhelpful reply. Our customer support and chatbot shelf is mostly this.

Choose an assistant when the work is varied, individual, and changes shape every time. Judgement stays with the person, which is right when the task is not stable enough to encode.

Choose a copilot when your people already live inside a particular piece of software and the friction is context switching rather than capability. The gain here is mostly that nobody has to re-explain the situation.

Choose an agent when the workflow is repetitive, the success criteria are measurable, and the permissions can be drawn tightly enough that the worst case is acceptable. Those three conditions travel together. If you cannot say what success looks like, you cannot evaluate the agent, and agent evaluation asks whether a whole multi-step job was completed, which is a harder question than whether any single answer in it was good.

The rule of thumb: use the simplest system that can do the job reliably. Autonomy you did not need is pure downside.

Before you buy an agent, ask these

This is the part worth keeping. If a vendor cannot answer these clearly, that is itself the answer.

1. Which systems can it read? A real answer names systems and the scope inside each one, such as the calendar read-only and the orders table read and write. A category name is not an answer.
2. Which actions can it take? A real answer is a list of verbs bound to a system, such as create a replacement order, refund up to a ceiling, write a case note. Scope of action is decided by the access it holds, not by the instructions it was given.
3. Which actions require a human? A real answer names the actions rather than setting a global switch, such as anything that moves money, contacts a customer, or deletes a record. An approval gate belongs where a mistake would be costly, not everywhere, and not nowhere.
4. What happens when a tool call fails? There are four behaviours available, which are retry, escalate, stop, and carry on regardless. Only the last is disqualifying, so ask about it directly rather than waiting for it to come up unprompted.
5. Is every action logged, with enough detail to reconstruct why? A usable record holds the action, the data it acted on, the tool it called and the result it read back. A log of what happened without why is not an audit trail.
6. Can permissions be narrowed per task? Per task rather than per installation, so that something issuing a refund does not also hold whatever access it would need to edit a price list. Ask about containment as a separate question, because permission decides which actions are attempted and sandboxing decides what is within reach when one of them goes wrong.
7. Can it spend money? If yes, the answer has three parts, which are the ceiling, who is able to change it, and whether the payment system enforces it or only the instructions do.
8. Can it contact customers unsupervised? A real answer is two lists, which are the channels it can send on and the events that cause it to send. Ask before deployment rather than after.
9. How is sensitive data handled when it passes through the model? A real answer covers where it goes, how long it is kept, and whether anything is trained on it. An answer to only the first is a third of an answer.
10. Can a person stop it mid-run? Stopping and undoing are different questions, so a real answer also covers what becomes of the work already in flight when the switch is thrown. A kill switch is useful in proportion to who can reach it and whether anybody has ever tried.
11. Can its actions be reversed? Every action is reversible, compensable, or neither. A settled charge is compensated with a refund rather than truly reversed, and an email cannot be undone at all, so anyone who treats those as the same has not looked. Ask for the rollback plan, and ask whether it has been tested.

Questions two, three, ten and eleven are the load-bearing ones. Everything else can be fixed later.

Common questions

What is the difference between an AI agent and a chatbot?

A chatbot responds to messages within a conversation. An agent pursues a goal across several steps, using systems it has access to, and can change things outside the conversation. A chatbot that has been connected to your order system and given permission to issue refunds has stopped being only a chatbot.

Is ChatGPT an agent or an assistant?

It depends entirely on how it is configured. Used as a place you go to and ask, it is an assistant. Connected to tools and given a multi-step goal, the same product behaves as an agent. This is why the product name answers nothing.

Is a copilot the same as an assistant?

They overlap heavily. The distinction that holds up is placement: an assistant is somewhere you go, a copilot is already inside the tool you are working in and starts with your work in front of it. Vendors do not apply the words consistently.

Can a chatbot also be an agent?

Yes. The chat interface is unchanged; what changed is the connections behind it. Judge by access, not by appearance.

Do agents work without human supervision?

Some can. Whether they should is a separate question, and it is answered per task rather than per product. Human in the loop describes the arrangement where a person confirms at defined points, which is the usual sensible default for anything touching money, customers or records.

What are examples of agents in business?

Support workflows that resolve a request end to end, coding agents that make changes across a repository, research agents that gather and reconcile sources, and operational agents that move data between systems. Our automation and agents category and the agents and automation shelf cover the tools in this space.

Are agents safe?

Safety is not a property of the category. It is a property of the permissions, the guardrails, the approval gates and the logging you put around it. A tightly scoped agent doing one reversible job is safer than an assistant with an over-broad integration.

When should a business use an agent?

When the workflow repeats often enough to be worth encoding, success can be measured, and permissions can be drawn so the worst plausible mistake is one you can live with and undo.

The question underneath all of this

Every one of these systems will keep getting better at conversation. That improvement tells you nothing about which one to buy, because conversation was never the variable.

What varies is what you hand over. Access to information. Access to systems. Permission to act. Responsibility when it goes wrong.

Do not choose based on what the vendor calls it. Choose based on what it can reach, what it is allowed to change, and how much control the task genuinely requires you to keep.

---

Agentarius is an independent AI discovery, comparison and learning platform. We define the vocabulary of this shift, including agents and autonomy, in the Agentarius AI Glossary, and cover the tools themselves in the catalogue.