AI agents versus traditional workflow automation
They solve different problems and they are priced differently. Knowing which one a workflow needs is the difference between a two-week project and a six-month science experiment.
7 min readAI agents, Workflow automation, Architecture
The phrase "AI automation" hides two very different kinds of system. One has been reliable for twenty years. The other is new, genuinely useful, and much easier to get wrong.
Traditional automation: if this, then that
Traditional automation is a set of rules executed in order. A form is submitted, a row is created, a notification is sent, a spreadsheet is updated.
Its defining property is that you can predict the output for any given input, and you can explain why. When it breaks, it breaks loudly and in a way that points at the broken rule.
This is the right tool for the majority of operational work. Invoicing, synchronization, routing on known fields, scheduled reports, notifications, and anything where the input already has a defined shape.
AI agents: judgement inside a boundary
An agent is useful when the input does not have a shape yet. It reads an email, a transcript, or a document, and produces structure that rules can then act on.
The important word is boundary. An agent that is allowed to do anything will eventually do something you did not intend. An agent that reads a document, extracts five fields, and proposes a category is a small, testable component that you can measure.
In practice, the agent is a step inside a larger deterministic pipeline, not the pipeline itself.
How to choose
Ask what is uncertain about each step.
| Step characteristic | Use |
|---|---|
| Input is a known field or event | Rules |
| Output must be byte-for-byte predictable | Rules |
| Input is free text, email, or documents | Agent |
| Decision needs judgement or a policy read | Agent, with a threshold |
| Customer-facing action, refunds, pricing | Rules, with human approval |
| Volume is high and each case is boring | Rules |
The mistake we see most
Businesses buy an agent to do a job that rules should be doing. A typical example: an agent is asked to decide whether an invoice is approved, when the rule is simply whether a purchase order number is present and the amount matches.
The agent is slower, more expensive, and less predictable than five lines of logic. Meanwhile nobody has automated the part that was actually hard, which was reading the invoice in the first place.
The inverse mistake is also common: a team tries to write rules for a task that will never have rules, such as categorizing free-form customer complaints, and spends a year maintaining a list of keywords.
A practical split
For a typical back-office workflow, we expect the split to look like this:
- Rules for intake, routing, retries, thresholds, approvals, write-backs, and notifications.
- Agents for extraction, classification, summarization, and drafting.
- Humans for exceptions, judgement calls with money attached, and anything a customer will read before the first automation cycle has proved itself.
The split matters commercially. Rules are cheap to run and cheap to maintain. Agents cost per call and drift when models or inputs change, so they should be used deliberately and measured continuously.
What to ask a vendor
- Which steps of this workflow will be deterministic?
- Which steps use a model, and how is the output validated?
- What happens when the model is wrong?
- How will I see the error rate?
- What is the cost per item processed at my volume?
A vendor who cannot answer these is selling a demo, not a system.