Deterministic before intelligent: where AI actually belongs

There's a reflex right now to answer every operational problem with "let's put an AI on it." It's understandable. The models are genuinely good, and the demos are genuinely impressive. But most of the work inside a business doesn't need intelligence. It needs to happen the same way every time.

Our rule is in the name of the principle: deterministic before intelligent. If a rule can decide something reliably, a rule should. AI is reserved for the genuine judgment calls, and there are far fewer of those than the hype suggests.

The one question

Before any step in a workflow gets an AI, it has to fail a single test:

Can a rule decide this correctly, every time, from structured data?

If the answer is yes, and it usually is, you don't want a model there. You want a rule. Routing an approval based on dollar amount, generating an invoice from a contract, syncing a status across systems, sending a reminder when a date passes: none of these are judgment. They're logic. Putting a probabilistic model in the middle of deterministic logic doesn't make it smarter. It makes it slower, more expensive, and occasionally wrong about things that have an exactly correct answer.

This isn't a contrarian take. It's the consensus among people who actually ship automation: stable, repeatable, structured-data processes belong in rules, and AI earns its keep on the messy edges. (Stonebranch frames the same split as deterministic vs. probabilistic.)

Three buckets, not one

When we map a process, every step lands in one of three buckets:

1. Deterministic core, the rules. The spine of the workflow. Validation, routing, calculation, record-keeping, notifications. This is most of the system, and it's deliberately boring. Same input, same output, forever. No model goes here.
2. The messy edge, structured AI. The narrow band where inputs are unstructured or the category is fuzzy: reading a contract or invoice, classifying a free-text email, triaging an exception. This is where a model genuinely outperforms a rule, and where it needs the most guardrails.
3. The real decision, a human. The high-stakes call at the end. The system prepares it; a person makes it.

The art isn't in the AI. It's in drawing the boundaries so each bucket holds exactly what belongs in it, and nothing creeps from bucket 1 into bucket 2 because it "felt like an AI problem."

A worked example

Take accounts-payable invoice processing. The reflex version is "an AI agent that handles invoices." The disciplined version splits it:

• Reading the invoice PDF is bucket 2. The layout is unstructured, every vendor's format differs. A model extracts the fields. (How we make that extraction trustworthy without trusting the model.)
• Validating the line items is bucket 1. Do the numbers add up? Does the PO exist? Is the vendor on file? These are rules. The model's output gets checked by them, not trusted.
• Routing for approval is bucket 1. Amount thresholds and an approval graph. Pure logic.
• Approving a $40,000 invoice from a new vendor is bucket 3. A person, with everything the system already gathered laid out in front of them.

One workflow, one AI step, wrapped in rules on both sides. The intelligence is a component, not the architecture.

The goal isn't to use AI. The goal is the result. AI is one way to get there, the right way for exactly one of those four steps.

Why rules-first wins

Putting rules first isn't nostalgia for the old way. It's the cheaper, more reliable, more auditable design:

• It's faster and cheaper to build. Deterministic logic is well-understood engineering, not a data-and-model project. You ship the spine in weeks.
• It fails predictably. When a rule is wrong, it's wrong the same way every time, and you fix it once. A model that's wrong is wrong in ways you have to discover.
• It's auditable by construction. A rule is its own explanation. (And the AI steps have to be made auditable on purpose.)
• It shrinks the AI surface. The less the model touches, the less there is to validate, monitor, and second-guess. Smaller blast radius, higher trust.

The order, again

This is the same lesson that shows up everywhere in our work: do it in the right order. Unify the systems, automate the deterministic handoffs, then add structured AI on the narrow slice that's left. Skip to the AI and you're back in the pilot that stalls.

So the next time someone says "let's put an AI on it," ask the cheaper question first: can a rule decide this? Most of the time, the honest answer is yes, and the system you get is the one that runs like clockwork.

That's the work we do. If you want a candid map of which parts of your process actually need AI and which just need engineering, the consultation is free. We'll tell you when the answer is "none."