AI Automation vs Traditional Automation
Rules are cheap, predictable and testable. Models handle mess. Knowing which to use where is most of the skill - and using a model where a rule would do is a common, expensive mistake.
Automation has existed in business software for decades. What changed recently is that some of it can now handle unstructured input - messy text, varied document layouts, requests phrased however the person felt like phrasing them.
That is a genuine expansion of what can be automated. It is not a replacement for what came before, and treating it as one is how automation projects become expensive and unreliable.
Traditional automation: rules
Rule-based automation follows instructions you write. If this, then that. When a form is submitted, create a record. When status changes to shipped, send this email. When the date is the first of the month, generate the report.
Its properties:
- Deterministic. The same input always produces the same output.
- Testable. You can verify it exhaustively.
- Cheap to run. Effectively free per execution.
- Fast. Milliseconds.
- Debuggable. When it goes wrong you can trace exactly why.
- Brittle. It handles exactly the cases you anticipated and nothing else.
That last point is the limitation. A rule that expects an invoice number in a specific field fails when the supplier changes their template.
AI automation: models
AI automation uses a model to interpret input that does not follow a fixed structure. Read this email and work out what the customer wants. Extract the total from this invoice, whatever layout it uses. Classify this ticket by urgency.
Its properties:
- Probabilistic. The same input may not always produce identical output.
- Handles variation. This is the entire point - it generalises to cases you did not anticipate.
- Costs per execution. Every call has a price, small but not zero.
- Slower. Seconds rather than milliseconds.
- Harder to test. You cannot enumerate every input.
- Can be confidently wrong. This is the important one. A rule that fails usually fails visibly. A model that fails often produces a plausible answer that happens to be incorrect.
The choice is not either/or
Real automations use both, and the useful skill is knowing which layer each step belongs in.
A typical pipeline:
- Trigger - an email arrives. Rule.
- Filter - is this an invoice? Rule, or a cheap classifier.
- Extract - pull supplier, total, date, line items from a layout you have not seen before. Model. This is what it is for.
- Validate - does the total match the line items? Is the date plausible? Is this supplier known? Rules. Absolutely rules.
- Decide - under a threshold and validation passed, proceed. Otherwise flag for review. Rule.
- Act - create the record. Rule.
The model does one job: turning mess into structure. Everything around it is deterministic, because everything around it benefits from being predictable.
This is the pattern we build to, and it is why our AI automation work usually contains less AI than people expect.
Using a model where a rule would do
A common and avoidable mistake.
If your input is already structured - a form with defined fields, a database record, an API response - you do not need a model to interpret it. You know what the fields are. Writing a rule is cheaper, faster, more reliable, and testable.
We have seen automations that call a language model to decide whether a number is greater than a threshold. It works. It also costs money per execution, adds latency, introduces a dependency on an external service, and occasionally gets it wrong - for a comparison that is one line of code.
The rule of thumb: use a model only where the input is genuinely unstructured, or where the judgement genuinely requires interpreting language. Everywhere else, use a rule.
Where models genuinely earn their place
Unstructured text. Free-text enquiries, emails, chat messages, reviews, notes.
Varied document layouts. Invoices from two hundred suppliers, each formatted differently. This is very hard with rules and straightforward with a model.
Classification with fuzzy boundaries. Is this ticket a complaint, a question or a cancellation request? Rules based on keywords fail on phrasing they did not anticipate.
Summarisation. Condensing a long thread into something someone can act on.
First drafts. Producing a starting point a human then edits.
Semantic matching. Finding relevant information when the query does not use the same words as the source.
Reliability is the real difference
This is the practical distinction that should drive your architecture.
Rule-based automation fails loudly. The API returns an error, the field is missing, the process stops. You find out.
Model-based automation can fail quietly. It returns a well-formed answer that looks right and is wrong. Nobody notices for three weeks.
Which is why validation is not optional. Every model output that feeds a downstream action needs deterministic checks around it: is the value in a plausible range, does it match a known reference, does it satisfy an internal consistency check. When it does not, stop and notify rather than continue.
And where the output is customer-facing or hard to reverse, a person approves it. Not because the technology is untrustworthy, but because that is how you take the time saving without inheriting a new category of risk.
Cost, honestly
Rules cost almost nothing per execution. Models cost a small amount each time, which is negligible at low volume and becomes material at high volume.
Worth calculating before you commit. An automation processing fifty items a day is inexpensive at any sensible price. One processing fifty thousand needs the maths done, and often needs a cheaper model for the routine cases with a better one reserved for the hard ones.
Also worth monitoring in production, because volume grows and prices change.
A short decision guide
| Situation | Use |
|---|---|
| Input is structured and predictable | Rule |
| Input is free text or varied documents | Model |
| Decision follows explicit criteria | Rule |
| Decision requires interpreting language | Model |
| Output must be exactly right every time | Rule, or model plus human review |
| High volume, low value per item | Rule where possible |
| Cases you could not enumerate in advance | Model |
Most useful automations are mostly rules with a model doing one specific job in the middle. If your design has a model at every step, it is probably more expensive, slower and less reliable than it needs to be.
We use a rule wherever a rule will hold and reserve models for the parts that genuinely need them. Tell us about the process and we will tell you what it actually needs. More on AI automation.