AI agent or automation: which does your task need?

Jahanzaib Ramzan — Mon, 05 Oct 2026 17:48:25 +0000

Most teams arrive with the same sentence: "we want AI to handle this." Sometimes that's right. Often the task follows a rule, and a rule is cheaper to build, cheaper to run and far easier to check.

The short version

If someone can write down a rule that decides the next step, and that rule is right every time, you want automation.
An agent earns its place where something has to be interpreted before a rule can apply.
Agents cost more to run, are harder to verify, and fail by producing plausible answers rather than stopping.
Most real workflows want both: interpretation at one step, rules everywhere else.

The distinction that matters isn't the technology. It's whether the next step can be decided by a rule you can write down.

How do you tell whether a task needs an AI agent?

Take one real example of the task. Not the general description, but an actual request, document or message that arrived last week. Then ask: could someone write down a rule that decides what happens next, and would that rule be right every time?

Workflow automation

When it fits: The next step follows from the input by a rule. “When a form is submitted with the Enterprise option, create a task for the sales team and notify the channel.” Same input, same output, every time.
What it costs: Almost nothing per run. It breaks loudly when an assumption changes, which is the failure mode you want.

An AI agent

When it fits: Something has to be read and understood first. “When a supplier invoice arrives, work out which cost centre it belongs to” isn’t a rule. It depends on reading the invoice, and on knowing things that aren’t printed on it.
What it costs: A charge per request that moves with your volume, your model and your document sizes. Verification is ongoing, not one-off.

Most real workflows are a mix. A request comes in, something has to interpret it, and then a rule takes over. That's usually the right shape: interpretation where it's needed, rules everywhere else.

	Workflow automation	An AI agent
Use it when	The next step follows from the input by a rule	Something has to be read and understood first
Cost to run	Almost nothing per run	A charge per request that moves with volume, model and document size
How it fails	It stops, loudly, when an assumption changes	It keeps going and produces something plausible
How you check it	The rule fired or it didn't	Test cases and output checks, repeated when the model changes
Best role in a mixed workflow	Everything that follows a rule	Only the step that needs interpretation

For twelve concrete automations, each with what starts it and how it can fail, see workflow automation examples.

Why does the choice matter so much?

Choosing an agent where a rule would do costs you three ways.

It's harder to check. A rule either fires or it doesn't. An agent produces an answer that might be right, mostly right, or confidently wrong. Confirming it works means assembling test cases and checking outputs, and doing that again whenever the model changes underneath you.

It costs more to run, and the cost moves. Rules run for approximately nothing. Agents cost per request, and that figure changes when your volume grows, when you switch models, or when someone pastes in a longer document.

It fails less obviously. When automation breaks, it stops, and you know.

When an agent goes wrong, it usually keeps going and produces something plausible. That's the failure mode worth designing against, because nobody notices it for weeks.

None of this is an argument against agents. It's an argument for knowing which one you've chosen and why.

When is an AI agent worth it?

Three patterns come up repeatedly.

Answering from documents people can't find. Your policies exist. Nobody can locate the relevant paragraph. An agent that answers from approved guidance and shows which document it came from saves real time.

The source matters as much as the answer

Without a citation you've replaced "I can't find it" with "I don't know if this is true." An answer that can't be checked is not an improvement on no answer.

Reading unstructured things. Invoices, CVs, support emails, contracts. Anything where the information is there but not in fields. Extracting it and handing structured data to a rule is a good division of labour.

Preparing work for a person. The agent drafts, routes or summarises; a person approves. This is the shape we recommend most often, because it keeps the useful part and puts a human at the point where a mistake would cost something.

Where should a person stay in the loop?

"Human in the loop" gets used as reassurance. It's worth being specific about.

Ask what the worst realistic mistake is. If it's a badly worded draft, the agent can act alone. If it's money moving, a record changing, or a customer being told something wrong, a person approves first. The agent's job is then to make that approval quick, not to avoid it.

Permissions are a design decision, not an afterthought

An agent should be able to read what the task needs and change nothing else. Not because it will misbehave, but because a narrow blast radius is what makes the thing safe to run at all.

How would we approach it with you?

Bring one real example. The actual task, and what a good outcome looks like. Not a description of the category, but a request that genuinely arrived.
Find where the decision is made. We work through which step needs interpretation and which follow rules. Usually fewer steps need an agent than people expect.
Agree the boundaries. What it may read, what it may change, when it hands to a person, and how you will know if quality slips.

Often the answer is a small piece of automation and no agent. Sometimes it's an agent for one step and rules around it. Either way, you'll know which you're getting and what it will cost to run before anyone builds it.

That conversation is usually shorter than people expect, and it's the one that saves the most money.