Every second pitch I see this year has the word "agent" in it. An agent for your front desk, your inbox, your books, your hiring. When I ask what the agent actually does, the answer is almost always a list: read the enquiry, look up the price, draft the reply, log it in the CRM, ask someone to approve.
That is not an agent. That is a workflow. For most businesses that is good news, because a workflow is cheaper to run, faster, easy to test and easy to explain to the person whose name is on the invoice.
Agents work. For a narrow set of problems they are the right tool. The trouble is that owners are being sold the most expensive, least predictable option for jobs a checklist would handle.
If you can write the steps down, you don't need a model to decide them.
AI agent vs workflow automation: what's actually different
The cleanest definition I know comes from Anthropic's engineering team in Building effective agents. In a workflow, the model and tools follow paths written in code. In an agent, the model decides its own steps and which tools to use as it goes. Same model, same tools. The difference is who holds the map.
That one difference changes almost everything an owner cares about. Here is the same job, a new catering enquiry, run both ways.
- ✓New email arrivestrigger
- ✓AI reads it into fields AI1 call
- ✓Look up the price listrule
- ✓Fill the quote templaterule
- ✓Create the CRM recordrule
- ✓Queue it for a yesapproval
Put that difference in an owner's terms:
- Cost. A workflow calls the model once, for the one step that needs it. An agent calls it at every decision, and each call carries the history so far. We go deeper on this in cost per task.
- Speed. Rules run in milliseconds. Reasoning takes seconds per step, and the steps add up.
- Testing. You can test a workflow with twenty sample emails and know it works. An agent needs hundreds of cases, and it will still surprise you on the next one.
- Explaining. When a customer disputes a quote, a workflow gives you a line: step 3 used the price list dated 2 September. An agent gives you a transcript of its reasoning.
Anthropic's own advice in that piece is to find the simplest solution possible and add complexity only when it is needed, which, in their words, "might mean not building agentic systems at all." That is a model company telling you not to overbuy its product. Take the hint.
Why most business processes don't need an agent
Walk through the processes in a typical clinic, restaurant group or real estate team and you find the same pattern: the steps are fixed, the inputs vary. A booking request, a supplier invoice, a new lead. The data changes every time. What you do with it does not.
That is the distinction people miss. Messy input does not mean you need an agent. It means one step needs AI. A patient at a Vancouver physio clinic writes "can i move thurs to next wk sometime after 3, not mondays". A rule cannot parse that; a model can, in one call, turning it into a date range and an exclusion. From there it is a calendar lookup, a template and a send. The path never changes.
Nick Saraev, who teaches automation to a large audience, puts it bluntly: most people don't need agents, and when he looked at a week of his own work, almost none of the actions that actually drove his income were agent work. Sonny Sangha's rule is the one we use internally: if the steps are fixed, build a deterministic workflow. If you want an agent in the picture, use it to build the workflow (draft the n8n flow, write the code) rather than to run it every time a customer writes in.
That second idea is underrated. The agent does the creative, one-time work at design time, with a developer watching. The workflow does the repetitive work at run time, for a fraction of a cent, the same way every time.
Before you automate anything, try deleting it
There is a step before the agent-or-workflow question, and it saves more money than either. Elon Musk's five-step "algorithm", which Alex Hormozi has popularised for business owners, runs in a strict order: question the requirement, delete the part, simplify, speed up, and only then automate. Hormozi's warning is the one that matters for AI: reach for AI first and you end up automating things that should not exist.
Here is what that looks like on a kind of task I see in almost every operations review.
Every night at 11, the ops manager logs into six POS accounts, pastes sales into a 14-column sheet and emails it to nine people.
Who reads it? The owner looks at three columns. Two of the nine recipients left the company last year.
Drop eleven columns and seven recipients. Nobody objects, because nobody noticed.
One line per outlet: sales against target, flagged if under. It now fits in a WhatsApp message.
The POS already has a scheduled export. Use it instead of six logins.
A scheduled job posts it at 11:05 pm. No agent. Not even an AI step.
The report never needed an agent, or even an AI step. It needed three columns and a schedule. In our discovery sessions, a good share of the "automation ideas" on the whiteboard turn out to be tasks nobody would miss, and many of the rest shrink until a basic automation handles them.
Do I need an AI agent? The five-question test
Take one task. Answer these in order and stop at the first exit. It takes about a minute per task, and it is the same test we run with clients before anything gets built.
Would anyone notice within a month if you stopped doing it?No → delete it
Does it involve reading or writing language: emails, notes, PDFs, chats?No → plain automation
Once the language is understood, are the steps the same every time?Yes → workflow + one AI step
Can every risky or irreversible action wait for a person's yes?No → workflow, a person does the judgment
Does it happen often enough to test properly, dozens of times a week?No → workflow · Yes → agent with approvals
Delete it
Or shrink it until it's trivial.
Plain automation
Triggers, rules, schedules. No model.
Workflow + one AI step
Fixed path. AI reads or drafts one thing.
Agent with approvals
Model picks the path; a person approves what sticks.
| Outcome | What you build | Typical tasks |
|---|---|---|
| Delete it | Nothing. Stop doing it, or simplify it until it is trivial. | Reports nobody opens, double data entry, approvals nobody reads |
| Plain automation | Triggers, rules and schedules. No model involved. | Appointment reminders, payment receipts, low-stock alerts |
| Workflow + one AI step | A fixed path where AI reads or drafts one thing, rules do the rest, and a person approves anything customer-facing. | Replying to enquiries, sorting invoices, tagging reviews, intake forms |
| Agent with approvals | The model chooses its steps inside tight tool limits; every irreversible action waits for a yes. | Messy insurance claims, multi-system investigations, research tasks |
When I run this with an owner, most of their list lands in the first three rows. That is not a lack of ambition. That is the list getting cheaper, faster and easier to hand to a team.
What a workflow with one AI step looks like
Here is a restaurant group in Delhi with six outlets and a catering business that runs on email. Enquiries arrive in every format imaginable. The steps after that never change: read it, check the kitchen, price it, get a yes on big orders, send, log. One of those steps needs AI. The rest are rules.
Seven steps, one of them AI
The general manager sees the run the way a developer sees a build: every step, its result and how long it took.
- A run pauses on the one rule it can't settle alone: over 150 guests.
- Every step is listed with its result. Only step 2 used AI.
- The AI turned a rambling email into four fields. Everything after is rules.
- The GM checks the numbers and approves in one tap.
- The rest runs: quote sent, date held, CRM updated.
Look at how little AI is in there. The model does the one thing rules cannot: read "we're thinking around 180, mostly veg, north Indian, budget maybe 900 a head, Saturday the 18th for lunch" and turn it into four clean fields. Everything after that is a lookup or a template, and it will behave the same way on the ten-thousandth run as on the first.
It is also easy to test. You can write a check for step 2 ("the headcount in the fields matches the email") and run it against last year's enquiries before going live. If the model ever misreads 180 as 18, the quote comes out obviously wrong and the approval rule catches it. And because the approval is a designed screen, not a raw log, the GM actually uses it. That screen deserves as much care as the automation; I wrote about why in the approval button is the product.
When an AI agent is the right call
Agents earn their place when three things are true at once: the path genuinely changes case by case, the inputs are messy, and a wrong move is cheap or caught before it lands. A rejected insurance claim at a multi-location clinic is a good example. One claim needs a missing referral letter, the next a corrected billing code, the next a call to the insurer's portal and a resubmission. No fixed sequence covers them all, and there are enough every week to build a proper test set.
If you do build one, the unglamorous engineering decides whether it survives real customers:
- Idempotent actions. Every action that touches the outside world, charging a card, sending an email, booking a slot, must be safe to repeat. If the agent retries after a timeout, the customer must not be charged twice. Sonny Sangha makes this point often, and it is the first thing I check.
- Durable retries. Runs should survive a crash or a rate limit and pick up where they stopped, not start over and redo half the work.
- Tight tools. Give it read tools freely and write tools sparingly, and route every irreversible write through an approval lane.
- Evals. A fixed set of real past cases that you rerun every time you change a prompt or a model. Evals are what separate an AI project from an AI product.
- A ceiling. A per-run limit on steps and spend, so one confused case cannot loop all night.
None of that is exotic, but all of it is work, and it is the work most agent demos skip. It is also why the same agent that wowed a room tends to fail quietly in week three, a pattern we cover in why AI automation projects fail.
How we build this at LoopSuit
Our order never changes. We list the tasks with the owner, run the five questions on each, delete what we can, and build the cheapest thing that works. Most of our builds end up as workflows with one or two AI steps and a designed approval screen on top, in n8n or plain code the client owns outright.
When a task passes all five questions, we build an agent, with the approval lane, idempotent actions and an eval set from the first week. And we use agents heavily ourselves, to build: drafting flows, writing tests, generating eval cases from real history. That is where their flexibility pays off, with a developer watching and no customer on the other end.
If you want to run the test on your own list, that is exactly what an AI Clarity Session is for. The tasks that survive go into an AI & Product Blueprint: which ones get automated, where the AI step sits, and what the approval screen looks like.
Questions people ask us
What is the difference between an AI agent and workflow automation?
In workflow automation, the steps are written down in advance and run in the same order every time; AI may handle one step, like reading an email. In an AI agent, the model decides which steps to take and which tools to call as it goes. Workflows are predictable and cheap to run. Agents are flexible, slower, costlier per task and harder to test.
Do small businesses need AI agents?
Rarely, at first. Most small-business processes (bookings, reminders, enquiries, invoices, reviews) have fixed steps with messy inputs. A workflow with one AI step handles those well. Agents make sense later, for the few tasks where the path truly changes every time and there is enough volume to test them properly.
Is an n8n or Zapier flow with an AI step an agent?
Usually not. A flow where an AI node reads or writes one thing is a workflow with an AI step. It becomes an agent only when the model chooses which steps and tools run next. Both tools now offer agent-style nodes; most small-business flows do not need them.
Are AI agents more expensive than workflows?
Per task, almost always. An agent calls the model at every decision, each call carries the conversation so far, and failed tool calls trigger retries. A workflow calls the model once for the step that needs it. Agents also cost more to test, monitor and debug, which matters more than the model bill.
When should I use an AI agent instead of automation?
When all of these are true: the task is worth doing, the inputs are messy, the steps change case by case, every irreversible action can wait for a person's approval, and it happens often enough to build a test set from real cases. If any one fails, a workflow is the better build.