AI Copilot vs Agent vs Chatbot FAQ
A chatbot replies, a copilot drafts beside a person, an agent acts under permissions — buy the shape that matches who is in the loop, not the word on the vendor slide.
A chatbot answers questions. A copilot sits next to a human and drafts, suggests, or retrieves so the human still clicks send. An agent reads context and takes actions in your systems under scoped permissions, with evals and a fallback. Microsoft 365 Copilot and GitHub Copilot are copilots; they are not production agents for your order system. Pick by who is accountable for the next state change.
The taxonomy
If you only need the split: chatbot talks, copilot assists, agent acts, RPA follows a script. The rest of this page is when each is the right buy.
What is an AI copilot?
Software that sits in a person’s existing workflow and drafts, summarises, or retrieves so the person remains the one who sends, merges, or files. The model is a margin, not a coworker with credentials. GitHub Copilot in the editor and a “draft reply” button in the helpdesk are copilots. If it can file the ticket, refund the order, or email the customer without that click, you have crossed into agent territory.
What is the difference between a chatbot, a copilot, and an agent?
A chatbot is a conversation surface that replies. A copilot is that surface (or an inline panel) whose job is to help a specific role finish work they still own. An agent chooses tools and can change systems of record under permissions you issue, with evaluation and a human fallback. You can wrap an agent in a chat UI; the UI does not make it a chatbot. Buy from the action and the accountability, not from the window chrome.
When is a copilot the right buy?
When the cost of a wrong send is high, the UI already exists, and the bottleneck is drafting or finding, not executing. Lawyers, investigators, developers, and agents-on-the-phone often want a copilot first. You get value without opening write APIs. If nobody will sit in that chair, a copilot has no user and you wanted an agent — or you wanted nothing.
When do we actually need an agent?
When the work is a bounded workflow with a numeric success metric and the next step is a tool call: create the ticket, look up the order, write the CRM object, route the claim. If the human would only rubber-stamp, you are paying for theatre and should either automate under evals or stop. The agents FAQ covers how that system is built; this question is whether you should.
Is Microsoft Copilot or GitHub Copilot an agent?
No. They are copilots: they propose code or Office actions in a human’s session, with the vendor’s grounding and admin model. They can feel agentic when they run a loop in the editor, but they are not your production agent on customer records with your eval suite. We do not resell those seats. We implement systems in your stack, which may sit beside them.
For internal knowledge, should we buy a chatbot or a copilot?
If employees live in Slack or a search box and just need cited answers, a grounded chatbot (RAG) is the smaller system. If they live in the ticket, the IDE, or the claim form, put retrieval in that UI as a copilot so they do not context-switch. Same index, different surface. A floating “Ask HR” bot that nobody opens is how intranet chat dies.
Can one system be both a copilot and an agent?
Yes, in sequence. Shadow and propose in the copilot, then open scoped write tools when the eval holds. Many helpdesk builds do exactly that: draft reply first, “send and tag” later. It is still two permission sets and two metrics. Calling the whole thing “Copilot” in the steering deck is how write access lands without a gate.
Choosing and scoping the shape
Week one is a decision: who is accountable for the next state change. The build follows that sentence.
How do copilots get grounded in our data?
The same retrieval rules as any RAG system: permissioned chunks, citations, refuse when retrieval is empty. A copilot that drafts from the model’s memory is a liability with a friendly name. Vendor copilots use their connectors; custom copilots use your index. We build the latter in your VPC. We do not magically extend M365 Copilot’s graph beyond what you licensed.
Do copilots take actions?
They should not, except as an explicit, separately gated feature. The point of the copilot shape is that the human still owns send, merge, and file. “Copilot that also executes” is an agent with marketing. If you want actions, name them, scope the tools, and measure task success. Do not hide a write API behind a Copilot button.
How do you measure a copilot versus an agent?
Copilot: acceptance rate of drafts, time-to-complete for the human, factual error rate on accepted text, and whether people actually open the panel. Agent: task success, missed-escalation, eval-gate pass rate, cost per resolved workflow. Mixing CSAT from a chatbot trial with write-agent success is how programmes fake a win. Pick one primary metric in week one.
Will a copilot replace our helpdesk?
A copilot makes human agents faster. It does not take the queue. An agent on high-volume intents can take a slice of the queue and escalate the rest. Teams that buy M365 Copilot and expect deflection numbers get neither. If deflection is the goal, you are in the customer-support agent conversation, not the copilot conversation.
What do you need from us to choose the shape?
One workflow, who currently does it, what system of record changes, and what a wrong change costs. A 45-minute first call is enough to say copilot, agent, chatbot, or RPA. We need a process owner and an engineer only after that call, when there is a build. If you cannot name the workflow, you are not buying software yet.
How is a copilot priced versus an agent?
Vendor copilots are usually per-seat subscriptions you buy from Microsoft, GitHub, or similar — we do not resell those. A custom copilot or agent is our fixed-scope implementation plus platform subscription, quoted in writing. Inference is yours to the model provider, no token markup. Per-seat and per-workflow commercials should not be blended into one mystery number.
In four weeks, should we ship a copilot or an agent first?
Whichever matches the accountability you actually have. If write access will not pass security in a month, ship a copilot (draft + retrieve) in the four-week shape: discovery, environments, shadow, handover. If the workflow is bounded and tools exist, ship a read-then-write agent on one intent. We will not spend the month renaming an agent a copilot to dodge a review.
Running the shape you bought
Production is permissions, a gate before writes, and the honesty to change shape when the metric says so.
How do permissions differ for a copilot?
A copilot should see what the signed-in user can already see — the same IdP, the same ACL at retrieval. It should not run as a service account that can draft from everyone else’s files. That incident looks like a helpful summary of a salary doc. Agents add tool scopes on top. Copilots fail more often on retrieval ACL than on tools, because they have none.
Is human-in-the-loop different for copilots and agents?
A copilot is human-in-the-loop by definition: the person is the loop. An agent needs an designed queue for low-confidence and high-stakes cases, because the human is no longer in every turn. If your “agent” still needs a click on every action, you built a copilot and should measure it as one. Both still need evals on the text they produce.
Does shadow mode apply to copilots?
Yes. Show the draft beside the current process, store whether the human accepted it, score it, and only then make the panel the default. Shipping a copilot to all seats on day one is how you get unused licenses and a few leaked drafts. Acceptance rate is the shadow-mode metric. Four-week pilots should include that number, not just a screenshot.
Who owns a custom copilot after handover?
You do: prompts, index, evals, UI hooks, runbooks. Vendor copilots remain the vendor’s product; you own configuration and the data you put in them. We hand over artefacts from what we built, plus 30 days of on-call. There is no lock-in that requires us to keep the panel running.
Will we be locked into Microsoft or OpenAI if we start with their copilot?
You will be locked into their connectors, admin, and data path for that product. A custom agent we build is model-agnostic and runs in your cloud. Starting with M365 Copilot is a valid seat-level experiment; it is a poor foundation if you already know you need write tools on a system Microsoft does not connect. We will say that on the first call rather than ripping out seats you just bought.
When should a copilot project become an agent?
When acceptance is high, the remaining work is repetitive execution, and you can name a task-success metric. That is a permission and eval change, not a rebrand. If acceptance is low, adding write access will not save it. We treat the upgrade as a scoped increment, often inside the same four-week rhythm on one intent, not a new platform.
The same words in different teams
Support, sales, and engineering all say “copilot.” They do not mean the same buy.
In support, should we buy a copilot for agents or a customer-facing agent?
Buy the copilot if your constraint is handle time for humans who will stay on the ticket. Buy the customer-facing agent if you have high-volume intents, a policy corpus, and a plan to escalate identity and billing. Many orgs need both, in that order. The customer-support FAQ is the domain companion; this is only the shape choice.
Is a sales copilot the same as a voice agent?
No. A sales copilot sits in the CRM and drafts emails or next steps for a rep. A voice agent takes or places calls and writes a structured lead. Different latency, disclosure, and transfer problems. If the rep must stay on the call, you wanted a copilot in the ear, which is a harder product than people think. Do not buy one and expect the other.
How is a coding copilot different from a code-review agent?
A coding copilot autocompletes in the editor; the developer still commits. A code-review agent comments on the pull request against your standards and can fail CI. One is a seat productivity tool, often vendor. The other is a workflow with an eval against senior review. We implement the second. We do not resell GitHub Copilot.
Where does RPA sit versus copilot and agent?
RPA is a flowchart for deterministic clicks. Keep it for stable, high-volume transactions. A copilot helps a person; an agent handles messy language and tool choice. Replacing a working bot with an LLM because the slide said “agentic” is how you buy latency and variance. We will recommend RPA when the branch already exists.
How do we choose in the first meeting?
We ask what record changes, who is accountable, and how you will know it worked. Chatbot if it is Q&A. Copilot if a person stays in the chair. Agent if a tool should fire under policy. RPA if it is already a flowchart. If those answers are muddy, we will not start a four-week build. Bring the workflow, not a vendor shortlist.
Teams search “copilot vs agent” because vendors use the words interchangeably. The useful split is autonomy and write access: chatbots talk, copilots assist a person in an existing UI, agents change records through tools. RPA remains the flowchart. ReinforcedX implements production systems in your stack — often a copilot first, then write tools once evals hold. We do not resell Microsoft or GitHub Copilot. For the mechanics of agents (tools, shadow mode, ownership), use the AI agents FAQ; this page is the buying taxonomy.
Keep reading
Ready to refine
your workflow?
Share your current process. We’ll help you identify what can be automated — and where efficiency can be reclaimed.