What is the difference between a chatbot, copilot and agent?

A chatbot is a conversational interface. A copilot usually describes an assistant working alongside you. An agent can choose and carry out steps towards a goal. These labels overlap: a product with a chat window may also read files, use tools and take actions.

Updated, 7 September 2026: the earlier wording incorrectly treated chatbots as unable to act in other applications. This guide now distinguishes the interface from the capabilities and permissions behind it.

The Short Version

• Chatbot describes a conversational interface; copilots and agents can use that interface too.
• Compare what the system can read, change and do without further approval.
• Use the simplest setup that completes the task reliably.

The label does not tell you what the system can do

Calling something a chatbot tells you how you interact with it, but not everything connected to it. A simple text-only chatbot returns words for you to use. A tool-enabled assistant may search a database, edit a document or request an action in another service, depending on its integrations and permissions.

A copilot usually helps within a work context, such as drafting in a document or suggesting changes to code. However, the term is also a product name. Microsoft’s Copilot Studio documentation describes building agents that combine models, knowledge, tools and triggers. It would be misleading to assume that every product called Copilot only offers passive suggestions.

An agent typically has some freedom to decide which step to take next and to use tools to pursue a goal. That does not mean unlimited autonomy, access to every application, or permission to act without asking. An agent can operate within a single system and can require approval at important points.

Three questions are more useful than three rigid categories

These questions apply whether the interface says chatbot, copilot, assistant or agent. The same product can offer different modes with different capabilities. Check the mode and the account permissions you are actually using.

A workflow is not automatically an agent

A workflow can follow a fixed sequence: read a form, extract its fields and prepare a draft reply. An agent may instead decide which information to seek or which tool to call next. Anthropic’s engineering guidance distinguishes predefined workflows from systems in which the model directs its own process and tool use. There is no need to introduce that extra freedom when a straightforward workflow already does the job.

A practical example: preparing a meeting

A text-only assistant could turn the notes you paste into a proposed agenda. You would copy the result into your document. An assistant integrated with your documents might create that agenda as a draft in the right folder. An agent with suitable access could look for earlier minutes, identify missing information and prepare a calendar invitation.

Those are possible configurations, not claims that every product supports them. Sending the invitation should depend on the authority you have granted. The ability to draft an invitation does not imply permission to send it, and access to one folder does not justify access to all company files.

More capability changes the consequences of a mistake

Text-only output can still cause harm if it is inaccurate, reveals confidential information or is relied on without checking. A system with write access can also change or send something before you notice the error. The difference is not that chat is harmless; it is that tools give mistakes additional ways to affect the world.

For a new workflow, define the task, limit access to what it needs, identify actions that require review and check the outcome. Keep recoverable drafts or change records where practical. Assess the system on realistic work, including exceptions, rather than assuming that a successful demonstration proves reliability.

Worked example: a supplier invoice arrives twice

Imagine a small business receives two similar invoices from the same supplier. The following example describes possible configurations, not a claim about a particular product. The finance manager wants help checking the documents, but has not authorised a payment. That last detail matters more than the name printed on the AI tool.

With a text-only chatbot, the manager could provide appropriately redacted invoice details and ask for a comparison. The system might highlight different dates, matching amounts or a changed reference number. It cannot establish that the invoice is unpaid unless that information is supplied or accessible through a connected tool. Its answer should identify the evidence used and the uncertainty that remains.

A copilot embedded in the company’s finance software might place the comparison beside the original records and draft a message to the supplier. That could reduce copying between windows. It does not automatically make the conclusion more reliable: the wrong supplier record, a credit note or a payment recorded elsewhere could still change the answer. The manager needs a clear route back to the underlying entries.

An agent with suitable read access might search the invoice register, look for matching purchase orders and check payment status before preparing its recommendation. Its choices depend on what it finds. A missing order could trigger a request for information; a possible duplicate could be held for review. The workflow should stop at the agreed boundary. Permission to investigate an invoice is not permission to approve or transfer money.

The result to assess is therefore specific: did the system find the right records, explain the discrepancy and leave a useful draft for the manager? Counting how many steps it performed tells you much less. If a fixed duplicate-checking rule handles the job reliably, an agent may add complexity without adding enough value.

Worked example: answering a leave-policy question

Now consider an employee asking how to book annual leave. A chatbot that can retrieve the current staff handbook may be sufficient. It can explain the process and point to the relevant policy section. A product need not be highly autonomous to be useful, and a conversational answer can be well grounded when the source is current and appropriate to the employee.

The task changes if the employee asks it to submit a request. The system needs the right account, dates and approval route, as well as authority to write to the leave system. The distinction is between explaining a process and changing a record. A chat interface can support either, but the screen should make clear which action is about to happen and whether it has actually succeeded.

If the request fails because the leave service is unavailable, a useful assistant reports that failure. It should not present a drafted request as a completed booking. This is a practical test to include when evaluating a tool: interrupt a harmless demonstration workflow and check whether the user can understand what was completed, what remains pending and how to recover.

How to compare two tools fairly

Give both tools the same small, representative task and define a satisfactory result before starting. Include a straightforward case, missing information and an exception that should require human judgement. Use test records or non-sensitive material where possible. Keep a record of the inputs and outcomes so that a fluent explanation does not overshadow a wrong action.

Then compare the whole job. How much checking did the person need to do? Were sources easy to inspect? Did the system stay within its permissions? Could you undo a change? A fast first response can still create extra work if the output needs extensive repair. Equally, a slower process may be worthwhile if it produces a dependable result with less supervision.

Separate tool capability from the way you configure it. Two organisations can use the same product with very different access and approval rules. Test the actual setup you plan to use, and repeat relevant checks when those settings or integrations change. Buying a product labelled “agent” does not remove the need to decide who is accountable for the work.

What This Means For You

Choose the simplest setup that completes the task with appropriate oversight. Look past the product label and establish what it can read, what it can change and when it must ask. Those answers tell you much more about its usefulness and risk than whether the marketing calls it a chatbot, copilot or agent.

In Plain English

Imagine giving someone a desk, a filing cabinet key and a company bank card. Those are three very different levels of access. AI tools also need clear boundaries. Start by deciding which job needs doing and which access it requires, then choose the tool. A convincing answer on a screen is not proof that an action was appropriate or completed.

Related Reads

• How memory and context affect an AI answer
• What training data does and does not explain