Why deterministic AI decisions are a foundation for regulated systems

AI agents are no longer experimental assistants. They are now used in flows where decisions can move money, unlock assets, or change who can act in a system. In those settings, we are less interested in novelty and more interested in trust.

For a regulator, auditor, or customer, there are three practical questions:

1. Can we reproduce the same operational output from the same input?
2. Can we identify what changed when outputs changed?
3. Can we prove that a decision path met policy at the time it was executed?

The answer to all three is often no when teams rely only on a hosted LLM endpoint and assume temperature 0 means deterministic.

When a team says the model is non deterministic, they are usually describing a different problem: unpinned serving infrastructure. The model weights may be stable, but the execution environment around them is not. The same request can reach different hardware, different model build, or a changed scheduling path. That is why one input can return different answers on different days, and why one prompt can lead to different business outcomes.

In regulated and critical systems this is not just an engineering quirk. It is an auditability risk.

A simple failure mode, a real-world failure pattern

Imagine a treasury agent that checks and classifies a payment instruction from an API call. Two identical instructions arrive in a test replay and in production. If outputs differ, you now have ambiguity:

• The treasury team cannot prove which decision was based on policy and which was an execution artifact.
• A compliance officer cannot replay the incident and get one unambiguous trace.
• A post incident review becomes a manual reconstruction exercise across logs and third party evidence.

In many regulated domains, this violates basic expectations of controllability, even before formal legal review starts.

Why this is hard in hosted AI today

The AI stack is usually layered as follows: client gateway, scheduler, runtime, kernel library, model build, and GPU execution. Every layer can shift without warning.

The model alone is not the only control surface. The key controls are distributed across the stack, and they may be managed by different teams. That means teams that need determinism must either control all layers or verify externally whether the stack they use is stable at query time.

From a systems view, deterministic behavior requires a clear contract between these layers:

• fixed input bytes and tool schema,
• fixed sampling mode and seed strategy,
• fixed engine build and runtime version,
• fixed model release and fingerprint,
• fixed scheduler and batch policy, and
• fixed hardware class for the execution path.

When any layer is left open, byte identity cannot be promised.

Why this matters more in critical systems than in general chat

General chat tolerates variation because the business impact is low.

In contrast, regulated environments must reconcile two obligations at once: repeatable outcomes and transparent decision lineage. We need to provide evidence that is stable enough for review, even when a human needs to rerun the scenario months later.

These obligations are now explicit in many policy frameworks and sector standards. In high risk contexts, reproducibility is increasingly tied to quality systems, testability, and incident response discipline. The practical expectation is simple: if a decision is challenged, the organization should be able to recreate what happened.

This is also the center of our Agentic Determinism Index work. Instead of guessing which provider setup is stable, we measure it.

The state of the art is moving, but not yet universal

There is promising work in three areas:

1. Deterministic inference controls in model servers. Projects like vLLM and SGLang now expose modes aimed at stronger replay guarantees. They reduce drift, but often with throughput tradeoffs.
2. Structured output and schema validation. Teams use JSON mode, schema contracts, and post validators to keep outputs parseable. This helps reliability, but does not remove variability at token level.
3. Policy and evidence pipelines. New compliance tooling connects model decisions to policy checks, logs, signatures, and dispute artifacts. Those stacks assume that the AI output can be reproduced and explained, not merely plausible.

These threads are useful, and together they are more than ad hoc testing. The missing piece remains a shared public signal of which public stacks are replayable and under what precise conditions.

State of the art and what it tells us

• Open model and runtime reproducibility guidance. PyTorch reproducibility notes and model-serving guidance emphasize that bit identity is a stack level property.
• Deterministic inference modes. Public efforts in vLLM and SGLang expose deterministic flags and batch invariance modes for operators who prefer consistency over raw throughput.
• Model API policy documents. Major providers publish seed and reproducibility caveats, and those notes repeatedly warn that same model names do not guarantee same execution state over time.
• Formal risk standards. EU AI Act record keeping rules, NIST AI RMF, and ISO quality frameworks all converge on auditability and traceability obligations for high risk AI workflows.
• Operational evidence standards. New finance and compliance workflows are moving toward signed decision artifacts, replay logs, and policy gates because those controls are only meaningful when outputs can be reproduced.

Short reading list for the team:

• OpenAI, "How to make your completions reproducible with the new seed parameter," 2023, https://cookbook.openai.com/examples/reproducible_outputs_with_the_seed_parameter
• OpenAI API reference for the responses endpoint, https://platform.openai.com/docs/api-reference/responses/create
• Anthropic API reference, https://platform.claude.com/docs/api/messages
• PyTorch reproducibility notes, https://docs.pytorch.org/docs/stable/notes/randomness.html
• NIST AI Risk Management Framework, https://www.nist.gov/itl/ai-risk-management-framework
• Regulation (EU) 2024/1689 (AI Act), https://eur-lex.europa.eu/eli/reg/2024/1689
• SGLang, "Towards Deterministic Inference in SGLang and Reproducible RL Training," September 2025, https://lmsys.org/blog/2025-09-22-sglang-deterministic
• vLLM batch invariance documentation, https://docs.vllm.ai/en/stable/features/batch_invariance
• Thinking Machines Lab, "Defeating Nondeterminism in LLM Inference," September 2025, https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference
• Sclar et al., "Quantifying Language Models' Sensitivity to Spurious Features in Prompt Design," 2023, https://arxiv.org/abs/2310.11324

What we need from hosted providers

For regulated deployments, providers should state, not imply, what guarantees they can deliver:

• fingerprint and version clarity,
• replay mode behavior,
• supported deterministic settings,
• evidence fields suitable for traceability,
• transparent change announcements tied to stack updates.

Until those are standard, teams must verify for themselves.

This is where a simple measurement can be useful: a leaderboard style index that shows which provider and model combinations actually keep byte identity over repeated probes.

From policy language to engineering choice

The next article in this series is technical. Here is the practical takeaway:

If you run agents in regulated systems, ask four questions before launch:

1. Is replay possible from the same input?
2. Are we tracking exactly which serving tuple produced each output?
3. Do we have evidence artifacts for every automated path?
4. Can we detect and act on drift before business risk rises?

Only then are metrics and policy decisions on the same page.

You can read our technical explanation and open harness here: Agentic Determinism Index (ADI).

The ADI is intentionally narrow. It tests reproducibility behavior directly and publishes raw transcripts and scoring so anyone can verify.

Closing thought

Determinism is not about blocking innovation. It is about defining the boundary between controllable behavior and untraceable variation. In critical contexts, that boundary is the difference between a decision that can be defended and one that cannot.

Lemma Ventures engineering. We focus on verifiability first, because every replay that fails to verify is a gap in the control system.