AI assistants and agents are not deterministic – but they can be used to build deterministic systems

A language model can give different answers to the same question. The wording can change. The reasoning can take a different path. A tool can be called with different parameters. Sometimes the result is better than expected. Sometimes the model misses something that seemed obvious.

This is not a temporary defect that will necessarily disappear with the next model version. The variation is part of how the technology works. Which is why you sometimes hear the conclusion:

AI cannot be used in systems where the result has to be predictable.

It is a reasonable objection, but a conclusion that goes too far. The AI assistant does not itself have to be deterministic for the system around it to deliver a controlled and verifiable result.

Two different kinds of systems

Traditional software is usually built on explicit rules. If a certain condition is met, a certain operation is performed. The same input, the same code and the same state should in principle produce the same result.

A language model works differently. It computes which answer is probable given the instruction, the context and the model. Even when the variation is constrained, you cannot assume that every run produces exactly the same result.

That is an important difference. But the two kinds of systems do not have to compete. They can be used for different parts of the same workflow.

AI is good at:

• interpreting unstructured information
• identifying possible patterns
• formulating hypotheses
• suggesting classifications
• generating code or configuration
• explaining complicated material
• producing possible courses of action

Traditional software is good at:

• checking data types and formats
• applying fixed rules
• performing calculations
• managing permissions
• validating limits
• maintaining state
• logging and tracing decisions
• stopping disallowed operations

The interesting part begins when we let each system do what it does best.

AI can propose – the system decides

Suppose an AI agent reads a document and tries to determine which information classification it should have.

It would be risky to let the model's free text directly control storage, access or publication. The model can misread the document, use a category that does not exist or give an ambiguous answer. Instead, the model can be asked to deliver a structured proposal:

{
  "proposed_class": "confidential",
  "identified_risks": [
    "personal data",
    "financial information"
  ],
  "rationale": "The document contains..."
}

The surrounding system can then verify that:

• the class exists in the organization's established model
• mandatory fields are filled in
• identified personal data is handled according to the rules
• the AI is not attempting a disallowed action
• a human approves the classification when the risk requires it

The AI interprets and proposes. The deterministic part validates, decides and executes.

Separate the reasoning from the decision

A common architectural mistake is to let the language model both analyze the situation and make the final decision. That can work in a demonstration. It becomes much harder to control in a business system.

A safer division is:

Unstructured information
          ↓
   AI-based interpretation
          ↓
   Structured proposal
          ↓
 Deterministic validation
          ↓
Rules or human decision
          ↓
       Execution

The model is used where variation is valuable: interpretation, context and proposals. Program code and established rules are used where variation is dangerous: permissions, financial transactions, decisions affecting citizens and changes in other systems.

AI can also create deterministic artifacts

AI does not always have to participate when the system runs. An assistant can be used during development to create program code, tests, validation rules, database schemas, configuration files, decision rules, infrastructure definitions and documentation. The result can then be reviewed, tested, version-controlled and run as ordinary software.

The AI's work happens before the system goes into operation. The finished system does not have to call a language model at all.

This resembles how a human developer works. The developer's thought process is not deterministic. Two developers can produce different solutions to the same problem. But the program that is reviewed, compiled and deployed can still behave predictably.

AI-generated code should be judged by the same principle:

We should not trust the code because we trust whoever wrote it. We should trust it because we can verify how it behaves.

Tests are the bridge between probability and predictability

If an AI assistant generates a function, the result can vary between runs. But the function does not have to be accepted as-is. It can be checked through unit tests, integration tests, type checking, static analysis, security scanning, code review, reproducible builds and test data with known expected results.

Once the code passes the established checks, exactly how it was created matters less.

That does not mean tests prove the system is free of defects. They never do. But they turn a probable proposal into an artifact that can be judged against explicit requirements. AI produces a possible answer. The tests decide whether the answer gets to become part of the system.

Structured output is not enough

It has become common to require a language model to answer in JSON or follow a defined schema. That is an important improvement, but it does not make the model's conclusion deterministic.

An answer can be syntactically correct and still contain the wrong classification, fabricated facts, a weak rationale, disallowed combinations, or values that are correct in format but wrong for the business.

Structured output makes the model's answer easier to check. It does not replace the check. A schema can guarantee that the amount field contains a number. It cannot by itself guarantee that the amount is accurate, reasonable or approved.

Agents need explicit authority

The problem becomes especially important when an AI does not just give advice but is also allowed to use tools. An agent might read documents, search databases, create tickets, send messages, change configuration, order resources and start other processes.

Then a good instruction is not enough. The agent's actual authority has to be constrained technically. A robust system should define:

• which tools the agent may use
• which data it may read
• which objects it may change
• permitted parameters
• limits on amounts and volumes
• which actions require approval
• how every operation is logged
• how a running process can be stopped
• how incorrect changes are rolled back

The agent may be allowed to propose that an account be closed. It should not necessarily have the permission to do it. The agent may be allowed to draft a message. A deterministic system can check the recipients, the data classification and the mandatory approval before anything is sent.

Instructions steer behavior softly. Permissions and validation steer it hard.

When a human must be in the loop

Human approval is sometimes used as a general safety solution. But a human in the loop only helps if the person understands what is being judged, receives sufficient information, has time to perform a real check, has the mandate to stop the process — and is not exposed to so many proposals that approval becomes routine.

If a user is expected to approve hundreds of AI-generated decisions per day, the human control soon becomes symbolic.

Human review should therefore be reserved for what genuinely requires judgment. Machine-verifiable requirements should be checked by code.

Not everything needs to become deterministic

Nor is it always necessary to eliminate variation. If an AI helps draft a text, summarize a meeting, suggest questions, find possible problems or create alternative solutions, variation can be an asset.

The requirement should not be that every system always gives identical answers. The requirement should be that the degree of variation matches the consequence of an error. The greater the impact an action can have, the less the system should rely on the model's free judgment.

The deterministic shell

A useful way to think is to place the non-deterministic model inside a deterministic shell. The shell can consist of:

• identity and permission checks
• validated inputs and outputs
• permitted tools
• fixed business rules
• tested code components
• transaction limits
• logging and traceability
• human checkpoints
• safe defaults
• mechanisms for aborting and rolling back

The model gets to work inside the shell, but it does not get to decide where the shell's boundaries are.

In practice this is the same principle used for people in well-governed organizations. We do not assume that every individual always acts in exactly the same way. We build roles, permissions, approval rules, controls and follow-up around the work.

The question is not whether the AI can be trusted

When organizations discuss AI agents, the conversation often lands in a question that is too simple:

Can we trust the model?

A better set of questions is:

• What may the model propose?
• What may it decide?
• What may it execute?
• Which results can be verified automatically?
• Which actions require human approval?
• What happens when the model is wrong?
• Can the error be detected before it has consequences?
• Can the action be rolled back?
• Who owns the final responsibility?

A model that is sometimes wrong can still be very useful in a system that expects it to sometimes be wrong. A model that appears highly accurate can, on the other hand, become dangerous in a system that lacks controls for the few occasions when it fails.

The architecture comes before the agent

We will probably use more and more assistants and agents. They will get better at reasoning, using tools and carrying out longer workflows.

But better models do not abolish the need for system architecture. On the contrary. The more capable the agents become, the more important it becomes to distinguish between probable judgments and permitted actions.

The AI assistant does not have to be deterministic. But the system must be deterministic where the business requires it.

We do not achieve that by writing longer instructions to the model. We achieve it by building clear boundaries, verifiable artifacts, tested rules and controlled authority around it.

AI can provide the interpretation, the variation and the proposals. The system must still provide the rules, the decisions and the responsibility.