Automation vs AI: how to tell which one you actually need
Not every problem needs a language model. A short, honest decision framework for choosing between rules-based automation and AI — with a worked example on invoice intake.
"Should we use AI for this?" is almost always the wrong first question. The right one is: is this problem deterministic, or does it need judgement?
Get that split right and the rest of the decision — cost, reliability, maintenance — mostly makes itself.
Two different tools, often confused
Rules-based automation does the same thing every time. If a file lands in this folder, move it. If a Stripe payment comes in, create a row in the CRM and send a receipt. If a form is submitted, notify Slack. The logic is explicit. You can read it. It runs in milliseconds and costs almost nothing per execution.
AI-based automation — really, LLM-based automation — makes judgement calls on unstructured input. It reads a support email and decides which category it fits. It reads an invoice PDF from a supplier it has never seen before and pulls out the total. It writes a first draft reply in the tone of your brand.
Both are "automation." They have very different failure modes.
A four-question decision framework
Before adding a language model to a workflow, walk through these:
- Is the input structured? If it arrives as a webhook, a form submission, or a row in a table, you almost certainly do not need AI. Wire it up with rules.
- Is there one correct answer? If yes, a rule beats a model every time. Models are for cases where "reasonable answer" is the bar.
- How bad is a wrong answer? If wrong is expensive (billing, legal, safety), you need a human review step whether you use rules or AI. If wrong is cheap (a mis-categorised newsletter signup), full autonomy is fine.
- How often does the shape of the input change? Rules are cheap to run but expensive to maintain when the world keeps changing. AI is more expensive per run but shrugs off small variations. Volatile inputs push you toward AI.
If the first two answers are "yes," stop. Use n8n, Zapier, or a small script and move on.
A worked example: invoice intake
A mid-sized company receives 400 supplier invoices a month, roughly half by email PDF, half through supplier portals as structured data.
The portal invoices are structured. Fields are labelled. The right tool is a rules-based integration: pull from the API, map to the ERP schema, done. Reliability is 100% because there is nothing to interpret.
The email PDFs are the interesting half. They arrive from ~80 different suppliers, each with their own template, some scanned, some digital. Writing rules for every layout is a losing game — a new supplier means a new rule, and layouts change without notice.
This is where a language model earns its cost. An LLM with vision reads the PDF, extracts the fields, and returns structured JSON. A validation step checks that the total matches the sum of line items and that the supplier exists in the ERP. Anything that fails validation goes to a human queue. Anything that passes goes straight through.
Cost per invoice, at current API pricing: a few cents. Time saved per invoice: a few minutes. The payoff is obvious. But notice what happened — you didn't replace the rules-based half. You used AI only where rules were the wrong tool.
Cost and reliability, honestly
Rules-based automation, once built, is essentially free to run and close to 100% reliable on the cases it was written for. Its weakness is the long tail of inputs no one anticipated.
LLM-based automation costs real money per run — usually cents, sometimes more — and is not deterministic. Two calls with the same input can produce slightly different outputs. It handles the long tail gracefully but you must plan for validation, monitoring, and the occasional wrong answer.
A useful rule of thumb: if you can list every case on a whiteboard, use rules. If the list would run off the whiteboard, use AI.
The best systems are hybrids
In practice, the workflows that actually save time in a business are rarely pure AI or pure rules. They are pipelines: rules do the deterministic parts, an LLM handles the messy interpretation step in the middle, and rules take over again for the "now write this to the database, send this notification, update this status" tail.
Pick the right tool for each step, not for the whole workflow. That's most of the skill.