Agent, chatbot or script — which one you actually need

Three words get used interchangeably in proposals and they are not interchangeable at all: agent, chatbot, automation. They differ in what they can do, what they cost to run, and — the part that matters most — what happens when they are wrong. Buying the wrong one is the most common expensive mistake we see, and it usually means buying the most capable one for a job that needed the simplest.

The short answer

Buy the least capable thing that solves the problem. A script that runs the same steps every time is cheaper, faster, more predictable and easier to fix than an agent that decides what to do each time. Capability you do not need is not free — you pay for it in running cost, in unpredictability, and in the review burden of checking work that could have been deterministic.

What each one actually is

Automation, or a script. Fixed steps in a fixed order. When this file arrives, extract these fields, put them in that system, email this person. No language model needs to be involved at all, or one is used for a single narrow step such as reading a document. It does the same thing every time, which is precisely its value.

A chatbot, or assistant. Converses with a person, answers from a defined body of knowledge, and hands over when it cannot. It does not act on your systems beyond looking things up. Its failure mode is saying something wrong, which is bad but recoverable.

An agent. Given a goal, it decides which steps to take, calls tools, checks results and tries again. Its power is handling situations you did not anticipate. Its risk is exactly the same sentence — it will do things you did not anticipate, including at three in the morning with nobody watching.

The comparison that should drive the decision

	Script / automation	Assistant	Agent
Decides its own steps	No	No	Yes
Cost per run	Near zero	Low, scales with conversation	Highest and variable — it may loop
Predictability	Total	High	Bounded at best
Failure mode	Stops and tells you	Answers wrongly	Takes a wrong action
Debugging	Read the log, find the line	Trace the retrieval	Reconstruct a decision path
Right when	The steps never change	People ask varied questions with fixed answers	The path genuinely varies and the cost of a wrong action is low

The row that decides most real cases is the failure mode. A script that fails stops and tells you. An agent that fails has already done something. If that something is reversible, fine. If it emailed a customer, submitted a form or issued a refund, you are not debugging — you are apologising.

A test you can apply in one minute

Take the task and ask four questions in order.

Can you write the steps down? If yes, and they do not change, you want a script. Stop here — this covers more cases than anyone expects, and it is the cheapest answer.

Is the variety in the questions, or in the actions? Many different questions with stable answers is an assistant. Many different sequences of actions is where agents start to earn their place.

What happens if it is wrong at 3am? If nobody notices until morning and the damage is permanent, do not give it the ability to act. Give it the ability to draft, and have a person confirm.

How would you prove it did the right thing? If you cannot answer, you cannot operate it — regardless of which of the three you bought.

Those four questions are the same instinct as the volume-and-reversibility test in which process to automate first, applied to technology choice rather than task choice.

Why agents get sold anyway

Two honest reasons and one less honest. The honest ones: agents genuinely are the right answer for some open-ended work, and they demo spectacularly, because a demo is the best-case path. The less honest one: “agent” is the word that sells right now, so a great deal of software that is a script with a language model in the middle is being marketed as one.

You can test this quickly. Ask the supplier what the system does when a tool call fails twice. If the answer is a specific, designed behaviour, it is an agent built by people who have operated one. If the answer is vague, it is a script wearing the word.

This advice is not contrarian

It is worth saying that “use the simplest thing that works” is not a sceptic’s position held against the industry — it is the industry’s own guidance, written by the people building the models. Anthropic’s engineering note on building effective agents opens by recommending the simplest solution possible and warning that agentic systems trade latency and cost for capability, which is only worth it when the task genuinely requires it. OpenAI’s own agents guidance similarly frames autonomy as something to be scoped and constrained rather than maximised.

The governance view lands in the same place. The NIST AI Risk Management Framework organises its guidance around mapping context, measuring behaviour and managing risk proportionately — which in practice means that a system permitted to take consequential actions carries obligations a read-only assistant does not.

So when a proposal argues for an agent because agents are the current state of the art, it is worth noting that the model vendors themselves advise starting below that.

The hybrid that is usually right

In practice the systems that survive are rarely purely one of the three. The shape that works most often: a deterministic script as the skeleton, a model used narrowly where judgement is genuinely needed, and a human confirmation step on anything irreversible.

A supplier-invoice workflow is the clearest example. The routing, validation and posting are a script. Reading the document is a model. Approving anything above a threshold, or anything that failed validation, is a person. There is no agent in it, and adding one would increase cost and risk without improving the outcome. The engineering behind that reading step is set out in reading Arabic invoices with AI.

This hybrid also has the best cost profile, for reasons covered in what AI costs after launch: the expensive component runs on a small fraction of the work rather than on all of it.

What to ask a supplier

Five questions that separate people who have run these systems from people who have sold them.

• Which of the three is this, precisely, and which parts of the flow are deterministic?
• What can it do to our systems without a human confirming? Name the actions.
• What happens when a step fails twice — retry, stop, or escalate?
• What is logged, and could we reconstruct why it did something last Tuesday?
• What is the monthly running cost at our volume, and what is the ceiling if it misbehaves?

A supplier who answers all five plainly is worth more than one with a better demo. If you are holding a proposal and want a second read on which of the three you are actually being sold, send it to us on WhatsApp, or ask for a scoped first phase where the architecture question gets settled before anything is built.

Frequently asked questions

Are agents just chatbots with extra steps?

No — the difference is real and it is about authority, not sophistication. A chatbot answers; an agent acts. The moment a system can change something in the world without a person approving that specific change, it belongs in a different risk category and needs different controls.

Is it cheaper to start simple and upgrade later?

Almost always, and the migration is easier than the reverse. A script that outgrows itself tells you clearly — the exceptions pile up and someone is handling them manually. An over-capable agent fails quietly, by doing odd things occasionally that nobody traces back to the architecture choice.

Do we need an agent to use AI properly?

No. Most of the value delivered by AI in ordinary businesses today comes from narrow, boring uses inside deterministic workflows: reading a document, classifying a message, drafting a reply for a person to send. That is not a lesser version of AI adoption; it is the version that stays switched on.

When is an agent genuinely the right answer?

When the sequence of steps truly cannot be known in advance, the task is open-ended, and a wrong action is cheap to undo. Research and triage work often fits. Anything touching payments, commitments or customer communications usually does not, at least not without a confirmation step.

How do we keep an agent from running away?

Constrain the tools it can call, cap the number of steps and the spend per task, make every consequential action require confirmation, and log the full decision path. If those controls make the agent useless for your task, that is a finding: the task needed a script.