Do not use an AI agent when the process is deterministic, when the task is a single step, when the volume is too low to repay the effort, when a wrong action cannot be caught or undone, or when you have no way to check whether the agent was right. In each of those situations a simpler tool — a script, a workflow rule, a single model call, or a person — will do the job with less cost and less risk. Agents are the right tool for a narrow band of work: multi-step tasks that genuinely require interpretation at each step. Outside that band, they add a probabilistic failure mode to problems that did not have one.
This is the companion to a broader piece on when not to use AI at all. The logic here is one level more specific: even where AI is the right technology, an agent — a model given tools, memory, and the autonomy to chain its own steps — is often the wrong packaging for it. The five conditions below are the ones worth checking before anyone writes an orchestration loop. The wider question of what agents are actually good for is covered in the overview of AI agents in operations.
Is the process deterministic? Then a script wins
If a process runs the same way every time — same inputs, same rules, same steps — it does not need judgment, and an agent's only real contribution is judgment. Moving a file when it lands in a folder, posting a journal entry on a schedule, sending a reminder when an approval sits for three days, syncing a field between two systems: these are jobs for a script, a scheduled task, or a workflow tool. They will execute in milliseconds, cost almost nothing per run, fail loudly and reproducibly when something breaks, and behave identically on run one and run one million.
Give the same job to an agent and you gain nothing while losing all of that. The agent is slower, costs money per step, and — because a model sits in the loop — carries a small chance of doing something different this time. A script that is wrong is wrong the same way every time, which makes it easy to find and fix. An agent that is wrong occasionally, differently each time, is a far harder operational problem. This is the core of the agents versus RPA and scripts comparison: determinism is a feature, and you should not pay to give it up. The honest test is to write the process down as rules. If you can finish the document, automate the document — not the judgment you no longer need.
Is it really one step? Then a plain model call wins
A large share of "agent" proposals are single-step tasks wearing a costume. Extract the fields from this invoice. Classify this email. Summarise this contract clause. Translate this specification. Each of these is one model call: input in, output out, no tools, no loop, no decisions about what to do next.
Wrapping a single call in an agent framework adds latency, cost, and — more dangerously — degrees of freedom. An agent given tools may decide to use them; an agent allowed to retry and reformulate may wander. Every capability you grant is a behaviour you now have to test for. When the task is one step, the right architecture is embarrassingly boring: call the model, validate the output against rules, route low-confidence results to a person. That pattern is well understood, easy to measure, and cheap to run. The rule of thumb: an agent is justified when the sequence of actions is unknown in advance. If you can name the sequence, you do not need an agent to discover it.
Is the volume too low to repay the effort?
Agents are not free to build or to keep. Someone has to design the task boundaries, connect the tools, write the guardrails, build the evaluation set, monitor the behaviour, and investigate the failures. That effort is roughly fixed regardless of volume — which means volume decides whether it pays.
A task performed a handful of times a month, by a person who knows it well, in a few minutes each time, is almost never worth an agent. The build and upkeep will cost more attention than the task ever consumed, and the low run count means failures surface slowly — you might need months to discover a flaw a high-volume process would expose in a day. Low-volume work has a further property that argues for humans: each instance tends to be unusual, and unusual is precisely where agents are weakest and least tested. Save the engineering for work that is frequent enough to measure and repetitive enough to learn.
Can a wrong action be caught and undone?
The most important question on this list. An agent does not just produce output; it acts — sends the email, posts the payment, updates the record, places the order. Before granting that ability, ask what happens when the action is wrong. Wrong is not a possibility to eliminate; it is a rate to manage. The question is whether the blast radius of a single wrong action is survivable.
Some actions are naturally recoverable: a draft can be discarded, a flagged record re-reviewed, an internal status corrected. Others are not: a payment released to the wrong account, a price quoted to a customer, a regulatory filing submitted, a contractual notice sent. If a wrong action would be irreversible — or worse, invisible, taking effect silently with no log entry a person would ever review — an autonomous agent has no business taking it. The workable pattern is to let the agent do the reading and preparation, then put a human approval in front of the irreversible step. That is not a failure of automation; it is what guardrails around agents are for. Autonomy should end exactly where recoverability ends.
Do you have ground truth to evaluate against?
To run an agent responsibly you need to know how often it is right, and to know that you need ground truth: a set of cases where the correct answer is established, against which the agent's behaviour can be scored. For document extraction, that is verified field values. For a triage agent, correctly-routed historical cases. For a reconciliation agent, matches confirmed by a person.
If no such reference exists — because the task is novel, because "correct" is contested, or because nobody has ever recorded outcomes — then you cannot measure the agent, and an unmeasured agent is an act of faith. You will not know its error rate, whether a prompt or model change made it better or worse, or whether it is drifting. Teams in this position tend to substitute vibes for evaluation: the demo looked good, so ship it. The discipline of evaluating agent reliability has to come first. If ground truth does not exist, the honest sequence is to run the process manually for a period, record the decisions, and only then automate against that record.
What to use instead
None of this argues against automation — it argues for matching the tool to the shape of the problem. Deterministic and stable: script it. Single-step interpretation: one model call plus validation. Low volume: leave it with a person, perhaps with a model assisting. Irreversible actions: agent prepares, human approves. No ground truth: measure manually first, automate second.
The pattern across all five is the same. Agents are expensive judgment, and expensive judgment should be spent only where judgment is actually the bottleneck — multi-step work, variable inputs, decisions that cannot be enumerated in advance, at a volume that repays the investment. Where those conditions hold, agents are genuinely useful, and deploying them well is a discipline of its own. Where they do not, the boring tool is the better one — and choosing it is not caution, it is competence.