When Not to Use an AI Agent (and What to Build Instead)
We build agents for a living, which is exactly why this page exists. The fastest way to damage a team's confidence in this technology is to put an agent on a task that never needed one, watch it be 94% right where a script was 100% right, and spend the next quarter defending it.
Below are the six situations where we say no, and the thing we suggest instead. None of them is a statement about model capability; they are statements about where nondeterminism is a cost rather than a feature.
1. The steps never change#
If the sequence is fixed — pull file, validate columns, transform, load, notify — you do not need anything to decide what happens next, because nothing decides. Write the pipeline. If one step needs judgement, such as classifying a free-text field, call a model for that one step and keep the rest deterministic. You get the model where it helps and predictable behaviour everywhere else.
This is the single most common overbuild we see. A model call inside a pipeline is not a lesser thing than an agent; it is the correct thing.
2. The task is arithmetic or exact matching#
Totals, reconciliations, tax, eligibility rules with published thresholds: these have right answers and existing implementations. A model can explain a calculation beautifully and still get it wrong occasionally, and occasionally is a catastrophe in finance. Compute in code, then let the model do what it is genuinely better at — explaining the result to a person in their own language.
3. Latency budget under a second#
An agent that plans, calls two tools and answers cannot reliably do it in under a second, because each model call has its own latency floor. If you are inside a checkout, a search-as-you-type box, or a call routing decision, either move the work off the critical path and show the result later, or use a classifier and a lookup. Users forgive a slow answer they asked for; they do not forgive a slow page.
4. Nobody can say what a correct run looks like#
If the team cannot produce twenty examples of the task done right, you have no evaluation set — and without an evaluation set you have no way to know whether a change helped. Build the examples first. Often the act of writing them reveals that the task is really three different tasks, two of which are trivial and one of which is the real problem.
Twenty labelled examples is a low bar deliberately. If a team cannot reach it, the task is not yet understood well enough to automate by any method.
5. Every action is irreversible and high value#
Wire transfers, contract signatures, production deletions. You can absolutely put an agent in front of these — as a drafter that assembles the case and hands it to a human. What you should not do is give an autonomous loop unattended write access to something that cannot be undone, on the strength of an accuracy figure from a test set that did not contain your worst week.
6. The data it needs is not accessible#
An agent is only as capable as its tools, and its tools are only as capable as your APIs. If the information lives in a system with no read API, or in a spreadsheet that three people edit by hand, the agent will be reduced to guessing. Fix the access first. That work is unglamorous and it is also the majority of the value: teams that build the read API often find the agent afterwards is a two-week job.
Frequently asked questions
So when is an agent clearly the right tool?
When the next step genuinely depends on what the last step returned, when several tools might be needed in an order you cannot fix in advance, and when a human currently does this by looking things up and deciding. That combination is where the loop earns its cost.
We already built an agent for a fixed pipeline. Should we rip it out?
Not necessarily — measure first. If it is reliable and the cost is acceptable, leave it and spend your effort elsewhere. Replace it when you can point to a specific pain: unpredictable latency, cost per run, or failures nobody can reproduce.
Can an agent be part of an otherwise deterministic system?
Yes, and that is often the best design. Keep the spine deterministic and give the agent one bounded region where judgement is required, with a clear contract on what it may return. You get flexibility where you need it and predictability everywhere else.
when not to use ai agentsagent vs workflowllm automation limitsai project scopingagent alternatives
