We deploy AI agents. We also talk clients out of them fairly often, and it is usually the same conversation.
The request arrives as "we want an AI agent for X." Underneath it, X turns out to be a task with clear rules, stable inputs and a correct answer that can be checked. That is not an agent problem. That is a workflow, and an agent will do it slower, less predictably, and at a cost per run that never goes to zero.
The line
An agent earns its place when a task requires judgement over input you cannot fully anticipate.
Classifying an inbound email as a complaint, an invoice query or a sales enquiry is a judgement call over unpredictable text. No rule set covers it, because people write however they write. That is agent work.
Routing an invoice to the right approver based on amount and department is not judgement. It is a lookup and a threshold. An agent will get it right almost every time — and "almost" is the whole problem, because the failures are unpredictable and you will not find them by testing.
The test we use: can you write the rule down? If yes, write it down. Code that implements a written rule is inspectable, testable, free to run, and identical on Tuesday to how it was on Monday. Nothing about a language model improves on those four properties.
What the agent actually costs
The build is not where the cost sits. Three other things are.
It cannot be fully tested. A conditional either branches correctly or it
does not, and you can prove which. An agent has no equivalent guarantee. You can
run it against a hundred examples and get a hundred good outputs, and the
hundred and first is still an open question. That is a fine trade when the
alternative is nobody reading the email at all. It is a poor one when the
alternative is an if statement.
It needs a human boundary. Every agent we deploy has an explicit line where it stops and hands over. Deciding where that line sits is most of the design work — not the prompt. An agent that drafts a reply for approval carries a different risk from one that sends it, and the difference is not technical.
It drifts. Not the model on its own — the world around it. Inputs change shape, an upstream system starts including a new field, a provider ships a new version. A workflow built on written rules fails loudly when that happens. An agent keeps answering, slightly worse, and nobody notices for a month. This is why agent work carries ongoing maintenance in a way that rule-based automation often does not.
Where they genuinely win
Four shapes, in our experience.
Unstructured in, structured out. A document, an email, a transcript, a voice note — something with meaning in it and no schema. Getting to fields you can act on is exactly what this technology is for, and there is no non-AI way to do it that is not a person reading it.
Triage under volume. Not deciding the outcome, deciding the queue. Sorting two hundred inbound items into five buckets so the right person sees the right ones first. Errors here are cheap and self-correcting, because a human still looks at every bucket.
Drafting for approval. The agent produces, a person disposes. The cost of a bad output is a deleted draft. This is the highest-value, lowest-risk shape and the one most teams underuse, because it feels less impressive than automation that acts on its own.
Answering from a known corpus. Retrieval over your own documents, with the sources shown. The value is not the generation — it is not having to know which of four hundred files the answer is in.
Note what these share: in all four, a wrong answer is visible and recoverable. That is the actual criterion. Not accuracy — recoverability.
The hybrid that usually wins
Most of what we build is neither "a workflow" nor "an agent." It is a workflow with one agent-shaped step in the middle of it.
The deterministic parts stay deterministic: fetching, validating, routing, writing to the system of record, retrying, logging. The one genuinely ambiguous step — read this thing and tell me what it is — goes to a model. Then the output is validated against a schema before anything downstream touches it, so a malformed response fails like any other bad input instead of propagating.
That arrangement is testable everywhere except one bounded point, and that point has a known failure mode. Compare it with an agent given broad autonomy over a whole process: untestable everywhere, and failing in ways you hear about from a client rather than from your own monitoring.
Before you ask for an agent
Three questions, worth answering honestly before anyone quotes you for anything:
- What happens when it is wrong? If the answer involves money moving or a client seeing something unreviewed, the agent needs a person in front of it.
- Could you write the rule down if you had an afternoon? Then have the afternoon. It will be cheaper than the agent and it will still work in a year.
- Who looks at the output next month? Not next week, while it is new and interesting. Agent quality degrades quietly. Somebody has to be looking, and that somebody needs naming before the build, not after.
If the honest answers point at an agent, we build them, and the capability library holds a fair number. If they point at a workflow, we will say so, and it will be the cheaper project.