Not every workflow needs an agent. Deterministic automation is cheaper to build, cheaper to run and easier to assure — here is how to tell which one you are looking at, before you pay for the wrong one.
There is a lot of pressure at the moment to put an agent on everything. It is worth resisting, not out of caution, but because deterministic automation is genuinely better at a large share of the work.
Rules are cheaper to build, cheaper to run, faster, and — the part that matters most in a regulated setting — they behave the same way every time, which makes them straightforward to assure. If a process is predictable and the rules are stable, an agent is a more expensive way to get a less predictable result.
The test
Four questions. If the answers are all on the left, use rules.
- **Does the input vary?** A fixed-format EDI message is a rules problem. An email from a supplier who writes it differently every time is not.
- **Does the next step depend on meaning?** Routing by a field is a rules problem. Routing by what the message is actually about is not.
- **Can you enumerate the cases?** If you can write them down, write them down. If the list keeps growing every time you look at real examples, that is a signal.
- **How much does being wrong cost?** A wrong answer to a status enquiry is an annoyance. A wrong eligibility decision on a regulated product is a different conversation, and it raises the assurance burden for anything non-deterministic.
Most real workflows are both
The useful design is rarely all one or the other. A typical workflow has AI at the edges, where input is messy and meaning matters, and rules in the middle, where the process is defined.
Interpret the incoming request with AI, because it arrives as prose. Apply eligibility with rules, because the policy is written down and must be applied identically every time. Take the action deterministically, because the system call is the system call. Escalate with rules, because the escalation policy is a policy.
That design is cheaper than an agent doing all four, and considerably easier to explain to a reviewer.
A worked example
Supplier invoices arrive as PDFs, some machine-generated, some scanned, from a few hundred suppliers who all lay them out differently.
Extraction is not a rules problem. Layouts vary, scans are imperfect, and maintaining a template per supplier is a job nobody wants. Use AI, and give it a confidence score.
Matching the extracted lines against the purchase order is a rules problem. The tolerance is defined, the currency conversion is defined, and the answer must be identical every time.
The threshold between them is a decision, not a technicality: below what confidence does a document go to a person instead of into the ledger? Set it deliberately, measure it, and move it on evidence.
What the agent version costs you
If you put an agent across the whole flow, four things get harder. Cost per item rises, because every step is a model call. Latency rises. Behaviour becomes harder to test, because the same input can produce different output. And assurance gets more expensive, because “why did it do that” now has a longer answer.
None of that is a reason to avoid agents. It is a reason to use them where they earn it.
The assumptions to check
- The input really does vary. Look at a hundred real examples rather than assuming.
- The rules really are stable. If they change monthly, that changes the calculation.
- You have measured extraction or interpretation accuracy rather than assumed it.
- Someone has decided what confidence level sends an item to a person.
Key takeaways
- Deterministic automation is cheaper, faster and easier to assure; prefer it where it fits
- Use AI where input varies or the next step depends on meaning
- Most good designs are both, with the boundary chosen deliberately
- Set and measure the confidence threshold that sends work to a person
- The cost of an agent is not only the model call; it is testing and assurance too