Why rules still win some jobs
Traditional software does exactly what it was told. Its logic is written down, so a developer can point at the line that produced a result, and a test can show it will produce the same result tomorrow. That quality is dull, and it is exactly what you want from the part of the business that counts money, tracks stock or decides who may see what.
AI agents trade some of that certainty for flexibility. A model can phrase things differently or choose a different route on a different day, which is helpful when reading a customer's email and risky when calculating a tax amount. Knowing which kind of job you have is most of the decision.
Five tests for when traditional software should decide
Run each job through five tests. The repeat test: must identical input always give identical output? The replay test: can you reconstruct exactly why it did what it did? The money test: does it move funds or change an official record? The rule test: does a law, contract or policy define the exact outcome? The volume test: does it run so often that cost per action matters?
One clear yes on the first four is usually enough to keep traditional software in charge of the decision. A yes on the fifth is an economic argument for rules rather than a model call every time. An agent can still prepare the input or draft the explanation, but the decision itself comes from logic you can inspect.
- Repeat: identical input must give identical output
- Replay: you can explain and reproduce each result
- Money: funds or official records are affected
- Rule: a law, contract or policy fixes the answer
- Volume: the job runs often enough that cost per action adds up
Jobs where rules should stay in charge
Invoicing and tax calculations, payroll, stock counts, appointment availability, user permissions, order status and compliance reports are all examples. Each has a correct answer that can be checked against a rule. If an agent gets one wrong now and then, that is still a wrong invoice or a double-booked client, and finding the pattern behind it is harder than debugging code.
Reliability also matters outside business hours. A scheduled report must run at the same time and give the same numbers whether or not anyone is watching. Rules and databases handle that without ongoing prompts, retries or usage fees, and when they do fail, the failure is usually easy to reproduce and fix.
The cost and speed gap
Every decision an agent makes may involve a call to a language model. That takes longer than running a rule, and most services bill by usage, so cost grows with volume. A rule that checks a postal code or applies a discount costs very little and responds immediately, which matters for checkout pages, booking forms and anything your staff wait on.
Testing is simpler too. With rules you can write checks for every case that matters and run them after each change. With agents you test on realistic samples and keep watching afterward, because behaviour can shift as models and inputs change. Both need care, but one asks for far less of it.
How agents and rules can work together
None of this makes agents pointless. It tells you where to place them. An agent reads a messy supplier email and proposes the fields for an invoice. Traditional software validates those fields, applies the rules and records the result. The agent suggests and the rules decide. A person approves anything unusual, and the whole chain is logged.
This pattern also helps with governance. You can set the agent's permissions narrowly, keep sensitive records inside the system of record, and show an auditor which step was software and which was a model. If you are unsure which category a job falls into, an outside review of the process can save you from building the wrong thing.
Where the line may move
The boundary will shift as models become more consistent and as tools for checking their output improve. Some jobs now handled by rules may gain an AI layer, and some AI jobs may be tightened into rules once the pattern is understood. Revisit the five tests whenever a vendor, a regulation or your own volume changes, rather than treating today's answer as permanent.
- 01Models that behave more consistently on narrow tasks
- 02Better ways to test and monitor what an agent does
- 03Regulators and customers asking for clearer records of automated decisions
Questions & answers
When the job must give the same result every time, be explained step by step, handle money or official records, or run at high volume. In those cases rules are more predictable, cheaper per action and easier to test. Agents are a better fit for messy language and varied cases.
No. Agents rely on traditional software for records, calculations and the actions they carry out. Databases, business logic and permissions remain the foundation. What is changing is that agents are being added on top of them to handle reading, drafting and routing.
Yes. A model can misread a request, state something untrue or follow instructions hidden in a document. Rules fail too, but they fail in repeatable ways you can trace. That difference is why money, records and permissions belong in software that behaves identically each time.
Give it narrow permissions, let it propose rather than commit, and put traditional software between its output and your records. Log every action, require a person to approve anything that matters, and test with real cases first. Security and governance review belongs in the build, not after it.
