Deterministic or Probabilistic

Attio is the agentic CRM for modern teams. It’s your always-on revenue engine: agents and workflows build pipeline, chase every buying signal, and move deals forward alongside your team. Try Attio now.

In This Issue

• The difference between deterministic rules and probabilistic models.

• How to tell whether a task needs judgment or explicit logic.

• Why predictable decisions should remain outside the model.

• Where rule engines become too complex to maintain.

• How to combine models and rules in one production workflow.

An AI model can evaluate a request, classify it, summarize it, and recommend what should happen next.

That does not mean the model should make every decision.

Some tasks contain ambiguity that cannot be resolved through a practical set of explicit rules. Others have exact requirements that the system already knows. Using a model for the second type introduces uncertainty without adding useful intelligence.

The architectural decision begins with one question:

If the correct action can be expressed completely and maintained as logic, use rules. If the task requires interpreting language, recognizing patterns, ranking uncertain alternatives, or generating a context-sensitive response, a probabilistic model may be appropriate.

Most production workflows need both. The useful boundary lies between interpreting the situation and enforcing what must happen.

Deterministic means the decision is specified

A deterministic component applies defined logic to known inputs.

Given the same inputs and system state, it produces the same result. Its behavior can usually be described through conditions, calculations, decision tables, state transitions, or constraints.

Examples include:

• Rejecting a transaction above an account limit.

• Requiring approval when a purchase exceeds a threshold.

• Routing records according to region and service tier.

• Checking whether a required field is missing.

• Preventing a user from accessing a resource without permission.

• Calculating tax from defined rates and categories.

The system does not need to infer what the policy probably means. The policy already defines the result.

These decisions benefit from determinism because their value comes from consistency. The organization needs the rule to be applied the same way, tested against known cases, and changed deliberately when the policy changes.

A rule engine also makes the decision path inspectable. The team can identify which condition fired, which version of the rule was active, and which input produced the result.

Probabilistic means the system estimates

A probabilistic component does not follow an exhaustive map from every possible input to one prescribed answer. It estimates an output from patterns learned or represented by a model.

This is useful when the inputs are variable and the desired result depends on meaning, similarity, likelihood, or context.

Examples include:

• Classifying the intent of a customer message.

• Extracting fields from inconsistent documents.

• Ranking search results by likely relevance.

• Detecting unusual behavior.

• Summarizing a long conversation.

• Drafting a response for a particular situation.

These tasks are difficult to express as complete rules because the number of possible inputs is large and their meaning is not always literal.

A model can generalize across examples that were never written into a decision table. That ability creates its value and its uncertainty. The same flexibility that lets the model handle unfamiliar language also prevents the team from specifying every outcome in advance.

Probabilistic output therefore needs evaluation across representative cases. Passing a set of exact unit tests is insufficient because the system can produce outputs that are reasonable, wrong, incomplete, or unstable in ways the developer did not enumerate.

Use rules when the correct answer is already known

Teams sometimes introduce a model because the existing logic has not been documented.

That is not the same as needing judgment.

Suppose employees send purchasing requests in free text. A model may be useful for extracting the supplier, amount, category, and requested date. Once those fields are known, approval authority may follow an exact company policy.

The model can interpret the request. The rule engine should enforce the policy.

Asking the model whether a purchase “seems appropriate for automatic approval” replaces a known rule with an estimate. It makes the outcome harder to reproduce, explain, and audit.

The same principle applies to security controls, retention periods, financial limits, mandatory disclosures, supported regions, and contractual restrictions. If the organization has already made the decision, the application should encode it directly.

Models should not be used to rediscover policy on every transaction.

Use a model when rules stop describing the task

A rule-based system is attractive because each rule appears understandable. The advantage declines when the rule set becomes a growing catalogue of exceptions.

A customer-message classifier might begin with a few keyword checks. “Refund” routes to billing. “Password” routes to account support. “Delivery” routes to shipping.

Then real language arrives:

• “The parcel never came, and I want my money back.”

• “I was charged after cancelling.”

• “I cannot enter my account to view the invoice.”

• “The order arrived, but it belongs to somebody else.”

The team adds ordering rules, phrase combinations, exclusions, and overrides. Every repair creates a new interaction with existing logic. The rule system is now attempting to represent meaning through an expanding set of textual conditions.

This is where a probabilistic model can provide a cleaner boundary. The model classifies the request from its language and context. Deterministic logic then routes the classified request according to ownership, customer status, permissions, and escalation policy.

The model handles interpretation. Rules handle commitment.

Test whether experts can state the rule

A practical way to choose the architecture is to ask subject-matter experts two different questions:

1. Can you explain the exact rule that produces the correct answer?

2. Can you consistently recognize a good answer when you see one?

If experts can state the logic completely, encode it as rules.

If they cannot describe an exhaustive rule but can label examples consistently, a model may be able to learn or apply the pattern.

If experts cannot agree on the correct result, the problem is not ready for automation. Adding a model will hide the disagreement inside an output that appears decisive.

The team must first define the objective, acceptable outcomes, and evidence of quality. A model cannot compensate for an unresolved decision.

Keep hard boundaries outside the model

A probabilistic system can recommend an action while deterministic controls limit what the application may execute.

This separation matters most when an incorrect action carries material consequences.

A useful application pattern looks like this:

The model may propose a tool call, but the application verifies whether that tool is allowed. The model may extract a payment amount, but the application checks its format and limit. The model may identify a likely customer intent, but routing rules determine which systems and data that intent can reach.

This architecture preserves the model’s flexibility while keeping authority in components that can be tested exactly.

Do not force the whole workflow into one category

“Deterministic or probabilistic” is rarely a decision about the entire application.

It is a decision about each step.

Consider an invoice-processing workflow:

1. A model reads the invoice and extracts supplier, date, line items, taxes, and total.

2. Deterministic validation checks that required fields exist and the arithmetic reconciles.

3. A model maps unfamiliar descriptions to likely accounting categories.

4. Rules determine the approval path from amount, cost center, and supplier status.

5. A person reviews exceptions that exceed defined risk thresholds.

6. Deterministic logic records the approved transaction in the accounting system.

Calling this an “AI invoice system” hides the architecture. The workflow contains interpretation, validation, classification, policy enforcement, human judgment, and execution. Each responsibility has a different tolerance for uncertainty.

Design improves when those responsibilities remain visible.

The two systems fail differently

Deterministic systems usually fail because the rule is wrong, missing, outdated, or applied to an input the designer did not anticipate.

Probabilistic systems can fail even when the application and model are operating as designed. The model may misinterpret an input, assign the wrong class, omit an important fact, or generate a plausible answer unsupported by the evidence.

That difference changes testing.

Rules should be tested against boundaries, conflicting conditions, state transitions, and policy versions. Teams can define expected outputs for specific inputs.

Models should be evaluated over representative datasets and difficult cases. Teams need to measure the frequency and consequence of errors, watch performance across relevant groups, and monitor whether production inputs are changing.

A hybrid workflow needs both forms of testing. The deterministic shell should be testable independently from the probabilistic component.

Complexity can move in either direction

Rules are simpler when the task has a small, stable decision surface.

Models become attractive when maintaining the rules costs more than evaluating and operating the model. But replacing hundreds of rules with one model call does not eliminate complexity. It changes its location.

The team now needs evaluation data, model-version controls, monitoring, fallback behavior, latency management, and a process for handling uncertain outputs.

The comparison should therefore include operating complexity:

• How frequently do the rules change?

• How many exceptions interact?

• Can expected outcomes be specified exactly?

• Is representative evaluation data available?

• What happens when the model is uncertain or wrong?

• Can the application safely contain an incorrect result?

• Does a simpler deterministic baseline already perform well enough?

The most sophisticated option is not automatically the most suitable one. Architecture should reflect the structure of the task.

The move

Take one proposed AI workflow and divide it into individual decisions.

For each decision, complete this contract:

Then assign each decision to one of four paths:

• Rules when the required behavior is explicit and stable.

• Model when the task depends on interpretation or generalization.

• Model plus rules when the model proposes and deterministic logic constrains.

• Human judgment when the decision remains ambiguous and the consequences require accountable review.

Start with the simplest deterministic baseline that can perform the task. Add a model when the evidence shows that rules cannot handle the necessary variation without becoming fragile or unmaintainable.

Worth reading

Google’s Rules of Machine Learning recommends launching without machine learning when a reasonable heuristic can establish the first working baseline. It also identifies the point where a growing heuristic becomes too complex to maintain and a learned model becomes the stronger option.

Rules of Machine Learning

Takeaways

• Use deterministic logic when the organization already knows exactly what must happen.

• Use probabilistic models for interpretation, classification, ranking, and generation.

• Decide separately for each workflow step.

• Keep permissions, limits, prohibitions, and policy enforcement outside the model.

• Establish a deterministic baseline before adding model complexity.

• Move from rules to a model when the rule system is becoming an unmaintainable representation of judgment.

• Test rules for exact behavior and models for measured performance across representative cases.

If this helped you, leave a comment or your reaction. I’d like to hear where you landed.

INVENEW exists to help tech builders, operators, founders, and leaders turn AI from experiments into working systems.

Sponsored

👨‍✈️ AI is moving fast. Is your security strategy keeping up?

SECURITY DEMO → GRC strategies for securing cloud AI: Join experts from Amazon Web Services (AWS) and SANS Institute for a hands-on security demo exploring how to apply governance, risk, and compliance (GRC) strategies across modern AI environments. See approaches for managing identity and agent access, protecting sensitive data, strengthening detection and response, and addressing risk across the AI lifecycle.

Note: Third-party company and product names belong to their respective owners and are used for identification and illustrative reference only.