The words “chatbot” and “agent” are used almost interchangeably in marketing right now, which is a problem, because the two things carry completely different risk profiles. One of them writes text. The other one writes to your database. You should know which one you are buying.
The one-sentence versions
A chatbot is conversational software: it receives a message and produces a reply, inside the boundaries of a conversation.
An agent is goal-directed software: it receives an objective, then runs a loop — reason, choose a tool, call it, observe the result, reason again — until the goal is met or a limit is hit. Its output is not a message. It is a set of actions.
Both can use the same underlying model. The difference is not the model. It is what the software around the model is allowed to do.
Chatbots: bounded by the conversation
A chatbot’s world is the conversation. That bound is a feature, not a limitation. It means a chatbot can be built from deterministic parts — flows, branches, validated form inputs — with a model called only where language understanding is genuinely needed.
Oneop’s chatbot builder works this way: a visual flow of roughly 55 executable block types — messages, validated input, branching, knowledge-base-grounded answering, intent classification — that you can test against a draft, A/B test between published versions, and roll back with one click. Most of what a good support bot does is not generative at all; it is a well-designed flow that reaches for the model at the right moments.
The failure mode of a chatbot is bounded too: a wrong or unhelpful answer. Bad, worth engineering against (we wrote a practical guide to grounding a chatbot), but recoverable inside the same conversation, usually by a human takeover.
Agents: bounded by whatever you bound them with
An agent’s world is your systems. Give an agent a goal like “qualify this lead” and it might read the CRM record, look up past conversations, draft an email, and update a field. Each of those is a tool call, and some of them are writes.
This is where the risk profile changes completely. A chatbot that loops wastes a conversation. An agent that loops — or that gets manipulated by a prompt injection buried in an email it reads — can flood your CRM, send things, change things. The question to ask of any agent product is not “how smart is it?” but “what stops it?”
Here is what stops ours, as numbers rather than adjectives:
- Six reasoning iterations per run by default, hard cap of twelve.
- 6,000-token budget per run.
- Forty-five seconds of wall clock.
- Three actions per run.
Hit any ceiling and the run ends as escalated, with the exit reason stored. The agent stops rather than invents an answer to finish. Every step’s thought, chosen tool and actual observation is kept on the run, so what you review afterwards is the sequence that happened, not the agent’s summary of itself.
Writes get a second layer: every proposed action passes through a governed engine that applies the autonomy level you set per agent — log the suggestion, queue it for human approval, or dispatch it. Finance and stock actions are excluded by default no matter what the autonomy dial says; they sit behind a separate explicit opt-in. The full model is in Autonomy levels: a governance model for AI at work.
The overlap: when a chatbot acts
The clean dichotomy blurs in one place, and it is worth understanding. A chatbot flow can include actions: in Oneop, a flow can create a CRM contact, open a deal or a ticket, look up an order, or check stock as native blocks. At that moment, the chatbot is doing agent-class work — writing to the system of record.
We treat it with agent-class caution: chatbot write actions are hard-capped at five per conversation per ten minutes at the engine level. A looping flow or a manipulated visitor session cannot exceed that, regardless of how the flow was built. If a product lets its chatbot write to your CRM and cannot tell you the equivalent number, that is a gap.
A comparison table you can reuse
| AI chatbot | AI agent | |
|---|---|---|
| Input | A message | A goal |
| Output | A reply | Actions (plus a trace) |
| Loop | One turn at a time | Reason → tool → observe, repeated |
| Failure mode | Wrong answer | Wrong action |
| Needs grounding | Yes (knowledge base) | Yes (live system data) |
| Needs run ceilings | Rarely | Always |
| Needs autonomy levels | No | Yes |
| Needs an audit trail | Helpful | Non-negotiable |
Which one do you need?
Probably both, in sequence. Most SMBs get value fastest from a grounded chatbot on web chat — deflecting repeat questions, capturing leads, handing off cleanly to a human. Agents earn their keep next, on internal work where a human review step is natural: drafting replies for the help desk, scoring and routing leads in the CRM, extracting data from documents.
What you should avoid is the product that blurs the line without the controls: a “chatbot” with write access to your systems and no action limits, or an “agent” whose runs you cannot audit. The label matters less than the mechanism.
One more disclosure, because the distinction demands it: every AI call in Oneop — chatbot and agent alike — goes to a single model provider, Google Gemini, and every call is metered against a visible per-workspace credit balance. No mystery models, no mystery bills.
If you want to see the difference rather than read about it, the free plan includes both the chatbot builder and AI agents — and agent runs can be executed in a clearly-badged simulated mode first, which makes no model call at all. Test the boundary before you trust it.