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

The definition, in one paragraph

An agent is defined by what it is allowed to do, not by how clever it sounds. Give a system a goal, a set of tools it may call, and permission to decide the order in which to use them, and you have an agent. Take away the tools and you have a chatbot. Take away the decision and you have workflow automation. The distinction matters commercially because only one of the three removes work from a person: a chatbot produces text that somebody still has to act on, whereas an agent produces a completed action and a record of it.

The three things an agent has that a chatbot does not

• Tools. Named operations it is permitted to call: read a record, create an invoice, send a message, book a slot, run a query. Each one is an explicit grant, not an emergent ability.
• Memory. A record of what it has already done in this task and, usually, of what happened in previous ones. Without it an agent repeats itself and cannot recover from a partial failure.
• A control loop. It observes the result of each step and decides the next one, rather than following a route drawn in advance. This is the property that lets it handle an input nobody anticipated, and it is also the property that makes it harder to test.

Chatbot, agent and workflow automation compared

The three are frequently sold under the same label. They fail differently, cost differently, and suit different problems.

Five questions that tell you which one you need

Most organisations reach for an agent when a simpler and more reliable option would do. These five questions settle it faster than a proposal does.

1. 1

   Is the input structured every time?

   If the work always arrives as the same form, file or field set, workflow automation will be cheaper, faster and more reliable. Reach for an agent when the input is a document, an email or a conversation, where no two arrive in the same shape.

2. 2

   Does the correct next step vary?

   If the sequence is identical on every run, encoding it explicitly is better engineering. If the next step depends on what was found in the previous one, that judgement is exactly what an agent supplies.

3. 3

   Does the work require reading and understanding?

   Pulling twelve fields off an unfamiliar invoice layout, summarising a call, or deciding whether a complaint is urgent are all tasks where a rule set becomes unmanageable and a model does not.

4. 4

   What is the cost of a wrong action?

   A wrongly filed record costs minutes. A wrongly issued refund costs money and trust. The higher that cost, the more of the process should sit behind an approval step, and the less an autonomous agent is the right answer.

5. 5

   Can you describe the process to a new starter in a page?

   If you can, you can automate it conventionally. If your answer is that the new starter learns it over three months, you are describing judgement, and judgement is the thing an agent is for.

What this looks like in practice

A concrete case makes the distinction obvious. An invoice arrives by email as a scanned attachment. A chatbot, shown the file, can tell you what the total is. Workflow automation can move the file to a folder and notify the finance inbox, because those steps never change. An agent reads the document, extracts the supplier, dates, line items and totals, checks its own arithmetic against the stated total, looks the supplier up in your ledger, notices that the bank details differ from the ones on file, declines to post the invoice and puts it in a review queue with that discrepancy written at the top.

Only the third of those removes the task. It is also the only one of the three that can take an action you did not want, which is why the useful question about an agent is never how autonomous it is, but where the boundary sits.

What agents still get wrong

A balanced account has to include the failure modes, because they decide how a project should be scoped.

• Behaviour varies between runs. The same input can produce a slightly different path, so testing has to be statistical rather than a single pass. Anything requiring identical output every time should not be an agent.
• Confident errors remain the central risk. A model will produce a plausible supplier name for a smudged field rather than admit it cannot read it, unless it has been explicitly built to flag low confidence and stop.
• Long chains compound. A step that is right 95 per cent of the time is right 77 per cent of the time after five steps, which is why production agents use short chains with checkpoints rather than long autonomous runs.
• Cost scales with volume, not with seats. Every item processed carries a model cost, so a high volume process needs that arithmetic done before the build rather than after the first invoice.

Our own figures, clearly marked

For context rather than as a benchmark: across the agents we build, a first build typically converts around two hours of document keying into about ten minutes of checking, and reduces first response to a new enquiry from roughly four hours to under thirty seconds. Those are typical results for a first build, not measured results for a named client, and they depend heavily on how clean the source data is.

Reviewed 25 July 2026. Market figures change; where this page quotes a range from a third party, the source is named above. Figures described as ours are our published fees or typical results for a first build, not measured results for a named client.