Trust is an architecture

Trust is an architecture. You don't coax trust out of a model with clever wording, and no vendor can hand it to you ready-made. You design it, the way you'd design any system you plan to rely on.

For a couple of years, "hallucination" was the word standing between enterprises and putting AI in front of a customer, and it's still the number-one named obstacle. In practice, though, that fear increasingly belongs to an earlier era. Almost none of my customer conversations now open with "our agent made something up." The models got better, grounding got better, and outright hallucinations, at least in customer support, are largely a thing of the past.

So the frontier has moved. The strongest teams have stopped asking whether the model will lie and started asking a more specific question: how much of the job should the model be deciding at all? Almost always, the answer is less than what ends up in the prompt. Real trust comes from an architecture that only asks the model to do the part it's genuinely good at.

From hallucinations to wrong decisions

When an agent goes wrong today, it's rarely because it invented a fact. Far more often, it reached for the wrong tool, or asked the customer for the wrong thing next. You can debate whether that even counts as a hallucination. Maybe it does, maybe it doesn't.

What matters is that "the model lied" sends you looking in the wrong place, because the label you put on a problem decides what you go fix. Chase truthfulness and you'll hunt for a better prompt or a smarter model, when the thing in front of you is a design problem: the system handed the model a decision it might not have been best suited to own.

The real problem is reliability

The question worth sitting with is reliability. Can you build an agent that does the same thing every single time? That one points at something you can actually control.

The irony is that once you take reliability seriously, you stop reaching for a bigger, more capable model and start reaching for determinism. The parts of a customer interaction with exactly one correct outcome don't need intelligence. They don't need reasoning or creativity. They need to be right every time, on rails. The more of your agent you can put on rails, the less there is to go wrong.

Where business logic should live

Here's a pattern I run into constantly. Someone bakes business logic straight into the prompt. If it's a US phone number, ask for a zip code. If it's a Canadian number, ask for a postal code. Both branches, written out as an if-statement, sitting inside the prompt in plain English.

That should just be a deterministic workflow. It's a rule with exactly one right answer, and instead you've handed it to a language model and asked it to remember to follow along. One rule like that is fine. But multiply it. Take every combination of business logic in a real support flow and put all of it into the prompt, and you haven't made the agent smarter; you've given the model more surface area to trip over. Every branch written in English instead of in a deterministic flow is another place it can go wrong, and once you've stacked dozens of them together, you shouldn't be surprised when the behaviour turns out inconsistent.

Give the model less to get wrong

The honest answer to "how do you reduce hallucinations" is that mostly, you don't. You think about the whole system and where each kind of work belongs. Some moments genuinely need intelligence and conversational fluidity, the part only a model can do well when it's meeting a real person in an open-ended situation. Others just need a rule that fires the same way, every time, and that kind of rigidity belongs in a deterministic framework, not in the prompt. Do that, and the work you hand the model is only what it's genuinely good at.

The catch is that you can't do any of this if you can't see inside your own agent. You can't decide what belongs to the model and what belongs in code when the whole thing is a black box that somebody else runs. You get to hope the prompt holds and open a ticket when it doesn't. Reliability is a design decision, and design decisions need control: being able to see where a choice gets made, move it to where it belongs, and trust it will behave the same way next week.

That's the philosophy we build on at Voiceflow. Put generative reasoning where you need it, keep deterministic guardrails where you don't, and give your team an agent they can actually see into and shape. Trust in an AI agent doesn't come from a better sentence in the prompt. It comes from the architecture around it, and from owning that architecture instead of renting it. That's what owning your CX really means: when your team controls how the agent is built, better resolutions and stronger ROI stop being numbers you hope a vendor hands you, and start being outcomes you engineer.

‍