Three product categories are being sold under interchangeable names right now: copilot, agent, assistant, chatbot. The words are doing no work. What does do work is a pair of questions you can ask about any of them, and the answers split the category cleanly.
Who starts the work? And who commits the write?
The two questions that define the boundary
An AI copilot is invoked by a person and returns output that the person accepts, edits or discards. A copilot does not decide to act; it decides what to propose, once, and then stops. Initiation is human, commit is human.
An AI agent is given a goal and decides its own path to it: read a record, work something out, draft something, change something, read again. Initiation may be human or automatic, but the commit authority can belong to the agent. That single difference is what turns a software category into a governance problem.
Everything else people cite as the distinction — reasoning quality, context window, model tier — is a spectrum. Commit authority is binary. Either the write reaches your system of record without a human accepting it, or it does not.
Copilot, agent, chatbot side by side
| AI copilot | AI agent | AI chatbot | |
|---|---|---|---|
| Who starts it | A person, deliberately | A goal handed to it | An inbound message |
| Where it lives | Inside a surface you are already using | Across the records it has tools for | Inside one conversation |
| Number of model calls | One per invocation | Many, one per reasoning step | One per turn |
| Chooses its own next step | No | Yes | No; it follows the flow it was given |
| Commits the write | No. You do | Yes, if its autonomy allows | Only through explicitly configured action blocks |
| Worst realistic failure | A bad suggestion you accept without reading | A wrong action taken at scale | A wrong answer to a customer |
| Needs run ceilings | No loop to bound | Always | Rate limits, not step limits |
| Needs an autonomy setting | No | Yes | No |
The row that matters is the fifth. A copilot’s worst day is a human rubber-stamping something they should have read. An agent’s worst day is a sequence of writes nobody read at all.
The failure case: a copilot that quietly became an agent
Here is the specific way teams get hurt, and it is not by choosing wrong. It is by a product changing category underneath them.
A team adopts a drafting copilot in their help desk. It suggests replies; agents read them, edit them, send them. Safe, popular, no governance required. Six months later the vendor ships an “auto-send for high-confidence replies” toggle, and somebody turns it on, because it is framed as a productivity setting rather than an authority change.
The tool is now an agent. It initiates on an inbound ticket and commits an outbound customer email with no human read. Nothing about the model changed. What changed is that the failure mode moved from a bad draft a person catches to a bad message a customer receives, and the team’s controls were designed for the first one. There are no step ceilings, because a copilot never needed them. There is no approval queue, because a copilot never needed one. There is no per-run trace, because a copilot’s trace was the human sitting in front of it.
The lesson is procedural: treat any toggle that removes the human accept step as a category change requiring the same review you would give a new vendor. We wrote about the decision framework in when not to automate.
Why the loop is the real technical difference
A copilot makes one model call. Whatever it returns, it returns; there is nothing to bound, because there is no second iteration in which a mistake could compound.
An agent’s defining machinery is the loop: reason, choose a tool, call it, observe what actually came back, reason again. That loop is powerful for the same reason it is dangerous — it can recover from a failed step, and it can also chase a wrong conclusion through six steps of increasingly confident tool use.
So an agent needs numbers a copilot never needed. In Oneop, AI agents run under four published ceilings: six reasoning steps by default with a hard cap of twelve, a 6,000-token budget, forty-five seconds of wall clock, and three write actions counted across the whole run. A fifth check ends the run as no-progress when two identical observations come back in a row, which is what a loop looks like from the inside.
Hitting any ceiling ends the run as escalated with the trace kept, rather than pushing on to produce something. That is the design position worth stealing even if you build your own: an agent that cannot finish should stop, not improvise an ending.
Where the write actually happens
The cleanest way to classify a tool is to find the line of code where your record changes, and ask what had to be true for that line to run.
For a copilot, the answer is always “a person clicked accept”. For a chatbot, the answer is usually “the flow reached an action block a builder deliberately placed there”. In Oneop, those chatbot write actions are capped at five per conversation per ten minutes at the engine level, because a conversational surface with unbounded write access is an agent wearing a chatbot’s label. The chatbot half of that boundary is covered in AI agents vs AI chatbots, and the flow builder itself is on the AI chatbot page.
For an agent, the answer depends on a setting. Oneop resolves it at a single governed dispatch point using the agent’s autonomy mode: suggest records the proposal and writes nothing, approve creates a durable queue row that expires after forty-eight hours if nobody touches it, and autonomous dispatches immediately. Money and stock actions are refused at that same dispatch point regardless of the mode, and regardless of whether a human approved them, until that entire class is deliberately switched on. The three-position model is set out in autonomy levels: a governance model for AI at work.
The evaluation questions to actually ask
Skip the category label on the pricing page. Ask these:
- Does it start itself? If yes, what event or schedule, and can you see the list?
- Can it write to my system of record without a human accept? If yes, under what setting, and who can change that setting?
- How many model calls can one unit of work make, and what stops the tenth?
- When it stops, what is stored? A summary the model wrote about itself is not a trace. The tool chosen and the observation returned is a trace.
- What is the category it can never touch, in any configuration? A product with no such category has not thought about this.
Worth knowing about Oneop specifically: an agent runs when a person starts a run. There is no scheduler behind it and no record event that fires it, so an Oneop agent is human-initiated even in autonomous mode — autonomous describes whether it needs an approver after it proposes, not whether it wakes up by itself. The controls that apply to every AI call regardless of surface are documented on AI governance.
The position
Copilot and agent are not two points on a capability ladder where agent is the advanced one. They are two different risk contracts, and the correct answer for most teams is to run both: copilots broadly, wherever a human is already looking at the screen, and agents narrowly, on work where you can name the failure and bound it. A team that has deployed copilots everywhere and no agents has not fallen behind. A team that promoted a copilot to an agent with a toggle and no review has.