When should you use an AI agent instead of a normal automation?

The decision is not about how sophisticated the task feels. It is about whether the branching is enumerable. Take three real jobs. Categorising an inbound enquiry: three or four outcomes, all known, no agent needed. Drafting a reply that uses the customer's history: still enumerable, because the inputs are known even if the text is generated. Working out why a shipment was rejected at a customer's goods-in: not enumerable, because the answer determines what you look at next and the tree is wide.

The second condition is that intermediate results must be observable to the system. An agent is only useful if it can see what its actions produced, because that is what it uses to choose the next step. A job where the system acts and learns nothing until a human tells it the outcome is not an agent job at all; it is a workflow with a delayed review, and dressing it as an agent just adds an unnecessary loop around a single decision.

The third is that the work must be worth more than the supervision it displaces. Agents remove per-step review and replace it with end-state verification. Where a step is cheap to review and expensive to redo, that trade is bad. Where a step is expensive to review — because it is one of many, or because reviewing it means doing it — the trade is good. This is why investigation, reconciliation, research sweeps and multi-file code changes are the durable agent use cases and single-decision tasks are not.

There is a fourth condition that is easy to miss and is usually decisive in a small business: someone has to own the failure. An agent that goes down the wrong path produces work that looks finished. If nobody in the business can tell a good output from a plausible one in the domain concerned, the agent is not saving time, it is deferring an error to a point where it is more expensive. Automations do not have this property to the same degree, because a fixed route fails in the same visible place every time.

Where all four hold, the agent should still be bounded rather than open. Give it a step budget, a tool set narrow enough to describe in a sentence, a required report of what it did, and one or more checkpoints where a person can stop it. Those constraints do not reduce what the agent can do on the tasks it is good at; they reduce what it can do on the runs where it has misunderstood the task, which is the only situation where the constraints ever bind.

A last practical note. The strongest signal that you have an agent-shaped problem is that your own process document for it contains the words 'depending on what you find'. That phrase is exactly the point where a fixed route cannot be written, and the number of times it appears is a reasonable estimate of how much an agent would actually be doing.