Comparison

Chatbot or agent?

The distinction is not intelligence or model size. It is that an agent takes actions in real systems — which is why an agent needs permissions, audit logs and a blast-radius analysis, and a chatbot does not.

THE ACTUAL DIFFERENCE

A chatbot produces text. Whatever it says, the worst outcome is that a person reads something wrong. That is not trivial — wrong information causes real harm — but the failure is contained to the conversation.

An agent calls tools. It updates records, sends messages, issues refunds, provisions access. When an agent is wrong, the consequence persists in systems outside the conversation, and may not be noticed for weeks.

Everything else follows from that. An agent needs a permission model, an audit trail, confirmation on destructive operations, and someone to have asked "what is the worst this can do if fully compromised". A chatbot needs good retrieval and a sensible tone. Teams that build agents with chatbot discipline are the ones most likely to have incidents.

SIDE BY SIDE

	Chatbot	AI agent
Produces	Text	Text and actions
Touches other systems	Read-only, if at all	Reads and writes
Worst-case failure	Wrong answer	Wrong action, persisted
Needs a permission model	—	✓
Needs an audit trail	Useful	Essential
Prompt injection exposure	Misleading output	Unauthorised actions
Typical build time	2–4 weeks	6–16 weeks
Evaluation focus	Answer accuracy	Accuracy plus action correctness
Human oversight	Optional	Required above a risk threshold

Build times are design targets for a first production version, not measured client outcomes. The difference between them is not model complexity: it is permissions, audit, error handling and the evaluation of actions taken.

WHICH DO YOU NEED?

A chatbot is enough when…

The value is in answering questions from a body of knowledge — documentation, policies, product information. If a person takes the action afterwards, you get most of the benefit at a fraction of the risk and cost. This describes far more use cases than the current enthusiasm suggests.

An agent earns its cost when…

The action is the tedious part. If answering the question is easy and executing the ten-step follow-up is the work, automating only the answer saves nothing. That is when the additional engineering is justified.

QUESTIONS

QUESTIONS — 4

Yes, and it is usually the right sequence — retrieval quality is the foundation for both, and an agent acting on bad retrieval is worse than useless. Design the boundary so tools can be added behind a permission layer rather than bolted on, because retrofitting authorisation into a system that never had it is the hard version of the work.

Read-only tool use is a middle ground and a genuinely useful one. It carries some agent characteristics — you need to prevent injection-driven data exfiltration — without the blast radius of writes. We would still design it with per-user authorisation, because a read tool with broad credentials leaks across tenants just as effectively as a write tool corrupts them.

Almost none of it is model work. It is permissions, audit logging, error handling, confirmation flows, rollback paths and evaluating whether the actions taken were correct — not just whether the text was good. That last one is genuinely harder to evaluate and is where most of the extra time goes.

Giving an agent broader permissions than any of its users, because it was simpler during development and never revisited. It turns every user into an effective administrator of whatever the agent can reach, and it is the finding we see most often in reviews of existing systems.

Keep reading

Security Architecture

→

30-minute call · no deck