Automation follows a route you laid out in advance. An agent is given a destination and works out the route itself. Both can end with the same appointment in the same calendar, and the difference only becomes obvious when something unexpected happens on the way.
This is a different comparison from rules versus AI. You can build an automated pipeline that uses AI at one step — reading a message, say — and it is still automation, because you decided the order. What makes something an agent is that the order is not fixed.
Automation: the path is the product
A form arrives, so create the record, send the acknowledgement, notify the right person, set a reminder for Thursday. You drew that. It runs the same way every time, you can point at any step and say what it does, and when it breaks you know exactly where.
That predictability is the whole value. It is also the limit: if the enquiry arrives by text instead of the form, or asks something your path has no branch for, the automation does not improvise. It does what you told it, which is now the wrong thing.
Agents: the destination is the product
An agent gets the goal — get this enquiry qualified and booked — plus a set of tools it is allowed to use and limits on what it may do. It decides what to do first, looks at what came back, and decides again. If the customer answers a question you never anticipated, it can still get to the booking.
The cost of that flexibility is that you cannot read the route off a diagram beforehand, because there is no fixed route. You can constrain what it is allowed to touch, you can log everything it did, and you can require it to hand off when unsure — but you are supervising an outcome rather than specifying a sequence.
The test that actually separates them
Try to draw your process as a flowchart. If you can finish the drawing, you want automation, and you should not pay for an agent to do something a pipeline does more cheaply and more predictably.
If the flowchart keeps sprouting branches you cannot close, that is not a failure of drawing. That is the shape of a job that needs an agent.
Processes with a handful of known inputs and one correct path each are automation. Processes where the input is a human being saying something in their own words, and the right next step depends on what they said, are agent-shaped.
Most real systems are both
- The agent handles the conversation — reading, asking, deciding, booking.
- Automation handles everything downstream — the record, the confirmation, the assignment, the reminder.
- A rule catches the edges: anything above a value threshold, or flagged unusual, goes to a person before it goes anywhere else.
Built this way the unpredictable part is small and observable, and the rest of the system is as boring and reliable as it should be. It also means you can start with the automation half, which is cheaper and faster to prove, and add the agent once you know the pipeline behind it works.
Which to build first
Almost always the automation. It is quicker, its failures are obvious, and it forces you to write down what your process actually is — which is the part most businesses have never done explicitly. Very often that exercise alone fixes the problem you were going to buy an agent for.
The other comparison people mean by this question: AI automation vs traditional automation
What an agent is, and the permissions that matter more than the intelligence: What is an AI agent?