An invoice is overdue, a required field is missing or an appointment falls outside opening hours. You normally do not need a language model for these decisions. You need reliable data and clearly defined rules.
Automation can be worthwhile without AI. A language model becomes interesting when content is worded in different ways and needs to be interpreted, summarised or put into a usable form. The subsequent decision can still follow fixed rules.
This separation helps with planning: which work is linguistically difficult? Which follows an unambiguous instruction? And which requires judgement or responsibility that should remain with a person?
Four tasks, four different tools
The following examples are a decision aid, not a description of measured customer projects.
| Task | Natural solution | Why |
|---|---|---|
| Send a reminder when a confirmed appointment is two days away | Time rule and notification | The condition and output are clear |
| Check that the customer number and invoice amount are present | Form or data validation | The structure and required fields are defined |
| Sort differently worded emails by request type | Rules for clear cases, potentially AI for free text | The same intent can be expressed in very different ways |
| Make a goodwill decision in a disputed case | A responsible person supported by prepared facts | Context and consequences require an accountable decision |
Even language model providers recommend starting with the simplest suitable solution. Anthropic explains that more elaborate agents can add cost and latency, and that fixed workflows are often more suitable for well-defined tasks. This does not mean every task can be solved without AI; it supports making a deliberate choice. Source: Building effective agents.
A quick test for rules
Take a specific task and try writing it like this: “If these verifiable conditions hold, perform exactly this action. Otherwise …”
If a knowledgeable person can derive the same decision without interpretation, a rule-based solution is a good first candidate. Remember exceptions: missing data, duplicate events, public holidays, cancellations and changes after initial recording.
If the sentence fails because people write freely or documents have different structures, AI may help at that point. If it fails because your organisation does not know the rule itself, a business decision is needed first. A model does not replace an unresolved business requirement.
Where a language model has a useful role
Imagine an email: “We have moved. Please send everything to our new address from next month.” A rigid search for one keyword may miss different formulations. A model could extract the request type “address change” and the details mentioned.
That does not approve the change. The application must check which customer the message belongs to, whether the sender is authorised and whether the necessary details are complete. A proposed address must not become an authoritative customer record change without checking.
A fixed output format also solves only part of the problem. A schema can check required fields and data types, for example. It does not confirm that an address actually belongs to the correct customer. The JSON Schema documentation describes these structural checks; business correctness needs separate verification.
A useful combined approach
A practical workflow might look like this: unambiguous system messages are processed directly using rules. Free-text messages are prepared for classification. The application checks the result against permitted values and existing data. Incomplete or consequential cases go to a responsible person.
The model interprets language. It does not automatically receive permission to execute every action inferred from it. Permissions and required approvals belong in the application and connected systems. OWASP explicitly recommends limiting functions, permissions and autonomy in this way. Source: Excessive Agency.
This combined approach does not have to feel complicated to the customer. They want an understandable confirmation and to know whether their request is complete or still being reviewed. The internal choice of tools belongs in the conversation only when it is relevant to that purpose.
Account for all the work
If a language model is part of the solution, our example calculation for AI assistants helps you plan setup, operations and usage separately.
The cheapest model bill is not proof of cost-effective automation. Compare development, operations, maintenance, checks and error handling. With a small number of cases, regular checking can consume the potential time savings.
An explicitly fictional calculation shows the difference. Suppose a team handles 600 similar cases each month, taking three minutes each. The existing workload is 1,800 minutes, or 30 hours.
| Step in the example | Assumption | Monthly effort |
|---|---|---|
| Review automatically prepared cases | 480 cases at one minute each | 8 hours |
| Handle remaining cases manually | 120 cases at three minutes each | 6 hours |
| Monitor the workflow and maintain rules | Flat planning assumption | 2 hours |
| New total recurring effort | 8 + 6 + 2 hours | 16 hours |
| Calculated reduction from the previous workload | 30 − 16 hours | 14 hours |
This is not a measured saving or a performance promise. One-off implementation, training and additional costs are not included. If checking takes two minutes rather than one, the new monthly effort rises to 24 hours and the reduction falls to six hours. That is exactly why you need to measure review time during a pilot.
Which solution wins the comparison?
Where possible, test the same representative sample using a simple rule-based version and a version with AI. Do not compare only the number of automatically handled cases. Record incorrect classifications, necessary rework and the time until a substantively correct result is reached.
An AI version is worthwhile when a demonstrable benefit offsets the additional operational and review effort. A rule-based version is worthwhile when it reliably simplifies the relevant workflow. Sometimes the best first improvement is a required form field or an unambiguous document name.
Record your decision: which part is automated, which data is required, when a person takes over and who maintains the rules. This also makes later changes easier.
That is why our AI and automation services start with the workflow. A recurring task and its typical exceptions are enough for an initial assessment. Whether it needs a language model should be the result of the investigation.