Most of the work you want to automate does not need a model

The brief usually arrives already decided. Somebody has written "AI-powered exception handling" on a slide, a budget line exists against it, and the question put to the engineering side is which provider to use. The polite response is to answer the question. The useful one is to ask what happens today, step by step, and get every step written down before anybody opens a provider console.

Do that with a typical exception workflow and you tend to get something like this. A delivery scan fails to arrive inside a time window. A rule notices. A queue entry is created. A person opens the entry, reads a short free-text note from the driver, chooses one of five reasons from a list. The system writes the reason back against the consignment, updates a status, and sends a templated message to the customer. Six steps. Five of them are conditions, lookups and writes that a relational database and a few hundred lines of ordinary code have handled reliably for decades. One of them, reading the note, is genuinely open.

That one step may well deserve a model. The other five will be worse with one. Slower, more expensive per run, harder to test, and much harder to explain to somebody who wants to know why a particular customer received a particular message on a particular Tuesday. The exercise worth doing before the provider decision is drawing that line in writing, decision by decision.

Three conditions, and all three have to hold

• The input is genuinely open You cannot enumerate the shapes it arrives in. Free text written by a human under time pressure, a scanned document from a supplier who changes their template whenever they feel like it, a photograph of a damaged pallet. If you can write down the fields, the input is not open. It is a form you have not built yet.
• The rules cannot be written down Not that the rules are tedious to write down. Ask the two people who actually do the work to state the rule out loud. If they agree, and it fits on a page, you have a specification rather than a judgement call. If they disagree, and the disagreement is about meaning rather than about a field nobody captured, that is the honest signal.
• A wrong answer is survivable Survivable means there is a cheap correction path. A human checks it before anything moves, the cost of an error is bounded, or the output is a suggestion rather than an action. If a wrong answer pays an invoice, files a statutory return, or releases a batch, a model can still draft the answer, but something deterministic has to stand between the draft and the consequence.

Two out of three is the score that causes trouble. Open input with unwriteable rules and an unsurvivable outcome is not a reason to skip the model, it is a reason to put review in front of it. Writeable rules with an open-looking input is usually a data capture problem wearing a costume, and the fix is a better form upstream rather than a classifier downstream.

Take the workflow apart before you take the decision

What ordinary code is still better at

This is not nostalgia. There are specific properties you give up when a decision moves from a function to a prompt, and for these categories the properties matter more than the flexibility.

• Validation Required fields, formats, ranges, referential integrity. A constraint in the database is checked on every write forever, costs nothing, and cannot be talked out of its position.
• Routing and thresholds If the value is above a limit, or the customer sits in a tier, or the age of the record crosses a number of days. These are the rules a business changes twice a year and needs to change in one place.
• Lookups and joins Resolving a code to a name, a name to an account, an account to an owner. A model asked to remember a mapping is an expensive and lossy version of a table.
• Arithmetic and money Totals, tax, proration, rounding rules that somebody argued about in a meeting. Deterministic, testable, and auditable to the line.
• Idempotency and retries Running the same job twice must not send the message twice. This is control flow, and control flow belongs in code regardless of how clever the steps inside it are.

Nobody has been paged at two in the morning because a CASE statement quietly started behaving differently.

The argument for boring components

Where a model genuinely earns its place

Back to the driver's note. It arrives in three languages, contains abbreviations invented on the depot floor, and carries the one piece of information the structured fields do not: what actually happened. Reading that reliably is not a rules problem. Neither is pulling line items off a supplier invoice whose layout changes without notice, nor classifying a support message into a long tail of categories where the bottom forty each account for a handful of cases a month, nor drafting the paragraph a human will read, edit and send.

The pattern that holds up in production is narrow. The model does one job, over one input, and returns a typed structure that gets validated like anything else arriving from outside the system. Confidence below a line, or a field that fails validation, routes to a person. The code around it decides what happens next. Used that way, a model is a component rather than an architecture, and it can be swapped, versioned and switched off without the workflow collapsing.

The bill for putting a model where a rule would do

You pay in four places. Cost and latency per call, on a step that used to be free and instant. Nondeterminism, which turns a regression test into a probabilistic one. Version drift, where a provider update changes behaviour on a step nobody thought of as risky because it was only checking a threshold. And explainability, which is the one that hurts in the room that matters. When an auditor asks why this particular claim was routed for manual review, a rule answers with a line number and a value. A prompt answers with a paragraph about likelihood, and the conversation gets longer every time.

Where this argument is wrong

It is wrong when the rules exist but nobody will own them. A rules engine that has grown to several hundred entries, each covering a fraction of a percent of volume, maintained by no one and understood by a person who left, is not more explainable than a model. It only looks that way on the architecture diagram. It is also wrong when the organisation genuinely cannot agree the rule, and waiting for agreement means the work stays manual for another year. A narrow model with a human check is a defensible way to ship while that argument is still running, provided you write down that the argument is the real blocker. We have built deterministic components that should have been models, and the giveaway was always the same: a rule set that changed every fortnight and never converged.

Keep the drawing. The line between the two moves as models get cheaper, as your rule set gets longer, and as the error path gets better instrumented. Six months from now somebody will want to revisit a step, and the useful thing to have on hand is not the decision but the reasoning: which of the three conditions held then, and which one has changed since.