Say "determinism" in a meeting about AI and it can sound like nostalgia, a wish to go back to rules engines and flowcharts.
It isn't. The value of today's AI models comes precisely from the fact that they aren't rigid. They handle ambiguity, messy language and situations no one wrote a rule for. Nobody sensible wants to give that up.
But the model and the system around it are two different things. The model can be probabilistic. The business process it sits inside usually shouldn't be.
Determinism isn't anti-AI. It's what lets people trust AI with work that matters.
Where variation is value, and where it is risk
Some work benefits from variation. Drafting a summary, suggesting options, searching for relevant documents, rephrasing a letter for a different reader: a slightly different result each time is fine, and often useful.
Other work is harmed by it. Calculating an amount owed. Deciding whether an application meets a threshold. Applying a policy. Writing to a system of record. Moving money. Here, "a slightly different answer each time" is not a feature. It's a defect.
Most agent workflows contain both kinds of work, often in the same few steps. The design mistake is to hand all of it to the model because the model can do all of it.
A useful test: would you accept a spreadsheet whose totals changed each time you opened it? Nobody would. Yet it's common to see agent pipelines where the arithmetic, the rule and the final decision are all produced by a language model, and could come out differently tomorrow.
Bounded behavior
The goal isn't to make the model deterministic. It's to make the behavior of the system bounded.
A bounded system has fixed edges, even if what happens inside them varies. Which data the agent may use. Which steps always happen, and in what order. Which checks must pass before anything changes. When it has to stop and ask a person. What it is never allowed to do, however it is prompted.
Inside those edges, the model can be as flexible as the task needs. The edges themselves don't move unless someone deliberately changes them, and that change is reviewed and recorded like any other.
That's the difference between an agent you've approved and an agent you've merely observed.
Repeatability is what makes trust possible
The strongest reason for determinism isn't technical. It's about what happens when someone asks a question.
When a customer, an auditor or a regulator asks "why did this happen?", you need to be able to reproduce what the system did. If you run it again and get a different answer, you can't investigate the original decision. You can't tell whether a fix worked, because you can't reliably recreate the problem. You can't show that the system approved last month is the one running today.
Repeatability underpins almost every control organizations rely on:
- Testing assumes the same input produces the same result.
- Change management assumes you can compare behavior before and after a change.
- Incident review assumes you can replay what happened.
- Audit assumes someone independent can check the work and reach the same conclusion.
Take repeatability away, and each of these becomes an exercise in interpretation.
Deterministic where it must be
The principle we design around is simple to state:
Deterministic where it must be. Probabilistic where it helps. Explicit about which is which.
Let deterministic logic do what it does well: calculations, rules, lookups, thresholds, the order of steps. Let models do what they do well: language, ambiguity, judgment on messy input. Make the boundary between the two visible, and record which part of the system produced which part of the result.
This isn't a compromise between AI and control. It's what allows an organization to give AI more responsibility, because the parts that must never vary, don't.
In the next article: the cost of silent drift, and why the most dangerous change is often the one nobody made.