Enterprise AI · Architecture
Probabilistic models are the wrong primitive for workflows that must produce identical outcomes for identical inputs. But that isn't a reason to hold LLMs back — it's a reason to change the architecture around them.
Ask any production LLM the same question twice at temperature zero. In many deployments, you will get two different answers. That is fine when you are brainstorming a subject line. It is a compliance event when the workflow is a claim payout, a regulatory filing, or a bill of materials being pushed to a shop floor.
This is the conversation we have been having with clients for the last eighteen months. And it is the conversation the market is now catching up to.
01 · The Problem
Probabilistic by design, non-deterministic in production
Large language models do not produce answers. They produce probability distributions over the next token, and then something samples from that distribution. Even when you set the sampling to be as greedy as possible — temperature=0 — commercial cloud APIs still routinely return different outputs for the same prompt.
Recent research from Thinking Machines Lab traced the culprit precisely: the reduction kernels inside the model (the operations behind RMSNorm, matrix multiplication, and attention) split their work differently depending on the batch size on the server at that moment. Whoever else's request happened to share your batch shifted your output by a rounding error, and a rounding error is enough to change the next token, which changes every token after it.
The good news: this is an engineering problem, and it has been solved. Open-source inference engines like vLLM and SGLang now ship batch-invariant modes that produce bit-identical outputs across thousands of runs. The bad news: the major commercial APIs — the ones most enterprises actually consume — still do not promise deterministic outputs as of this writing.
If you cannot guarantee that the same input produces the same output, you cannot audit the workflow. And if you cannot audit it, it does not belong in production.
02 · The Stakes
What "mission-critical" actually demands
Mission-critical automation is not defined by how important the workflow feels. It is defined by four properties that regulators, auditors, and executive risk committees will actually test for:
| Repeatability | Identical inputs must produce identical outcomes. Every time. Regardless of server load or time of day. |
| Auditability | Every decision must be traceable to a specific rule, model version, input, and timestamp — reconstructable months later. |
| Rollback | When something goes wrong, you must be able to isolate the failure, reverse its effect, and prevent recurrence. |
| Defensibility | Under legal, regulatory, or customer scrutiny, the workflow must justify its output on evidence, not vibes. |
A financial reconciliation that produces different totals on two runs is not a bug — it is a control failure. A claims workflow where the same claim can pay differently on Tuesday than on Wednesday is not a novelty — it is a regulatory exposure. A supply-chain automation that reorders inconsistently is not innovation — it is a working-capital problem.
The market is now confirming this in expensive ways. Salesforce executives have publicly acknowledged that their confidence in large language models has declined compared with a year ago, and the company is shifting Agentforce toward more predictable, rule-based automation. This is not a retreat from AI. It is a correction of an architectural mistake — treating a probabilistic component as if it were a deterministic one.
03 · Our Position
We do not deploy LLMs as orchestrators of mission-critical workflows
This is a firm position, not a preference. Not because LLMs are not powerful — they are, extraordinarily so. But because auditability, reproducibility, and rollback are non-negotiable properties of enterprise automation, and no probabilistic component can guarantee them on its own.
This does not mean we are holding LLMs back. It means we are putting them in the right seat.
04 · The Solution
Determinism as an architectural property, not a model property
You do not need the model to be deterministic. You need the system to be deterministic. The distinction is the entire point of this article.
The pattern is a deterministic workflow spine, with LLMs embedded as governed components inside it — never as the orchestrator, always as a bounded interpretation layer whose output is validated before it can affect anything downstream.
Architecture
The six layers, in order
| 01 | Deterministic router. Rules and structured data handle the majority path. The LLM is only invoked when the input genuinely requires interpretation. This alone eliminates 60 to 80 percent of variance risk in most real workflows. |
| 02 | Constrained interpretation. When the LLM is invoked, it produces structured output against a strict schema. No free-text into transactional systems. Ever. |
| 03 | Validation gate. Schema conformance, business-rule sanity checks, cross-reference to authoritative data. LLM output that fails the gate is either re-prompted with corrective context or escalated. It never proceeds silently. |
| 04 | Deterministic business logic. The decision — approve, reject, route, pay, hold — is made by code, not by the model. The model informed the decision; it did not make it. |
| 05 | Idempotent execution. Actions on downstream systems are wrapped in idempotency keys and rollback contracts. A duplicate call cannot double-pay. A failure cannot leave the system half-updated. |
| 06 | Complete audit trail. Every input, model version, prompt hash, raw output, validated output, rule triggered, and action taken — captured, timestamped, immutable. This is what makes the workflow defensible six months later when an auditor asks. |
The result: the system as a whole is deterministic even when the model inside it is not. The same input produces the same outcome — because the outcome is decided by the deterministic layers, not by the sampling temperature of a transformer.
05 · The Other Half
Where LLMs absolutely belong
Nothing above should be read as skepticism about LLMs. They are the most significant productivity technology of the decade. The point is only about where in the stack they belong.
Use LLMs generously for interpretation, summarisation, drafting, exploratory analysis, and any workflow where a human reviews the output before it becomes an action. Use them for classification, extraction, and translation into structured form — with validation. Use them anywhere the variance is a feature, not a bug: creative work, ideation, first drafts, code scaffolding.
Do not use them as the last-mile decision-maker in a workflow that must produce identical outcomes for identical inputs. That is not what they are for.
06 · How We Apply It
The Profecia Links approach
Eighteen years of enterprise systems integration has taught us that architectural discipline is what separates workflows that survive an audit from workflows that do not. Our partnerships with Oracle, Microsoft, Salesforce, and ServiceNow exist precisely because we bring deterministic backbone to systems that clients then extend with AI capability.
Internally, AI is a productivity multiplier across our engineering teams — it lifts UI/UX consistency, accelerates code review, improves security posture, and frees senior engineers to focus on architecture. Our engineers own every architectural decision and every line of code that ships to a client. AI helps them move faster on the parts that should be fast. It does not replace the judgement about what to build.
The same discipline applies to what we build for clients. When we integrate LLMs into enterprise workflows, they sit inside a governed architecture with validation gates, deterministic business logic, and complete audit trails. The AI accelerates the work. The architecture makes it defensible.
07 · A Test You Can Apply Today
Two questions to ask about any LLM automation in your pipeline
Before you approve any AI-driven workflow for production in a regulated or mission-critical context, ask two questions:
One. If we run this workflow twice with identical inputs, are we guaranteed identical outcomes? Not identical model outputs — identical business outcomes.
Two. If an auditor asks us six months from now why the workflow made a specific decision, can we reconstruct the exact input, the exact model version, the exact rule that fired, and the exact action taken?
If the answer to either is no, the workflow is not ready. Not because the AI is wrong. Because the architecture around it is incomplete.
Work with us
Architecting deterministic workflows around AI capability is what we do.
If you are evaluating an LLM-driven automation for a regulated or mission-critical workflow — or trying to make an existing one defensible — let us walk through it with you. Eighteen years of enterprise integration experience, zero client attrition, and a firm view about where the deterministic line belongs.
Top comments (0)