At a glance
- Eight conditions rule out an AI agent on their own: written-down rules, zero error tolerance with no review step, thin data, low volume, an unmeasurable outcome, no owner for exceptions, a regulated decision needing case-by-case explanation, or a tool you already own.
- Each condition points to one alternative: deterministic automation, RPA, configuring what you already pay for, a process fix, or manual review — the right-sized choice, not a lesser one.
- A single, narrowly scoped LLM call can cover the one judgment step, without putting the rest of an otherwise deterministic workflow through an agent.
- A five-minute self-check turns the eight conditions into a decision you can make before anyone starts building.
The cost of the wrong tool
This article isn't about whether AI agents work. It asks a narrower question: which workflows should rule one out before anyone builds it? Anthropic's own engineering guidance puts the underlying principle plainly: [1] "we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all." An agent is one of the most complex tools available; complexity has to earn its place.
Anthropic draws a specific line between the two main options: [1] "Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."
In plain terms: Anthropic's workflows still call a model on a fixed path. Deterministic software — a rules engine, RPA, a workflow script — skips the model, running on code alone. An agent picks its own path as it goes.
- A build paid for on a problem a workflow-automation script would have solved for less.
- A review step that slows the process down, or gets skipped once volume grows.
- Ongoing monitoring on a task a deterministic system would have run unattended.
Disqualifying conditions
The OECD's AI Principles frame the underlying discipline this way: [3] "AI systems must function in a robust, secure and safe way throughout their lifetimes, and potential risks should be continually assessed and managed." That assessment should start before a build, not only after it. The table below turns it into eight conditions: any single row rules an agent out, and a workflow can fail more than one.
| Condition | Why it disqualifies | Better alternative | Signal that would change the answer |
|---|---|---|---|
| The task reduces to a rule you can write down | If every input already maps to one output through logic you can state today, a model adds uncertainty a rule never needed. | Deterministic automation: code, a rules engine, or an RPA script running the same path every time | The exceptions to the rule start multiplying faster than you can write them down |
| A wrong answer is costly, and nothing checks it before it acts | Don't let an agent check its own output: without a person or rule between its answer and the action, a mistake reaches production the same way a correct answer would. | Manual handling, or an automated step that only executes after a named person signs off | A review step can be added cheaply enough to catch a mistake before it causes damage |
| There isn't enough real data or examples to build or test against | A system without enough recent real cases can't be evaluated, so there's no way to judge whether its output is right. | Run the process by hand until it produces the examples a system would need, or fix the data gap | Enough recent, real cases exist to build an evaluation set that looks like production |
| The volume is too low to justify owning a system | Much of the cost of owning a system — the license minimum, the monitoring routine, an owner's standing time — is largely fixed, so it doesn't shrink with volume the way manual hours do. | A shared tracker with a named reviewer, or a scheduled weekly batch run | The fixed cost of owning a system becomes smaller than the manual hours it would replace |
| Nobody can say what "working" means for this task | Without a number to tell them apart, an agent that's helping and one that's quietly making things worse look the same. | Pick the single output metric that matters, then score a sample of the current process against it before writing any code | A measurable definition of success exists, and someone has signed off on it |
| No one owns the cases the system can't resolve | Every system meets inputs outside what it was built for, and without a named owner those cases pile up unreviewed. | Name an owner before building, or keep the process manual until one exists | Someone with the authority and time to own the exception queue is named |
| A regulated or high-stakes decision needs a case-by-case explanation | If compliance or counsel requires a case-by-case explanation, a system whose reasoning can't be reconstructed for that case doesn't meet the bar. | A written decision table or scorecard, where every outcome traces to a stated rule the reviewer can cite for that case, and a named person decides whatever the rules don't cover | Your compliance team or counsel confirms what the explanation must contain, and the system can produce it for every case |
| A tool you already pay for already does this | Building a system to duplicate a capability you already license adds one more thing to secure and maintain, for nothing new. | List the cases the licensed tool gets wrong and take them to the vendor or your admin as a configuration or support request before scoping a build | The vendor confirms in writing that the gap isn't configurable and isn't on its roadmap |
One condition maps onto NIST's own language: its AI Risk Management Framework states that risk management efforts "may need to include human intervention in cases where the AI system cannot detect or correct errors" [2]. NIST defines the terms behind the explainability condition this way: "Explainability refers to a representation of the mechanisms underlying AI systems' operation, whereas interpretability refers to the meaning of AI systems' output in the context of their designed functional purposes." [2].
Better alternatives, and when each wins
Each condition above points to one of five alternatives, each built for its own situation, not a fallback.
- Deterministic automation
Serves rows 1 and 7: once you can write today's rule down without new exceptions piling up, code it once — the same path every time. A decision table or scorecard applies the same idea to a regulated call: write the rule for every outcome you can, and route the rest to a named person.
- RPA (robotic process automation)
Serves row 1 when the rule has to run across screens and files, not through an API: script the click-and-file-move sequence instead of handing a model control of it.
- Configuring a tool you already own
Serves row 8: list the cases the licensed tool gets wrong and take them to the vendor or admin as a configuration or support request before scoping a build — usually cheaper than a new one.
- A process change
Serves rows 3, 5 and 6: run the work by hand for a set period, logging each case and its outcome (row 3); get the sponsor to sign off the metric in writing (row 5); write the exception owner and response time into the procedure (row 6).
- Manual review
Serves rows 2, 4 and 7: at low volume, where a wrong answer can't be tolerated, or a decision needs a case-by-case explanation, a person handling it costs less than a system built to replace them.
One more option sits between deterministic automation and a full agent: a single, well-scoped call to a model. Anthropic's own guidance is direct about when that's enough: [1] for many applications, "optimizing single LLM calls with retrieval and in-context examples is usually enough." Use one for a single bounded judgment call, with a narrow input and output and nothing downstream that needs it to loop back.
An agent earns its cost only once none of the alternatives above wins on its own. Our AI agent implementation page covers how we scope and build one at that point.
Borderline cases: when a small AI step inside deterministic automation is enough
Some workflows fail only one condition, in one place: the process is rule-based except one step needing judgment on messy input, like a free-text field. Routing the whole workflow through an agent for that one step is its own version of the wrong tool; the fix is a single, tightly scoped model call inside the workflow.
- Its input and output stay narrow — a category, a label, a field value — never an open-ended action.
- The deterministic workflow still owns every decision and audit trail; the model call only supplies one input.
- That call still clears its own bar on error tolerance, volume, and ownership, or it doesn't belong in the workflow yet.
A five-minute self-check
Run a candidate workflow through these checks; they cover six of the eight conditions (see the table for review-step and explainability).
- Write the rule
State the decision as an if/then rule in one sitting. If you can, without exceptions piling up, stop here and build deterministic automation.
- Name the volume
Say how many times a month the task runs, then weigh the manual effort against the ongoing cost of owning a system.
- Check the data
Pull a sample of recent, real cases — a few dozen, or whatever your volume allows. If they don't exist or don't look like production, there isn't enough to build or test against.
- Name the owner
Say out loud who receives a case the system can't resolve. No answer means the exception queue has no owner.
- State the measure
Pick the one output metric that matters, then score that same sample against it. No metric and no scored sample means it isn't ready to automate.
- Ask what you already own
Ask the admin or vendor contact for each system this workflow touches which of its steps that system already handles.
What to do next
If any one of the eight conditions applies, the workflow isn't ready for an agent yet. Fix the condition, or use the alternative it points to.
If you're not sure which workflows are candidates, that's a diagnosis question, not a build question. Our 360° AI Blueprint ranks AI and automation candidates by ROI, cost, and time-to-value before anyone commits to building.
Related reading
- Our AI readiness assessment covers the data, process, and sponsorship questions to answer before hiring a build partner.
- The 360° AI Blueprint ranks your automation candidates before you build anything.
- Rows 2 and 6 above both come down to who's watching the output once a system runs; our guide to human-in-the-loop AI governance covers how to assign and staff that role once a workflow clears every other condition here.
Frequently asked questions
When should you not use an AI agent?
Rule an agent out when the rules are already written down, a wrong answer is intolerable with no review step, there's no reliable data to test against, volume is too low, the outcome can't be measured, no one owns the exceptions, a regulated decision needs a case-by-case explanation, or an existing tool already does the job.
What's the difference between an agent and a workflow?
A workflow follows a path defined in advance, whether or not it calls a model along the way, and runs that same sequence every time. An agent decides its own path as it goes: which tool to call, in what order, and when it's done, without a sequence fixed ahead of time.
Is an agent better than RPA?
Not by default; they solve different problems. RPA wins when the work is a sequence of clicks and file moves between systems, and none of it needs judgment on messy input. An agent earns its cost when the work also needs judgment a fixed script can't make.
Should I use a single LLM call instead?
Often, yes, when the task is one bounded judgment call, such as classifying, summarizing, or extracting a field, inside an otherwise deterministic process. A single, narrowly scoped model call does that job without the autonomy, cost, and review burden of a full agent built around it.
Who is actually getting value from agents?
Teams whose workflow already clears the disqualifying conditions above: real volume, judgment that doesn't reduce to a rule, real data, a measurable outcome, a named exception owner, tolerance for a reviewed mistake, no duplicate licensed tool, and, where compliance requires a case-by-case explanation, a system that can produce one.
Sources
- [1] — Anthropic, "Building Effective Agents" (2024-12-19), "What are agents?" and "When (and when not) to use agents" sections (accessed 2026-09-28)
- [2] — NIST AI RMF 1.0 (January 2023), Section 3, "AI Risks and Trustworthiness" (Sections 3.1 and 3.5) (accessed 2026-09-28)
- [3] — OECD AI Principles, Principle 1.4, "Robustness, security and safety" (Recommendation adopted 2019-05-22, amended 2024-05-03) (accessed 2026-09-28)
More in AI strategy
AI Agents vs. RPA for Hotel Back-Office Operations: When Bots Break and What Replaces Them
AI agents vs RPA for hotel back-office operations: a decision table for OTA statement matching, folio audit and multi-property AP, plus how to phase bots.
Hotel Management CompaniesWhat a 360 AI Blueprint Costs for a Food & Beverage Manufacturing Back Office
What drives food and beverage manufacturing AI cost in the back office: a table of plants, co-packers, deductions and traceability scope, plus how to budget.
Food and Beverage ManufacturersAI Implementation Cost for Multi-Rooftop Dealer Groups: What Changes When You Add a Store
AI implementation cost for multi-rooftop dealer groups: a driver table showing how DMS count, OEM portals, build type and upkeep move cost per added store.
Auto Dealerships