I run 35 agents in production. They handle real work on a real schedule and they have been running long enough to have a failure history rather than a demo. That number is the reason I can be specific about this: most of what I have learned about where agents belong, I learned from the places they did not.

Condition 1: the task is deterministic

If the same input must always produce the same output, an agent is a worse implementation of a function. You are paying inference cost and latency to reintroduce variance that the task specifically does not want. The test is not whether the task is complex, since plenty of deterministic work is fiendish, but whether a second run on identical input is allowed to differ. If the answer is no, write the code.

The common failure here is subtler than "we used an agent for arithmetic". It is wrapping a deterministic core in an agent because the inputs arrive messily. Messy input is a parsing problem. The fix is one LLM call that normalises the input, feeding deterministic code that does the actual work. You keep the language understanding and you keep the guarantees.

Use instead: a script, or a single LLM call inside deterministic control flow.

Condition 2: a wrong answer is expensive or irreversible

Agents do not fail the way software fails. A null pointer throws. A timeout throws. An agent that has misunderstood the task produces a fluent, confident, well-formatted wrong answer and reports success. Nothing in the logs is red. I have written about how this compounds across handoffs; the relevant point here is narrower. Where the cost of a silent wrong answer is high, the absence of a loud failure mode is disqualifying on its own.

This is not an argument against agents near expensive decisions. It is an argument about where the agent sits relative to the decision. Preparing the inputs for an irreversible call is excellent agent work. Making the call is not.

The confidence problem underneath this is measurable, and the measurement is more specific than the folklore. Anthropic's Language Models (Mostly) Know What They Know found models reasonably well calibrated when scoring a fixed set of options, and losing that calibration on unfamiliar tasks. An agent chaining open-ended steps is squarely in the second case, which is why "the model will flag it if it is unsure" is not a control you can design around.

Use instead: agent-prepared inputs, human decision, deterministic execution.

Condition 3: the work is high-volume and low-margin

Script economics and agent economics diverge in opposite directions as volume grows. A script's cost per run trends toward zero; the work was done once, when it was written. An agent's cost per run is roughly flat: every execution buys the same tokens and the same seconds again. At low volume that difference is invisible. At high volume it is the entire business case, and it is running the wrong way.

Latency compounds the same way. Sub-second matters at scale, and an agent that reasons before acting is not operating in that regime. If the per-item margin is thin and the item count is large, the agent has to be doing something a script genuinely cannot, not merely something nobody has got around to scripting.

Use instead: a script for the volume, an agent for the exceptions it kicks out.

Condition 4: nobody owns supervision

This is the one that gets budgeted at zero, and it is the one that has cost me the most.

Supervising 35 agents takes three distinct layers, and they exist because each catches something the others structurally cannot. A passive heartbeat, where absence is the signal. A watchdog that reads process state and owns recovery, because deciding whether to restart requires knowing whether the agent is stuck or legitimately working. And an active probe that round-trips a real request every few minutes, because the failure mode that taught me the most was an agent whose host process was healthy, whose CPU looked normal, and whose connection to the outside world had silently died. Every internal signal said fine. Only an end-to-end probe disagreed.

None of that is model quality. None of it gets cheaper when the model improves. It is the standing cost of running processes that fail without erroring, and it does not appear on anyone's pilot budget. If you cannot name the person who gets paged when an agent goes quiet, you do not have automation. You have an unmonitored process with a credit card.

If you want the formal version of this argument, NIST's AI Risk Management Framework (AI 100-1) assigns trustworthiness to the organisation running the system rather than to the system itself, and its Govern function is explicit that accountability structures come before deployment rather than after it. My version of that is less elegant and says the same thing: name the pager first.

Use instead: nothing. Fix the supervision gap first, then revisit.

The heuristic that actually decides it

Count decision volume, not task volume. Not how much work there is, but how many genuinely novel decisions a single run requires, the ones where a human would have to look at the specific case and choose.

Most disappointing agent projects I have seen were row two implemented as row four. The task had language in it, language implied an LLM, and an LLM somehow implied handing over control flow. It does not. You can have the language understanding and keep the guarantees, and that combination is where most of the durable value has been.

Questions worth asking before the next agent goes in

A team that cannot answer the fourth question is not ready for the first three. Back up to the agentic AI pillar for the wider framing.

Frequently asked questions

When should you not use an AI agent?

Four conditions rule an agent out. First, when the task is deterministic, meaning the same input must always give the same output, which is what code is for. Second, when a wrong answer is expensive or irreversible, because agents fail silently rather than throwing errors. Third, when the work is high-volume and low-margin, since per-call inference cost and latency scale linearly while a script amortises to nothing. Fourth, when nobody owns supervision, because an unsupervised agent is not automation, it is an unmonitored process with a credit card.

What is the difference between an AI agent and automation?

Automation executes a path someone already decided. An agent decides the path at runtime. That distinction is the whole cost model: automation is cheap, testable, and repeatable, while an agent buys you the ability to handle inputs nobody enumerated in advance, and charges you variance in exchange. If you can enumerate the branches, you do not need an agent to choose between them.

Is there a rule of thumb for when agents are worth it?

The useful heuristic is decision volume, not task volume. Count the genuinely novel decisions the work requires per run. If that number is zero, use a script. If it is one or two and they are enumerable, use a rules engine with an LLM call at the branch point. If the decisions are open-ended and a human would otherwise make them one at a time, an agent starts earning its keep — provided somebody is watching it.

Do better models remove these limits?

Only the accuracy limit, and only partially. Model quality reduces per-step error rates, but it does not make a deterministic task non-deterministic, does not lower per-call latency into script territory, and does not supervise anything. Three of the four conditions are structural properties of the task, not capabilities of the model, which is why they have survived several model generations unchanged.

What should you use instead of an AI agent?

Match the tool to what is actually varying. Fixed path with fixed logic: a script or a scheduled job. Fixed path with fuzzy content: a single LLM call inside deterministic code, which gives you language understanding without handing over control flow. Branching path with enumerable branches: a rules engine or state machine. Open-ended path where a human would otherwise decide case by case: an agent, with supervision budgeted from day one.