Non-deterministic models are a fact. Non-deterministic systems are a decision.
The most successful AI framework company defines its own field as a problem without an end. You should not accept the definition.
LangChain, announcing its Series B in October 2025, described the work the company sells tooling for:
"the iterative process of refining non-deterministic LLM systems into reliable experiences"
Read the sentence as an engineer. The system is non-deterministic, and the job is to keep refining the system toward reliability. No finish line appears in the sentence. The product is the treadmill.
I do not dispute the first half. A language model is non-deterministic. Even with a fixed seed and an identical request, GPU arithmetic does not promise identical output twice. Anyone telling you otherwise is selling you something.
I dispute the conclusion everybody draws from the first half: since the model is non-deterministic, the whole system must be. The conclusion does not follow. You choose where determinism lives.
Two of the largest companies in the industry already made this choice, for actions. AWS writes about its agent policy layer:
"consistent, deterministic enforcement that remains reliable regardless of how the agent is implemented."
Apple, in a WWDC26 session on securing agentic features in apps, told developers where to start:
"we should try to focus on deterministic mitigations as a baseline because their security guarantees are easier to audit and reason about."
Easier to audit and reason about. Keep the phrase. A probabilistic check gives you a probability. A deterministic check gives you a rule you read, test and argue with.
Both companies apply the principle to what a model does. Neither applies the principle to what a model claims. The answer at the end of a run still gets judged, if anyone judges the answer at all, by another probabilistic system.
Merlin moves the line. The model stays non-deterministic. The model plans, reads, writes and proposes an answer, and two runs of the same request take different paths. After the proposal, deterministic rules get the last word. A model still gives an opinion on the answer, and rules run before and after the opinion and override the opinion. A rule counts open tasks. A rule checks whether a cited line exists in a file the run read. A rule compares the bytes Merlin verified with the bytes Merlin committed. Each rule gives the same verdict every time on the same record, and the rules carry tests pinning those verdicts.
The result is a system whose path varies and whose standard does not. You will not get the same run twice. You will get the same refusal twice, for the same reason, on the same evidence.
The objection I hear most: deterministic rules are rigid, and rigid rules block good work. Sometimes they do, and we publish those cases in this series too. A rigid rule blocking good work shows up in a log with a name and a line number, and you fix the rule. A probabilistic judge waving through bad work shows up nowhere. I will take the failure I see over the failure I never find.
Non-deterministic models are a fact. Non-deterministic systems are a decision. You get to make the decision differently.