A rule or an AI agent? How to tell what your process actually needs
Every tool now markets itself as an "AI agent", and companies ask about agents before asking what they want to improve. Below is a test that settles in thirty seconds whether a given step needs a language model or whether a plain rule will do.
The short answer
A rule is enough wherever two people doing the same step would make the same decision. A language model is needed only where content has to be read, understood and judged — content that looks different every time.
In a well-built process this is usually eighty per cent rules and twenty per cent model — in specific steps, not across the whole process.
The costliest mistake in this area is building an AI agent where a single "if-then" would have done. The second costliest is the reverse.
Why this is even a question
A year ago nobody would have asked it. Automation meant rules, and there was no alternative.
Today every tool markets itself as an "AI agent", and companies ask about agents before asking what they actually want to improve. The result is two kinds of failed implementation that cost in opposite directions.
An agent where a rule would do. A language model classifies enquiries that one field on the form could have split. It works, but it costs every month, occasionally gets it wrong, and it is hard to check why it decided what it did.
A rule where understanding is needed. An automation sorts emails by keywords. A client writes "my invoice isn't working", the rule looks for the word "complaint", finds nothing, and the enquiry goes to the wrong person. Formally the process works; in practice somebody still has to review everything by hand.
Both mistakes have the same root: choosing the technology before understanding the step.
A rule — when the answer is always the same
An enquiry from the form goes into the spreadsheet. An invoice changes status once paid. The client gets a confirmation. A task lands on the list with a due date. There is nothing to interpret — just a condition and an action.
A rule has four advantages a model cannot match:
- It is cheaper. You do not pay per call. Running cost is in practice the cost of the platform it runs on.
- It is faster. It executes in a fraction of a second, with no waiting for an external model to respond.
- It is predictable. The same input always gives the same result. You only need to test it once.
- It never makes a new kind of mistake. If it fails, it always fails the same way — and that is easy to find.
That last point is underrated. A rule's error repeats, so it can be spotted and fixed. A model's error can be one-off and hard to reproduce.
A model — when the content has to be understood
An enquiry needs a category, though nobody said which one it belongs to. An order number, a deadline and the actual request need pulling out of a long email. A question needs answering that is not in any ready-made FAQ.
A rule is not enough here, because the input looks different every time. You cannot foresee every phrasing, and a keyword list grows forever while still letting through cases nobody thought of.
A language model handles this well, because it does not look for words — it understands meaning. "My invoice isn't working", "the invoice won't send" and "the client says they never got the document" all end up in the same place.
A test that settles it in thirty seconds
Take one step of your process and ask a single question: would two people doing this step make the same decision?
If yes — it is a rule. Write it down and automate it. No model is needed here, and adding one only raises the cost.
If not, because the content has to be read, understood and judged — that is where a model belongs.
The test works because it exposes the source of variation. When two people decide the same way, the decision follows from a condition you can write down. When they decide differently, the decision needs interpretation — and interpretation is exactly what a model does better than a rule.
Sometimes two people decide differently not because the step needs interpretation, but because nobody ever set a rule. Then what you need is a decision, not a model. Settle the rule first — reach for a model only if it turns out impossible to write down.
What this looks like in one process
Take handling enquiries from a form, step by step.
| Step | Same decision? | Solution |
|---|---|---|
| Filtering spam with a hidden field | yes | rule |
| Saving the enquiry to a spreadsheet | yes | rule |
| Notifying the team | yes | rule |
| Choosing the language version of the reply | yes | rule |
| Creating a dated task | yes | rule |
| Assigning a topic the client did not state | no | model |
| Tailoring the reply to the description | no | model |
Five steps out of seven are rules. That is what our own enquiry handling looks like — it currently runs on rules alone, and the model layer is deliberately postponed until the rule-based version has processed enough real enquiries to show what a model would improve.
We described that process separately, with the payback calculation: how we automated our own enquiry handling.
When a model makes no sense, even if it fits
There are three situations where a model adds risk rather than value — even if the step formally needs interpretation.
When a mistake is costly and irreversible. Sending a transfer, approving a contract, deleting data. Even a rare error is unacceptable here. Better that a person decides, with the automation preparing everything for that decision.
When the answer has to be identical every time. Legal wording, price information, terms and conditions. A model phrases its answer slightly differently each time. Where exact wording matters, that is a flaw, not a feature.
When the company has no written-down knowledge. A model answers from the context you give it. If procedures, prices and rules exist only in people's heads, the model has nothing to draw on — and it will guess, sounding confident as it does.
What it costs
The distinction translates directly into price.
Rule-based steps fit within a standard implementation and generate practically no running costs beyond the automation platform.
Steps that need a model add its running cost — at typical small-business volumes that is PLN 50–300 a month, depending on the number of calls and the length of the content processed.
These are not large sums, but they are worth knowing before you decide. If a step can be handled by a rule, adding a model means paying every month for something that could run at no extra cost.
One obligation worth knowing about
When a language model talks to a client or prepares content the client receives, a disclosure obligation applies. Since 2 August 2026 the recipient has to know they are dealing with artificial intelligence — this follows from Article 50 of the EU AI Act.
It does not apply to rules. An automatic confirmation sent by a rule is plain automation, with no additional requirements. We covered the details in the piece on the new AI disclosure obligation.
Why we do not sell "AI agents"
This follows directly from everything above. An agent is not the goal — it is one way of carrying out a step in a process. The client is not buying a language model. They are buying the fact that enquiries reach the right person and the reply arrives in a minute rather than in two days.
That is why we start with the process, not the technology. First we break it into steps, apply the two-person test to each, and only then is it clear where a rule is enough and where a model genuinely changes something. Sometimes the answer is that no model is needed at all.
Frequently asked questions
No. They are two different tools for two different jobs. A rule carries out a decision someone has already made. A model makes a decision that cannot be written down in advance. Replacing a rule with a model does not modernise the process — it just makes it more expensive and less predictable.
Break the process into steps and ask the two-person question at each one. If the decision is unambiguous at every step, no model is needed. That happens more often than tool advertising suggests.
Yes — rarely, but it does, and sometimes in ways that are hard to predict. That is why we do not use one where a mistake is costly and irreversible. In such steps a model can prepare a proposal, but the decision stays with a person.
That is the best order. The rule-based version shows which steps actually cause trouble on real data. A model added afterwards lands exactly where it is needed.
If it is a rule — no. If a model talks to the client or prepares content the client receives — yes, since 2 August 2026 Article 50 of the AI Act requires it.
The running cost is usually PLN 50–300 a month at typical small-business volumes. On top of that comes a one-off cost of implementing the step, which depends on how complex the interpretation is and how much context the model needs.
He spent five years building operations at WebWave: from creating a support department from scratch to the role of Head of Operations and leading the integration after the company was acquired. While putting those processes in order he noticed how much time is taken up by work that develops nobody — and that the tools capable of taking it over already exist. A graduate in corporate finance from the SGH Warsaw School of Economics.
LinkedIn profile →