What is an AI agent, and how is it different from a chatbot?

The word agent has been stretched to cover almost anything with a language model inside it. That is a marketing problem, not a technical one. Underneath, there is a specific and fairly narrow definition, and it is worth knowing, because the difference determines what can go wrong.

The definition: a model in a loop with tools

A plain chatbot does one thing: it receives text and returns text. Whatever it "knows" has to already be in the model or in the prompt.

An agent adds three things:

1. Tools. Ordinary functions the model may call — search a database, send an HTTP request, run a shell command, write a file. The model does not execute them itself; it emits a structured request, your code runs it, and the result is fed back.
2. A goal. A task stated at a level above a single step: "reconcile these invoices", not "read line 4".
3. A loop. After each tool result, the model decides what to do next. It keeps going until it judges the goal met, hits a step limit, or fails.

That loop is the whole thing. Everything else — memory, planning, sub-agents, scratchpads — is an optimisation on top of it.

What tools actually are

This is the part that surprises people: tools are not special AI components. A tool is a function with a name, a description, and a schema for its arguments. You could write it in an afternoon.

name: search_orders
description: Find orders by customer email or order number.
parameters:
  query: string
  limit: integer (default 20)

The model sees that description in its context, decides search_orders is relevant, and emits a call with arguments. Your runtime executes the real function and returns the result as text. The model never touches your database directly.

Two consequences follow. First, an agent is only as capable as the tools you give it — the model contributes judgement about which tool and what arguments, nothing more. Second, the tool description is part of the prompt, and vague descriptions produce wrong calls just as vague instructions produce wrong answers.

The Model Context Protocol (MCP) exists to stop everyone rebuilding the same tool servers. It standardises how a tool server advertises what it offers, so one implementation can serve many different agent products.

Why reliability is the hard part

Agents fail in a way that is easy to miss in a demo. Suppose each step in a workflow succeeds 95% of the time — respectable for a language model doing something non-trivial.

Nothing is wrong with the model. Errors simply compound. This is why the agents that work in production tend to be unglamorous: five to fifteen steps, a tightly bounded domain, and a human checkpoint at the expensive moments.

It also explains a pattern you will see repeatedly in vendor guidance: prefer the simplest architecture that works. A single well-prompted model call beats a chain; a chain beats an autonomous loop; an autonomous loop beats a swarm of agents. Each step up buys flexibility and pays for it in predictability.

Where agents genuinely earn their keep

The tasks that suit agents share a shape: the goal is clear, the path is not, and the result is cheap to verify.

• Coding. The tests either pass or they do not. The agent can iterate against an objective signal.
• Research and retrieval. Gathering material from many sources, where a human reads the output anyway.
• Triage. Classifying and routing tickets, flagging anomalies, drafting first responses for review.
• Data wrangling. Reconciling records across systems whose schemas nearly, but not quite, match.

The tasks that suit them badly are the mirror image: verification is expensive, mistakes are irreversible, or the correct path is already known — in which case write the script instead. Nobody needs an agent to send a nightly report.

The permission boundary

Because an agent decides its own steps, "what is it allowed to do" cannot be answered by reading the code path. It has to be enforced outside the model.

In practice that means:

• Read wide, write narrow. Let the agent look at anything it needs; gate every action that changes state.
• Approval on irreversibility. Money, external messages, deletions, production deploys.
• Budgets. Cap steps, wall-clock time, and token spend. An agent stuck in a loop is a billing incident.
• A log you can replay. Every tool call and result, stored. When something goes wrong, "what did it actually do" must be answerable in seconds.

Prompt injection deserves its own line. If your agent reads a web page, an email, or a pull request comment, an attacker can put instructions in that content. The model has no reliable way to tell your instructions from the ones it just read. The defence is not a better prompt — it is not granting the agent authority it should not have in the first place.

How to tell hype from substance

When a product calls itself agentic, three questions separate the real thing from a rebrand:

1. What tools can it call, exactly? A list you can read, or hand-waving?
2. What happens when a step fails? Retry, escalate, stop — or silently produce a plausible wrong answer?
3. What can it do without asking? If the answer is "everything", that is not autonomy, it is an unbounded liability.

An agent is not a smarter chatbot. It is a chatbot with a hand on the controls, and the engineering that matters is almost entirely about that hand.