Deterministic vs. Agentic Is the Wrong Question

Almost every AI search product gives you a mode switch. The names vary — deterministic and agentic, strict and creative, guided and autonomous — but the pitch is always the same: pick the cautious one for sensitive content and the clever one for everything else.

We shipped that switch. Then we removed it, because it was answering a question nobody has.

What the switch actually bundles

Look closely at what changes when you flip a mode switch, and you find two decisions welded together.

The first is what the assistant is required to check. Does the policy screening run on this conversation? Is it allowed not to?

The second is what the assistant is allowed to spend. How many times can it re-plan when a search comes back empty? How many tools can it call? How long can a single turn take before it gives up?

These have nothing to do with each other. One is a compliance question, answered by your legal and risk people. The other is a cost question, answered by whoever owns the bill. A mode switch forces you to answer both with one click, and it picks the pairing for you.

Why the bundle bites

Here's the case that exposes it.

You're a regulated business. Every customer conversation has to pass an output check — that isn't negotiable. You also sell a large, messy catalog, where the first search frequently comes back empty and a second attempt from a different angle usually finds the thing.

What you need is maximum effort, non-negotiable checks. On a mode switch, that combination does not exist. The cautious mode gives you the checks and one attempt. The clever mode gives you the attempts and makes the checks optional. You pick which half of your requirements to abandon.

This isn't hypothetical. In our own product, the cautious mode implied a specific guardrail setting so strongly that an experience labeled as governed, with guardrails switched off, ran completely unguarded — and still reported itself as governed. The bundle didn't just limit what you could express. It hid a real failure.

Dial one: what it's required to check

Separate the two, and the governance dial turns out to be simple. It's a lock.

Guardrail rules normally have an on/off toggle, which is fine when the checks are a preference. When they're a requirement, a toggle is the problem — it exists to be switched off, usually at the worst moment, usually by someone with a deadline.

So the lock does one thing: configured rules run on every turn whether or not the toggle is on, and the toggle disables itself. Not a warning. Not an audit note after the fact. There is no off position.

That is the only setting in the product that governs anything. Everything else meters spend.

Dial two: what it's allowed to spend

The other dial is a budget, and naming it honestly changes how you set it. Ours has four numbers: how many times a turn may re-plan, how many tools it may call in total, how long it may run, and how much of your data schema goes into the planning prompt.

Two presets. Standard allows one planning round and three tool calls. Thorough allows three rounds and eight calls.

That's it. No behavioral difference, no personality change, no different safety posture. Just a ceiling.

The part that surprised us

Once we could measure the two dials separately, we ran the same eight questions through both presets against the same index.

Seven of the eight were identical. Same tools, same results, same answer. On the eighth, Thorough spent roughly three times the tokens to reach the same conclusion.

That is the real shape of the spend dial: it costs nothing on any turn that succeeds first time, and it only matters when the first attempt fails. Which reframes the decision completely. The question is not "is more effort worth paying for on average." It's "when my searches come back empty, does trying again actually help on my data?"

You can answer that from your own traces — count how often first attempts return nothing. Nobody can answer it for you from a feature comparison table, which is exactly why a mode switch is a bad way to ask.

What to do instead

Lock the checks that are requirements. Not "switch them on" — lock them. If a check covers policy language, pricing, or anything with legal exposure, it should not have an off position. Do this first, and do it independently of anything else.

Then set the budget from evidence. Look at how often first attempts come up empty on your content. If it's rare, the lower ceiling costs you nothing. If it's common, raise it — and note that you can raise it without touching a single guardrail, because the two are independent.

Stop looking for the mode that makes the AI trustworthy. No mode does that. What makes it trustworthy is that the checks can't be bypassed and that you can read what it did afterward.

The claim we stopped making

The earlier version of this post said deterministic mode meant the AI served pre-approved text with no synthesis and therefore couldn't hallucinate. That was never true of our product, and it's worth saying plainly: our cautious mode always synthesized. What it did was plan once instead of three times.

"It can't hallucinate" is an absolute claim, and absolute claims about generative systems are usually a naming exercise rather than an engineering one.

Here's the version we can actually stand behind. When the system narrows or widens something, it says so. If a search comes back empty and a filter gets relaxed to find results, the answer names the filter it dropped rather than presenting a broader result as an exact match. If a filter can't be translated for an external search provider, it comes back with the reason instead of vanishing. If a knowledge base returns nothing, the answer distinguishes "I didn't retrieve anything" from "that isn't documented" — because those are very different facts, and only one of them is the user's problem.

That is a weaker promise than "no hallucinations." It's also one you can verify in a trace, which makes it worth more.