“Agent” has become the word everyone uses and no one defines. Vendors describe their chatbots as agents. Automation tools rebrand their workflows as agents. The word shows up in every AI pitch deck, which would be fine if it meant something consistent — but it doesn’t.
That matters because a chatbot, an automation, and a true agent are three different things with different costs, different risks, and different appropriate uses. Knowing which one you’re being offered — and which one you actually need — is one of the more useful distinctions you can have before buying anything.
The three things people call agents
A chatbot answers questions. It takes input, processes it, and returns a response. It doesn’t do anything — it just responds. A chatbot that can look up your CRM before answering is a smarter chatbot. It’s still not an agent.
A workflow automation follows a fixed sequence of steps. When this happens, do that, then do this, then send here. It can be sophisticated — dozens of steps, conditional logic, multiple systems — but the path is defined in advance. It doesn’t decide what to do; it executes what was designed. A lot of what gets called “agentic AI” is actually well-built automation with a language model bolted on at one step.
An agent, properly defined, takes an open-ended goal and figures out how to achieve it. It plans, uses tools, observes the result, decides what to do next, and loops until the job is done — or until it’s stuck. The difference from automation is that the sequence isn’t fixed. The agent decides the sequence based on what it finds.
What an agent can do that the others can’t
The example that makes the distinction concrete: handling a customer refund request.
A chatbot tells the customer what your refund policy is. A workflow automation checks if the order meets refund criteria, processes the refund if yes, routes to human review if no. An agent receives the request, checks the order, looks at the customer’s history, notices the order is outside the refund window but this is the customer’s first issue after three years, decides the context warrants an exception, drafts a personalised response, and flags the exception for your records.
The agent handled a case the automation wasn’t designed for, using judgement rather than rules. That’s the capability. It’s real. It’s also the thing that makes agents more complex to build, more expensive to run, and more unpredictable to operate.
Where agents are genuinely useful
Agents are worth the complexity exactly where the work has variation that can’t be encoded in rules. Research tasks where the steps depend on what you find. Support cases where policy has exceptions. Outreach that needs to be personalised to context rather than templated.
If the work follows a fixed path — even a complicated one — an automation is cheaper, faster, and easier to audit. Most businesses need fewer agents and more well-built automations than the industry suggests.
The trade-off no one mentions
Autonomy means unpredictability. A chatbot fails by giving a wrong answer — that’s recoverable. An agent fails by taking a wrong action: sending a message you didn’t approve, processing a transaction it shouldn’t have, chaining together a series of reasonable-seeming steps that produce an unreasonable outcome.
This is why production agents need guardrails: rate limits on consequential actions, human review for anything above a certain threshold, audit logs so you can see what happened when something goes wrong. Not because agents are dangerous, but because any system with autonomy needs appropriate oversight — the same as you’d apply to a new employee given access to your systems.
How to figure out what you actually need
Three questions. Work through them in order.
Does the task follow a fixed path? If yes, you want an automation, not an agent. Better, cheaper, more auditable. Only move to agents if the path genuinely varies based on what the system finds along the way.
Does the task require judgement on information you can’t pre-define? If yes, an agent might be the right tool. But check whether the judgement could be captured in well-designed rules first — that’s almost always simpler.
Can a mistake be undone? If not — if the action sends an email, charges a card, updates a client record — you want human review before it fires, at least while the system is new. An agent’s value is in handling volume; the risk is handling it wrong at volume.
The label is less important than the answers. What matters is whether the thing you’re building matches the problem you’re trying to solve — not whether it’s technically an agent, an automation, or something in between.