I was on a call last week with a head of engineering who told me they'd "built an AI agent" for their customer support team. I asked what it did. It takes an incoming ticket, matches it against a list of categories, and routes it to the right queue.
That's not an agent. That's a classifier with a Zapier step.
This isn't pedantry. The distinction matters because it changes what you build, how you test it, how much it costs, and what can go wrong.
Automation does what you told it to do
Traditional automation is a flowchart. If this, then that. Input comes in, rules get applied, output goes out. The logic is fixed. You wrote it. It doesn't change unless you change it.
Zapier, Make, n8n, a Python script with some if-statements. These are automation tools. They're bloody useful. I've built dozens of automations and they save real time every single day.
The key thing: the path is predetermined. There's no decision-making happening. The system follows rules you defined.
An agent makes decisions
An AI agent has a goal, access to tools, and the ability to figure out the steps on its own.
Here's a real example. I built an agent for a client that handles incoming partnership enquiries. It reads the email, looks up the company on LinkedIn and Companies House, assesses whether they fit the client's partner criteria, drafts a response, and either sends it or flags it for human review depending on its confidence level.
The agent decides what to look up. It decides whether the company is a fit. It decides what to write. It decides whether it's confident enough to send the reply itself.
That's the difference. The agent isn't following a script I wrote. It's using judgement (well, something that functions like judgement) to navigate from input to output. The path varies every time.
Why the distinction matters
Three practical reasons.
Testing is completely different. You can test an automation by running every branch of the logic tree. You can verify that input X always produces output Y. Done. An agent, you can't do that. Because the path changes depending on the input and the model's interpretation. You test agents by evaluating outputs across a wide range of inputs and checking whether the results are acceptable. It's probabilistic, not deterministic. If you test an agent like you'd test an automation, you'll miss failures that only show up with weird real-world data.
Failure modes are different. An automation fails predictably. Something breaks in the flow, you get an error, you fix the step. An agent fails in ways you might not notice. It might route 95% of things correctly and subtly mess up the other 5% in ways that look plausible. That silent failure is the thing that kills you. I wrote about this more in my post about deploying AI agents.
Cost models are different. An automation costs you compute time, which is basically nothing. An agent costs you API calls to a language model, and the cost scales with the complexity of each individual run. One agent processing a simple email might cost £0.02. A complex one with multiple lookups might cost £0.40. Multiply that by volume and the numbers get real very quickly.
When to use which
Use automation when the logic is clear and stable. If you can draw the flowchart on a whiteboard and it doesn't change month to month, automate it. Don't bring AI into something that a simple script handles perfectly well. Adding AI to a solved problem is just adding cost and unpredictability for no reason.
Use agents when the task requires interpretation. When the input varies. When the right action depends on context. When the same input might need a different output depending on other factors.
That ticket routing system I mentioned at the top? Automation. The partnership enquiry handler? Agent.
A lot of what I see companies trying to do with agents should actually be automation. And some of what they're trying to do with rigid automation would work better with an agent. The trick is knowing which is which.
The spectrum in between
It's not always binary. Some of the most useful things I've built sit in the middle.
Take a content moderation workflow I set up for a client. The automation part handles the obvious stuff: known banned words, duplicate submissions, formatting checks. That's all rules-based. Fast, cheap, reliable.
The AI part handles the ambiguous cases. The ones where context matters. A comment that's fine in one context but problematic in another. That gets routed to a lightweight model that makes a judgement call.
About 80% of the volume goes through the automation path. 20% hits the AI. Total cost is a fraction of what it would be if you ran everything through an agent.
This is where I spend most of my time with clients through our agent strategy work. Not building pure agents. Building systems where automation handles the predictable stuff and agents handle the rest.
If you're planning your first AI project and you're not sure whether you need an agent or just a good automation, start with the automation. You can always add the AI layer later. Going the other way round is much harder.