Deterministic Is Still King

The AI everyone’s bolting onto everything is a probability engine. Most of what your business runs on needs the same answer every time. Here’s how to tell which is which before it costs you.

AI is a probability engine. Most of your business runs on certainty.

The email comes down from the board: we need an AI strategy by the end of the quarter. By the end of the month, a team is wiring a language model into a process a spreadsheet has run correctly for nine years. The spreadsheet gave the same answer every time. The model is right most of the time, and nobody can tell you which times.

This is the screw, and the new hammer everyone bought.

There’s something worth understanding about a large language model before you put one in charge of anything. It doesn’t know things. It predicts the next most likely word, one after another, against a wall of probabilities baked in during training. Ask it the same question twice and you can get two different answers. Nobody is going to patch that out. It’s the machine doing the one thing it was built to do.

For a lot of work, that’s a gift. If you want forty subject lines for a campaign, variation is the point. If you want a rough draft of a memo, a plausible guess you then sharpen beats a blank page every time. Language is fuzzy, and a fuzzy tool fits it like a glove.

Most of what a business runs on isn’t fuzzy. Payroll isn’t fuzzy. A GST calculation isn’t fuzzy. Whether a customer qualifies for a refund under a written policy isn’t fuzzy. Each of these has one correct answer, and the same inputs should produce it every single time. That’s determinism. Same input, same output, forever, and you can prove it.

Deterministic systems have run the world for decades, without anyone calling them clever. A formula in a spreadsheet. A database query. An if-then rule. A state machine that moves an order from “placed” to “picked” to “shipped” and never skips a step. None of it makes a keynote. All of it is correct, the same way, every time, and when it breaks you can find out exactly why and fix it.

Put two jobs side by side. A model writing you a birthday message is brilliant, and the variation is half the charm. A model deciding whether an invoice gets paid is a problem waiting to happen, because “mostly pays the right invoices” isn’t a finance function, it’s a liability with a slow fuse. The technology didn’t change between those two sentences. The nature of the work did, and that’s the only thing that should decide which tool you reach for.

Here’s the move that’s costing people money. They look at that boring, reliable backbone and ask how to put AI into it. Wrong question. The question is which parts of the work need judgment, and which parts just need to be right.

Sort your work into those two buckets and most of the argument answers itself.

The hype taught people to mistake variance for intelligence.

I understand how we got here. The demos are genuinely stunning. You type a sentence and a paragraph comes back that reads like a sharp colleague wrote it. The first few times, it feels like magic. It feels like the thing in front of you understands what you meant.

It doesn’t understand. It’s extremely good at producing text that looks like understanding. The whole problem lives in the gap between those two sentences, and that gap is where companies are losing money right now.

Here’s the trap. When a tool does something brilliant often enough, you start crediting it with brilliance even on the runs where it’s confidently wrong. A calculator that’s right 95% of the time is a broken calculator. You can’t tell the right answers from the wrong ones without checking each one, and once you’re checking every answer you’ve saved yourself nothing.

The confident tone is the real danger. A deterministic system that fails usually fails loudly: an error, a blank, a number that’s obviously off. A language model that fails hands you a wrong answer in exactly the same calm, fluent register it uses for a right one. There’s no tremor in its voice when it’s making things up. That’s what makes it dangerous in the places that have to be right. It never sounds unsure.

Then there’s the pressure from above. “What’s our AI strategy” is now a question every board asks, and “we’ve added AI” is a thing every company wants to say in its next update. So a model gets bolted onto a process for the announcement, not because the process was failing. The work was already getting done. Now it gets done less reliably, costs money per run, takes a beat longer, and someone’s quarter is spent babysitting it.

I’ve watched a team take a workflow that ran on a few hundred lines of rules (fast, free, correct) and replace it with a call to a model that costs money every time, adds a second of latency, and now and then returns something nobody asked for. The reason was always the same. We wanted to be using AI.

That’s a hammer driving a screw. The hammer is a marvel. It’s the finest hammer anyone has ever forged. The screw still strips, and the wall still cracks.

The tell: you’re debugging answers that used to be guaranteed.

Here’s how you know you’ve put a model where a rule belonged. Look at the scaffolding you’ve had to build around it to make it behave.

You write guardrails to stop it saying things it shouldn’t. You build an eval suite to measure how often it’s wrong, because “how often is it wrong” is suddenly a live question. You spend afternoons tuning the prompt (adding “do not invent policies” and “only use the information provided”) because it keeps inventing policies. You drop the temperature to zero to make it less random, which is you begging a probabilistic tool to please act deterministic for once.

Stack all of that up and look at what you’ve built. Weeks of engineering and a recurring bill, spent dragging a probability engine most of the way back toward the certainty a lookup table handed you for free. You rebuilt a calculator. You rebuilt it worse, and now you pay rent on it.

Every layer of that scaffolding is a tell. Guardrails, evals, retries, “please don’t hallucinate” stapled into the prompt — that’s the toll for forcing the wrong tool through a job the right tool already did. None of it needs to exist when the answer comes from a rule.

A rule doesn’t hallucinate. A rule doesn’t need a test harness to tell you how often it lies, because it doesn’t lie. A rule is wrong only when you wrote it wrong, and then it’s wrong the same way every time, which means you can find it, see it, and fix it before lunch. Now try debugging “the model gave a strange answer to one customer last Tuesday and we can’t reproduce it.” You can’t reproduce it because reproducibility was the thing you traded away when you swapped the rule for a guess.

Even the labs route the important work to deterministic tools.

Ask the most advanced model on earth to multiply two long numbers and it might get it wrong, because exact arithmetic isn’t what next-token prediction is built for. The model reaches for the most plausible-looking answer, and a plausible-looking number and the correct number are different things that happen to look alike.

The people who build these models know this better than anyone. So look at what they did about it. They didn’t train the maths in harder and hope. They gave the model a calculator. When you ask a frontier system to do real arithmetic now, it doesn’t do the sum in its head. It writes a small piece of code, runs that code in a plain deterministic environment, and reads the answer back. The industry calls this “tool use”, and it’s the standard way serious AI systems get anything exact done. The model handles the language. A deterministic tool handles the truth.

Sit with that for a second. The most sophisticated AI companies in the world, staffed by the people who understand these systems more deeply than anyone alive, will not trust the model to add two numbers. They route it to deterministic code, every single time, because the answer has to be right and they know how it arrives at one.

So when someone wants to hand a language model your pricing logic, your eligibility rules, your compliance checks (the things that have to be right), the builders of the technology have already answered the question for you. They won’t let it do the arithmetic. The model’s job is to work out what needs calculating. The calculation itself belongs to a rule.

Determinism isn’t the boring option. It’s the one you can defend.

Make it concrete, because the cost stops being abstract the second something goes wrong.

In 2024, Air Canada lost a case at a Canadian tribunal over its chatbot. The bot had told a grieving passenger he could apply for a bereavement discount after booking. The airline’s real policy said no such thing. When the passenger took it to the tribunal, Air Canada argued (and this is real) that the chatbot was a separate entity responsible for its own statements. The tribunal didn’t wear it. The airline was held to what its bot had promised, and it paid.

The fare rule the bot fumbled was written down the entire time. A lookup against the real policy would have returned the correct answer to that passenger every time, for nothing close to the cost of the case or the press it earned. Air Canada pointed a probability engine at a question with one written, knowable answer. The engine produced a different answer in a confident voice, and the company wore the result.

That’s the cost that never shows up in the demo. When a deterministic system gives an answer, you can put your finger on the rule that produced it. When a model gives an answer, the best account you can offer afterwards is that it seemed likely at the time.

This is where it bites hardest in regulated work — health and safety, financial services, aged care, anything where a decision has to survive an audit. You can’t put “the model felt like it” in front of a regulator. You can’t put it in front of a board, an auditor, or a coroner. They will ask why the system did what it did, and “we’re not entirely sure, it’s probabilistic” doesn’t close the conversation. It opens a far worse one.

Deterministic systems are explainable by construction. You can read the rule. You can test it. You can run the same input through it ten thousand times and get the same output ten thousand times, which is what lets you prove it does what you say it does. That reproducibility is the thing that lets you stand behind your own process when someone with authority leans in and asks you to.

AI earns its place at the fuzzy edges.

None of this is a case against AI. It’s a case for aiming it at what it’s brilliant at and keeping it away from what it’s bad at.

There’s a whole class of work where a language model is the best tool anyone has ever had. Reading three thousand support tickets and telling you the four themes that keep surfacing. Turning a rambling call transcript into a clean summary. Drafting a first version of something a human will sharpen. Pulling structure out of unstructured text — the name, the date, the amount buried in an email that could have been phrased ten thousand ways no rule could anticipate. Sitting with genuine ambiguity, where there’s no single right answer and a sensible read is the win.

That’s the fuzzy edge. The work is language-shaped, the inputs are messy, and a little variance costs you nothing because a person is reading the output anyway. Reach for the model here and it earns every cent.

Notice what those jobs have in common. There was never one correct output to begin with. Two good analysts would summarise the same call slightly differently, and both versions would be fine. Once the bar is “a sensible, useful read” instead of “the one right answer”, variance stops being a flaw and becomes range. That gives you the test in its plainest form. If two competent people could reasonably hand you different outputs and both be right, a model is at home. If they couldn’t, you’re back in rule territory, and the new tool is the wrong one again.

The dividing line is simpler than the hype makes it sound. If the task is language and judgment, and a good-enough answer that a human checks is the goal, the model fits. If the task has one correct answer that has to come back identical every time, and being wrong carries a cost you’d have to explain to someone, you want a rule. Most real systems are a blend: a model at the fuzzy front door, deterministic logic doing the work behind it that has to be right. The whole skill is knowing which part is which, and refusing to let excitement about the front door talk you into gutting the engine room.

One question to ask before you bolt the model in.

Take your list of “where we’re going to use AI” — and if you’re a business of any size in 2026, there’s a list. Go down it one line at a time and put a single question to each item:

Does the same input need to produce the same answer every time?

If the answer is yes, you’re looking at a deterministic problem, and a model is the wrong tool no matter how good the demo felt. You want a rule, a calculation, a lookup, a workflow. Boring. Cheap. Correct. The version you can still explain in a year.

If the answer is no (the work is genuinely fuzzy, the inputs are messy, and a sensible-enough answer with a human nearby is the win) then reach for the model, and reach hard. That’s its home ground, and it’ll outrun anything you had before.

My bet is that most of the list fails the test. That’s the finding worth having. A surprising share of what gets sold as “an AI use case” is a deterministic problem wearing a probabilistic costume, and the plain rule that would solve it properly is cheaper, faster, and still standing when someone asks you to account for it.

The new tool is extraordinary. Point it at the screws and it’ll let you down in a confident voice and hand you the bill. Find the work that has to be right, and keep it deterministic. Then let the model loose on everything that was always going to be a guess.