Why the word went blurry
“Agent” tests well in marketing, so everything became one. A rebadged if-then rule is now an agent. A chatbot with a knowledge base is an agent. A scheduled report is, apparently, an agent. When one word covers all of that, it stops carrying information — and you can’t make a buying decision on a word that carries no information.
The distinction underneath is real, though, and it’s worth thirty seconds to get straight.
Automation is a map
Classic automation is a recipe. When a form is submitted, create a row. When an invoice lands in the inbox, save the attachment to the job folder. Tools like Zapier, Make, and n8n are genuinely good at this and have been for years — no AI required.
The strength is predictability. A person drew the path, so the system walks the same path every time. The weakness is the same fact. The moment the input doesn’t match the map — the invoice arrives as a photo, the form has a typo in the email field, the vendor renamed the PDF — the recipe fails. Or worse, it does the wrong thing confidently.
Automation doesn’t know it’s wrong. It doesn’t know anything. It follows the map.
An agent reads the road
An agent gets a goal instead of a path: get this invoice into the books, coded to the right job, and flag anything unusual. To do that it has tools — read the email, look up the vendor, open the accounting system — and a loop: look at the situation, decide the next step, take it, check the result.
That loop is the whole difference. When the invoice is a photo, an agent can read it anyway. When the vendor is new, it can notice there’s no match and ask instead of guessing. When the total doesn’t line up with the purchase order, it can stop and hand the case to a person.
None of that is magic. It’s a language model wired to tools, with rules about what it may and may not do. But the practical effect is real: agents survive contact with messy reality in a way recipes don’t.
And the chatbot is neither
Worth separating, because it’s the thing most offices have actually touched: a chatbot is an interface, not a worker. It answers when spoken to, and then it stops. It has no trigger, no queue, and no job. Pasting an email into a chatbot and asking for a reply is useful — one of the cheapest wins available, honestly — but it isn’t automation and it isn’t an agent. The person is still the workflow. That distinction matters when a vendor demos a chat window and quotes you a system.
Automation follows the map. An agent reads the road.
The trade you’re making
Predictability and flexibility trade off. A recipe does the same thing every run, which makes it safe and easy to audit — and brittle. An agent adapts, which makes it useful — and means someone has to supervise it, log everything it does, and gate the actions that matter.
This is why “we added AI” is not automatically good news. An agent that can send email, edit records, or touch anything financial with nobody watching isn’t an upgrade. It’s risk with a login.
Concretely: a recipe that mis-files one invoice mis-files it the same way every time — you find the bug once and it’s gone. An agent that mis-reads one invoice might handle the next hundred perfectly. That’s better on average and harder to reason about, which is exactly why agent work gets a log, a review queue, and a person who owns the output.
| The work | The right fit | Why |
|---|---|---|
| Data moves between two fixed systems, same shape every time | Automation | A drawn path wins: cheaper, faster, fully predictable |
| Inputs arrive messy — email, photos, PDFs, voicemail | Agent | Judgment is needed just to understand the input |
| Exceptions need a decision | Agent + human gate | The agent drafts the decision; a person owns it |
| Anything customer-facing | Agent + approval | Drafts are fine; the send button belongs to a human |
| Anything irreversible | A person | If you can’t undo it, don’t delegate it |
What to ask before you buy
When a vendor says “agent,” make them show you the seams:
- What happens on a weird input? Show me, don’t tell me.
- Which actions can it take without a person approving?
- Where’s the log of everything it did last Tuesday?
- Who watches it after launch — and what’s their name?
If the answers are fuzzy, you’re not buying an agent. You’re buying a demo.
Start with the narrowest kind of judgment
The safest design is usually a hybrid. Let automation move the known pieces: create the folder, copy the approved fields, attach the source, and notify the right queue. Give an agent only the part that genuinely requires interpretation, such as classifying an unusual request or comparing a document with a written rule. Then make its answer an input to the next gate, not permission to roam through the rest of the office.
That boundary also makes failures easier to diagnose. If a fixed transfer breaks, inspect the map. If an interpretation looks wrong, inspect the source, instruction, and review decision. Mixing both kinds of work into one opaque “agent” turns every miss into a mystery. Separating them gives the operator a specific place to look and the business a specific choice about how much judgment to delegate.