AI agent vs chatbot: the difference that matters

The words get used interchangeably by people selling both, so here is the line that actually separates them.

A chatbot returns text. You ask, it answers. Everything it produces is a suggestion for a human to act on.

An agent calls tools and changes state. It looks up your order, applies the refund, updates the record. The output is not a sentence; it is a thing that happened.

Everything interesting, and everything difficult, is on the second side of that line.

Why the difficulty is not the model

Getting a model to produce a sensible sentence is close to free now. Getting a system to take an irreversible action in your business, correctly, and to stop when it should not, is engineering.

The problems that eat the schedule are not AI problems at all:

• Permissions. What is this agent allowed to touch? On whose behalf? An agent that can read every customer record because that was easier to wire up is a data breach waiting for its moment.
• Idempotency. The agent retries after a timeout. Did it just issue the refund twice?
• Ordering. Two tool calls that must happen in sequence, where the second fails. What state are you in now?
• Audit. Three weeks later somebody asks why a customer was refunded. Can you answer?
• Knowing when to stop. An agent that loops, retrying a failing call, burning budget, is the single most common expensive failure.

None of that is solved by a better prompt. It is solved by the same discipline you would apply to any system that mutates production data.

Guardrails are code, not prompts

The most important rule we work by: a prompt is guidance, never a security boundary.

If your agent is only prevented from deleting records because the system prompt politely asks it not to, you do not have a constraint. You have a suggestion, and models are famously agreeable to well-phrased arguments.

Real guardrails look like this:

• Irreversible actions sit behind an approval step by default.
• Spend and scope are capped in code, outside the model’s reach.
• There is a kill switch, and someone knows where it is.
• Every tool call is logged with its arguments and its result.

When you actually want an agent

Agents earn their keep when a task needs several steps against several systems and the sequence varies by case. Ad operations is a good example: research, generate creative, launch a campaign, watch it, adjust. Writing that as fixed code means encoding every branch. An agent with the right tools handles the variation.

We built exactly that, orchestrating two MCP servers from one persistent session, one for creative generation and one for campaign management. The value was not that the model was clever; it was that the context carried across the whole chain instead of a human retyping between four tabs.

When you do not

Plenty of things sold as agents should be a form and a rule.

If the task is the same every time, write the code. It will be faster, cheaper, fully testable, and it will not surprise you at 2am. “Could an agent do this?” is a less useful question than “does this need judgement?”

If the answer is no, you do not need judgement. You need software.

A middle ground worth knowing about

Between the two extremes sits the pattern we use most: a model that decides, and code that acts.

The model classifies, extracts, or ranks. Deterministic code takes it from there. You get the flexibility of a model on the ambiguous part and the reliability of ordinary software on the part that touches your data.

An assistant we shipped for a Lebanese retailer works this way. It interprets “what is the cheapest olive oil you have” in Lebanese Arabic, which is genuinely a judgement problem. But the search, the price comparison and the add-to-cart are plain code. The model never touches the cart directly.

That split is usually the right answer, and it is much cheaper to build than a fully autonomous agent.

The question to ask a vendor

Not “is it an agent?” but:

What can it change, what is it prevented from changing, and how would we know if it did something wrong?

If there is no clear answer to all three, it is not ready for your production systems, whatever it is called.

---

We build both, and we will tell you which one your problem actually needs. Have a look at how we approach agents, or start with a free three-month build and judge it on the running version instead of the pitch.