Answer
When is ordinary automation better than AI automation?
Whenever the rule can be written down. A rule runs identically every time and can be read by whoever inherits it.
Whenever the decision can be written as a rule. Rules are free to run, behave identically every time, and can be read and corrected by whoever inherits them. Use a model only where the input is genuinely unstructured language.
A great deal of what gets built as AI automation is a rule wearing a model. If the enquiry mentions a postcode outside the service area, decline it. If the invoice total exceeds a threshold, route it for approval. If the form has no phone number, send the follow-up. Each of these is a condition, and a condition expressed as code costs nothing per execution, behaves identically forever, and can be understood by anyone who opens it.
The model earns its place where the input is genuinely unstructured. Reading an enquiry written in prose and working out what the customer wants. Summarising a call. Deciding whether two differently worded descriptions refer to the same thing. Drafting a reply in the register of previous ones. These resist expression as rules, and attempts to express them produce brittle keyword logic that fails on the first message phrased unusually.
The practical shape most businesses want is a hybrid, with the model doing the narrow linguistic step and rules doing everything around it. Extract the fields from the enquiry with a model; decide what to do with the fields using rules. This is more reliable than either extreme: the model is doing what it is good at, the decision is inspectable, and the failure modes are separable when something goes wrong.
There are three further advantages to rules that get overlooked. They are testable in the ordinary way, so a change can be verified rather than sampled. They are auditable, so you can say why a given item was handled as it was. And they are inheritable, which matters more than anything in a small business: a rule can be read by the next person, and a prompt-driven behaviour has to be inferred from watching it.
The failure to watch for is a rule set that keeps growing exceptions. Where the conditions multiply past the point anyone can hold them, that is a signal that the underlying decision is not really rule-shaped, and continuing to add branches produces a system nobody can change safely. That is the legitimate moment to consider a model step, and it arrives later than enthusiasm suggests.
One cost-related note. Rules do not consume tokens, do not vary with provider pricing, and do not need a network call. For high-volume steps this matters materially, and it is a straightforward reason to keep the model on the narrow part of the path rather than in the middle of every item.
If you can write down what should happen, write it down; the model is for the part you cannot write down.
Siddharth Sharma, Context Theory
Related questions
Is it worth replacing an existing model step with rules?
Where the step turns out to be a rule, yes, and it usually pays for itself quickly through cost and predictability. The way to find out is to look at what the model actually returns: if the outputs cluster into a small set of outcomes determined by a few input features, the rule is already visible in the data and can be written.
What about rules that need to change often?
Frequent change is an argument for making the rules editable rather than for replacing them with a model, since a model whose behaviour changes requires a different kind of intervention that is harder to verify. A rules table someone can edit is the usual answer, and it keeps the change visible and reversible.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
2026 speed-to-lead benchmark · verified
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Software | A condition expressed as code executes identically every time at no per-item cost and can be read by anyone who opens it, none of which holds for the equivalent decision made by a model. | Comparing per-item cost and output variance for the same decision implemented as a rule and as a model call. |
| Workflow | The hybrid shape — a model extracting structure from unstructured language and rules deciding what to do with the result — separates the failure modes, so an error can be attributed to extraction or to logic rather than to the workflow as a whole. | Tracing an incorrect outcome in a hybrid workflow to either the extracted fields or the rule applied to them. |
| Procurement | Rules are testable, auditable and inheritable, and the third matters most in a small business because a rule can be read by a successor while a prompt-driven behaviour must be inferred from observing it. | Asking someone unfamiliar with the workflow to state what it will do with a given input, from the artefacts alone. |
| Response | A rule set accumulating exceptions past the point anyone can hold them indicates the decision is not rule-shaped, which is the legitimate trigger for a model step and arrives later than expected. | Counting the branches in an existing rule set and asking whether anyone can state the behaviour without reading it. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one