Deterministic workflows

Zero hallucination, because the model never authors the answer

Hallucination is not a quirk to be tuned down. It is what happens when you let a language model decide facts. Take it out of that role and the failure mode disappears.

Most AI support systems hand the whole conversation to a language model and then try to constrain it — better prompts, more retrieval, stricter instructions. That is damage limitation. The model is still the thing composing the answer, so it can still compose one that is wrong.

Dialog365 inverts the arrangement. Deterministic workflows carry the conversation. The model is used for a narrow, bounded set of tasks, and authoring facts is not one of them.

Where the model is used, and where it is not

TaskHandled byWhy
Understanding what the customer wantsLanguage modelNatural language is exactly what models are good at
Deciding which workflow appliesLanguage model, constrained to a fixed setA classification with a closed answer set, not open generation
Retrieving the customer's actual dataDeterministic tool callA lookup either returns the value or fails visibly
Deciding what the policy saysDeterministic workflow stepPolicy is a rule, not an opinion
Composing the factual content of the replyDeterministic workflowNothing to invent if nothing is generated
Phrasing an approved response naturallyLanguage model, within approved contentWording varies; facts do not

The distinction that matters is the fifth row. In a conventional setup, the model decides both what is true and how to say it. Here it only ever does the second, working from content the workflow supplied.

Why this produces the same answer every time

A deterministic workflow is a defined path: check identity, look up the order, evaluate the returns policy against the purchase date, state the outcome. Run it twice with the same inputs and it produces the same outcome, because it is code rather than a sample from a probability distribution.

  • The same question about the same account returns the same answer, every time
  • Policy changes are made once, in the workflow, not chased through prompt text
  • Every factual claim traces to a system of record or an explicit rule
  • There is no temperature setting that quietly changes what customers are told

Low LLM dependency is an operational property, not a purity test

Reducing how much the model decides has consequences that show up well beyond accuracy:

PropertyModel-led approachDeterministic workflows
TestabilitySampled, probabilistic, never exhaustiveEach path can be tested like any other code
AuditabilityExplain a generation after the factPoint at the step and the record it read
Cost per contactEvery turn is an inference callModel used for narrow tasks; most steps cost nothing
LatencyBounded by model round tripsDeterministic steps return in milliseconds
Model changesBehaviour shifts, needs revalidationAnswers unchanged; only phrasing is model-dependent
Regulatory reviewHard to evidence what it will sayThe decision path can be read and signed off

What happens when no workflow matches

This is the honest boundary. If the customer asks something no workflow covers, the system does not improvise — it says so and routes to a person with everything already established. A gap in coverage becomes an escalation and a logged request for a new workflow, rather than a confident invention.

Coverage is the thing to measure, not accuracy in isolation. Accuracy within the deterministic paths is a property of the design. The question worth asking of a deployment is what proportion of contacts an existing workflow covers, and that is a number you grow deliberately.

Where retrieval still fits

Not every answer is a rule or a record. Explanatory questions — how something works, what a term means — are answered from your own documentation, retrieved for that specific question, with the source cited. The model still does not draw on training data: it works from the passage retrieved, and if nothing relevant is retrieved, it declines.

What this costs you

Being straightforward about the trade: deterministic workflows have to be built. A system that hands everything to a model appears to cover everything on day one, which is why demos favour it. Coverage here is deliberate and grows contact type by contact type. What you get for that work is a system whose answers you can predict, test, audit and defend — which is usually the point.

Frequently asked questions

How can you claim zero hallucination?

Because the language model never authors the factual content of a reply. Answers come from deterministic workflow steps and system-of-record lookups; the model is used to understand the request and to phrase content the workflow has already supplied.

What is the language model actually used for then?

Understanding what the customer wants, selecting which workflow applies from a fixed set, and phrasing approved content naturally. It does not decide what is true.

What happens if no workflow covers the question?

The system says so and routes to a human with the transcript and everything already established. It does not improvise an answer, and the gap is logged so a workflow can be added.

Does this mean less flexibility than a model-led bot?

On day one, yes. A model-led bot appears to answer anything, including things it gets wrong. Deterministic coverage is built deliberately and grows, and within it the answers are predictable and auditable.

Does lower model usage reduce cost?

Yes. Most workflow steps involve no inference at all, so cost per contact is substantially lower than a design that calls a model on every turn.

See it on your own calls

Tell us how your contact centre runs today and we will map it to your setup.

Contact Sales

Related