AI agent or automation: which one for which task

An automation follows a script you wrote, whereas an agent decides what to do from a goal you stated, and everything else follows from that single difference.

So the test is not how complex the task is, contrary to what you read everywhere, but whether you can write out all of its branches in advance. A complicated task whose cases you already know belongs to a workflow, while a simple task whose outcome depends on what you happen to find along the way belongs to an agent.

The blank page test

Take the task and try to write the full procedure, not the general principle but the procedure itself, edge cases included.

“When a CV lands in the applications inbox, extract the name, email and skills, create a record in the ATS, send an acknowledgement.” You just wrote it in one sentence, which settles the question: that is a workflow, and Make or n8n will run it for a few euros a month without ever putting a value in the wrong field.

“When a client sends an opening, find five relevant profiles.” Try writing what comes next. Relevant by what measure? What if the pool only has two? What if the client already turned down a similar profile three months ago? Each question adds a branch, and the branches multiply until the script becomes unmaintainable.

If you write “it depends” more than twice, the task needs judgement. That is the boundary, and in our experience it holds better than any decision matrix, because it tests what you can actually write rather than what you assume is hard.

What each does well, and badly

A workflow is deterministic, which means the same input gives the same output today and in six months. When it breaks, it breaks loudly: the API changed, the node turns red, and you find out the same day. That quality is badly underrated until you have lived through the alternative.

An agent is adaptive. It composes its own sequence of actions from what it finds, which lets it handle situations nobody anticipated. In exchange, when it is wrong it is quietly wrong: it produces something plausible and false, and nothing turns red. That is why the question of who approves what arises for an agent and never for a workflow.

A workflow asks nothing of anybody once it runs, whereas an agent has to be adopted: you have to think of it, know what to hand it and learn to phrase things. That is where the real entry cost sits, and it is what takes three to four weeks before the reflex forms.

The three questions that settle it

Is the output mechanically verifiable? A copied field is checked by simple comparison, whereas a shortlist has to be judged, and that difference is usually enough to settle it: the first case is a workflow.

Is the number of cases finite? Three possible statuses and four document types are finite, therefore scriptable, while “every client need that might come in” is infinite and cannot be scripted however long you work at it.

Is the cost of an error asymmetric? A workflow that crashes has done nothing, whereas an agent that gets it wrong has already done something. Wherever the action is irreversible (a message sent, a profile rejected), you want either a workflow or an agent whose output passes through approval.

The “AI node” trap

Most automation platforms let you call a language model inside a node. That is useful, and it is not an agent.

The distinction is who decides the sequence. In a workflow with an AI node, you decided in advance: first this, then the model, then that. The model fills a hole in a plan you drew. In an agent, the model decides the sequence itself, at run time, from what it discovers: it can search, notice the result is thin, widen the criteria, and search again.

That is a difference in kind, not in degree. It explains why a workflow with ten AI nodes stays rigid, and why an agent with three tools can handle situations you never anticipated.

Where the line falls in a staffing firm

In practice it falls fairly cleanly.

Workflow territory: ATS-CRM sync, multi-posting an advert, an alert when a timesheet is missing, archiving a signed file, an automatic interview reminder. These are pipes, and they should be boring.

Agent territory: matching a client need against a pool, deciding which channel to use for a given contact, summarising an interview and keeping what matters, noticing that three consultants roll off in the same month and two open needs could absorb them.

The difference is visible at a glance: the first list describes movements of data, the second describes judgements.

What each costs, and why the comparison misleads

A workflow costs a subscription: a few tens of euros a month, predictable, independent of volume above a tier. In January you know what December will cost.

An agent costs per use. It spends reasoning on every task, and frontier model pricing sits around $1–5 per million input tokens and $5–25 output. Per task executed, that is clearly more than an HTTP call.

Comparing the two on that basis is nonetheless wrong, and it is the most common mistake. The question is not “what does this task cost under each”, for a scriptable task the workflow always wins. The question is what the task nobody does at all today costs. A follow-up that never goes out costs a placement; its token price is noise beside that.

Hence a simple rule: never put an agent where a workflow suffices, and never drop a judgement task because an agent bills it per use.

When a workflow should become an agent

There is a precise moment when the switch is due, and it is recognisable.

Your script had three conditions. It has eight. Every edge case the team reports adds a branch, nobody dares touch it any more, and half the runs fall into the “other” case a human handles by hand.

That is not a design problem: it is the sign that the task needed judgement all along, and that the workflow was a way of simulating it by enumerating cases. Enumeration works until it does not.

Migrating is not rewriting the workflow. It is throwing away the decision tree and writing the goal in its place, which is harder than it sounds, and the real lesson of the first month.

The architecture that works is hybrid

Setting the two against each other is a beginner’s mistake, encouraged by both camps.

Workflows hold the deterministic plumbing: they guarantee the data arrives in the right place, always, with no reasoning and no surprises. The agent works on top, on what the plumbing does not anticipate. It needs the plumbing to exist: an agent plugged into a badly synced ATS produces accurate judgements about wrong data, which is worse than nothing.

That is also why the question of what the agent is connected to matters more than its list of capabilities. An agent reasoning well over a disorderly system of record is still a useless agent.

The question to ask a vendor

Most tools now describe themselves as agents. One question separates them, and it takes thirty seconds.

“Show me a task where the tool decided to do something you did not anticipate.”

A workflow vendor cannot answer it, because their product is valuable precisely for never doing that. A vendor whose agent is a workflow with an AI node will answer with a branch they configured, listen for “we set it up so that”, which is the tell. A genuine agent has an example where it searched, found the result thin, and widened the criteria on its own.

Neither answer is disqualifying. What matters is knowing which one you are buying, because the two are priced, governed and adopted completely differently.

How to choose, in one line

If you can write the script, automate. If you can only describe the outcome, delegate.

And if you hesitate, start with the workflow. It is cheaper and faster to set up, and the day you catch yourself adding a ninth condition to a script that started with three, you will have your answer: it was a judgement task from the start.