There is a temptation right now to point a language model at every problem. Vendors encourage it, because “AI” sells. We resist it, because a lot of what an owner wants automated is better done with a rule: a piece of ordinary code that does the same thing every time, costs nothing per run, and can be tested once and trusted forever. Knowing which is which is most of the skill in building automations that last.
What a rule is good at
A rule is any decision you can write down completely. If the invoice is over $5,000, route it to the controller. If the job has not been updated in 48 hours, send the reminder. If the ZIP code is in this list, assign this crew. Every night at 6, pull yesterday’s orders and post the summary.
Rules are:
- Deterministic. Same input, same output, every time. You can test them with a handful of cases and know they work.
- Free to run. No model call, no cost per record, no rate limits.
- Explainable. When someone asks why the system did something, the answer is the rule.
- Fast to build. Often an afternoon.
A surprising share of the small automations we ship for clients are rules with good plumbing: a reliable connection to the systems involved, error handling, a log, and a notification. No model anywhere. They are unglamorous and they are the ones that are still running quietly three years later.
What a model is good at
A model earns its place when the input is messy or the decision cannot be written down. Reading a customer email that asks three things in no particular order. Pulling the fields out of a PDF that every vendor formats differently. Drafting a response in a human voice. Classifying a request when the categories are fuzzy and the examples are the only definition anyone can give.
Those are jobs where a rule would need a thousand branches and still miss, and where a model gets it right often enough to be worth the cost of checking. The cost is real: models are slower, cost money per call, produce different answers to similar inputs, and are wrong with confidence some percentage of the time. Every one of those has to be designed around, which is why we test AI the way we do.
The combination is usually the answer
Most good automations use both, in a specific arrangement: the model handles the messy edge, and rules handle everything after it.
Take intake. A model reads the incoming document and extracts the fields into a defined structure. From there, rules take over: validate the fields, reject what is malformed, route by amount, apply the pricing table, post to the system of record, notify the right person. The model did the one thing only a model can do. The rules did the rest, deterministically, cheaply, and in a way that can be tested. If the model is wrong, the rules catch the shape of it, and a person sees the exception.
That arrangement also keeps the model’s mistakes small. It is never asked to decide what to do, only to read. The deciding is code you can trust.
How we decide
Four questions, in order, for any step in a workflow:
- Can the decision be written down completely? If yes, it is a rule. Stop here.
- Is the input structured? Data from a system, a form, a database: rule. Free text, documents, images, speech: probably a model.
- What does a wrong answer cost? The higher the cost, the more the model’s output needs rules around it and a person behind it.
- How often does it run? A thousand times a day on a model adds up. The same volume on a rule is nothing.
The answers often turn a request for “an AI to handle our scheduling” into a rule for the scheduling and a model for reading the requests that come in by email. That is not a smaller win. It is the same win, at a fraction of the cost and risk.
Why this matters to an owner
Two reasons. The first is money: a rule-based automation costs less to build and nothing to run, so the payback is faster and the case is easier. The second is trust. Your team will adopt a system they can predict. An automation that does the same thing every time, and hands the unpredictable part to a person, is one they will stop watching and start relying on. That is the goal, and it is reached more often by a good rule than by a clever model.
If you are wondering which your workflows need, the honest answer is that we will not know until we look at them, and neither will anyone else. What we can promise is that we will not sell you a model where a rule would do.