Short answer: use a rule when the decision is explicit and stable, such as an amount above a fixed threshold, a required field, or a fixed calculation. Reach for AI when the input varies in form or language and has to be interpreted before a decision can be made, such as reading a free-text message or a scanned document. Most real workflows end up needing both: a rule for the parts that are fixed, and AI for the parts that vary.
What actually counts as a simple rule?
A rule is a condition you could write down as one sentence and everyone would agree on it in advance: if the invoice total is over a set amount, route it for approval. A rule does not require the system to interpret meaning. It compares a value against a boundary, checks whether a required field was filled in, or applies a fixed calculation. Rules are also the easiest thing to test, because you can give the system a set of known inputs and confirm the same output every time.
Default to a rule wherever one is available. It behaves the same way on the thousandth run as it did on the first, it needs no model to operate, and a person reading the rule can predict the outcome without running it. If a task can be described completely as a set of conditions, it usually should be built that way.
When does a task actually need AI?
AI becomes useful once the input stops arriving in a fixed shape. A support inbox receives messages of different lengths, tones and structure. A batch of scanned documents will have the same fields sitting in different places. A folder of product photos will vary in lighting and angle from one to the next. In each of these cases, a useful output depends on interpreting what the input actually contains, not on matching it against one expected pattern.
The tell is variation paired with meaning: the system has to understand what something is about, not only whether a field is present. Summarising the concerns raised across a set of varied customer messages is a good example of this. Checking whether a required field was left blank is not, no matter how the request happens to be phrased.
How do you tell the two apart in five minutes?
- Write down three real examples of the input. Use actual messages or documents, not a hypothetical one you invented for the exercise.
- For each example, write the output you actually want to see.
- Ask whether a fixed condition could produce that output correctly for all three examples.
- If yes, write the rule and test it against a fourth example you have not looked at yet.
- If no, note exactly what has to be interpreted, and treat only that part as the AI task. Keep the surrounding steps, such as routing, filing or notifying, as ordinary rules.
- Decide who reviews the output and what an unacceptable mistake looks like before anything runs unattended.
This exercise usually takes a few minutes, and it often shows that a task people describe as needing AI is mostly a rule with one interpretive step in the middle.
What does a mixed workflow look like in practice?
Most working automations combine both approaches rather than choosing one. An incoming enquiry might first be classified by an AI step to establish what it is about, then handled entirely by rules: route it to the right queue, apply a service level, check for a required attachment. The parts that still need judgment are handed to a person. Keeping the rule-based and AI-based parts of a workflow distinct makes the whole thing easier to test, since the rules can be checked deterministically while the AI step is evaluated separately against a set of example inputs.
| Signal in the task | Better fit |
|---|---|
| Fixed threshold or required field | A rule |
| Same input shape every time | A rule |
| Free text, images or documents that vary | AI, with review |
| A decision that changes an account, money or contract terms | Either, but only with human approval before the action |
| A wrong answer would be costly or hard to reverse | Add human review regardless of which approach you chose |
When this is the wrong choice
Neither approach is correct by default, and treating this as a one-time decision is itself a mistake. A rule is the wrong choice when the input genuinely varies and a fixed condition would quietly mishandle the uncommon cases you did not think to test. AI is the wrong choice when the decision is high stakes and could be handled just as reliably by an explicit rule, since that adds cost and uncertainty without a real benefit. AI is also the wrong choice, at least at first, when there is no way to review its output before it takes an action. If you cannot describe what an unacceptable mistake would look like for a task, that is a sign to pause and define one before automating anything at all, rule-based or not.
How we approach it at Ribhu Labs
We begin every automation conversation by mapping the actual task rather than starting from a tool. Where the work turns out to be a set of explicit conditions, we say so plainly and build the rule; where it needs interpretation, we scope the AI step narrowly and put a review point around it. You can read more about this on the AI & automation page, try a short version of this exact decision yourself in the decision-path study in the Lab, which is an illustrative browser demonstration rather than a connected system, and work through the AI foundations lesson for a short, practical introduction to the same idea.