Roman Poliashenko
When we demo a voice or chat agent, the first reaction is «wow, it talks like a person». The next question is almost always the same, and it is the right one: «What if it says something dumb to my customer?» Invent a price that doesn't exist. Promise a delivery you don't offer. Snap back at rudeness. Tell a competitor something it shouldn't. This is where it is actually decided whether an agent can be let anywhere near live customers — and it is exactly what demos talk about least. Below: how we answer that question — what guardrails are, how we ground the agent in facts, why escalation to a human matters more than a «smart» answer, and how we test all of it before the first call.
The problem isn't that the agent stays silent — it's that it can say too much
A large language model, by default, wants to be helpful. It was not trained to say «I don't know» — it was trained to produce an answer. So a «bare» agent, if you constrain it in nothing, will sooner invent a plausible falsehood than admit ignorance. For a chatbot writing poems that is no problem. For an agent that quotes prices, terms and timelines on behalf of your business, it is a direct reputational and financial hole.
So our job as an integrator is not «to teach the agent to talk». It talks out of the box. Our job is to teach it to stay silent where it must, to answer only from your facts, and to honestly hand the hard cases to a human. That is what guardrails are.
«Task done» is not the same as «said the right thing»
The most common trap when adopting AI is confusing «the agent replied» with «the agent replied correctly». A bot that cheerfully says something to every question looks like it works in a demo and becomes a source of problems in production. Formally it «handled» every conversation. In fact it ruined some of them — and you won't find out until an unhappy customer calls.
So from the start we separate two things: did the agent give an answer and was that answer correct, appropriate and safe. The first is basic functionality. The second is what we actually verify and stand behind. Guardrails exist for the second one.
What a guardrail actually is
A guardrail is not «one more prompt with the words please don't make mistakes». It is a set of concrete, verifiable rules and mechanisms that keep the agent within bounds even when the customer, deliberately or by accident, pushes it past them. In practice we build several layers.
- Allowed and forbidden topics. What the agent talks about (your product, services, booking, order status) and what it does not (politics, advice only a doctor or lawyer should give, other brands, the company's internal kitchen).
- Rules for prices and commitments. Often the safest thing is not to quote an exact price by voice at all, but to hand the calculation to a human or a system. The agent has no right to invent discounts, deadlines and guarantees.
- Personal-data protection. The agent doesn't fish for more than it needs, doesn't read card numbers back out loud, and doesn't dictate sensitive data where it could be overheard.
- Tone and behaviour under pressure. To rudeness — calm and focus on the point; to provocation — don't take the bait; to an attempt to «jailbreak» the agent with instructions in the chat — ignore them as text, not as a command.
- Escalation to a human. The main guardrail, covered separately below: when the agent is unsure, it hands off instead of improvising.
The defining feature of a good guardrail is that you can test it. «Be polite» is hard to check. «Never quote a price as a number; offer a free estimate instead» is easy: write a dozen provocations of «so how much does it cost?» and see whether the agent ever slips into a concrete figure.
Grounding: the agent answers from your knowledge, not its imagination
The strongest defence against invention is grounding. Instead of answering «off the top of its head», we give the agent access to your knowledge base as a tool: before it says anything about your product or terms, it retrieves the relevant fact from the provided material and answers from that. No fact in the base — no answer; the agent honestly says it will check, and escalates if needed.
This shifts responsibility for correctness from «whatever the model dreamed up» to what you gave it. Your knowledge base becomes the single source of truth: update the delivery terms and the agent quotes the new ones; remove prices from the base and the agent physically has no number to state. It is not a 100% guarantee, but it is the difference between an agent that sometimes guesses and an agent that leans on your text.
A practical detail: grounding only works when the knowledge base is clean. Half the work on a «smart» agent is really the work of making the facts in the base accurate, consistent and current. We spend no less time on that than on the prompt itself.
The most important guardrail is an honest «I'll pass this to a person»
If you stripped everything else away and kept one mechanism, it would be escalation. An agent that can say, at the right moment, «I'll pass this to a colleague, they'll get back to you» is a hundred times safer than an agent that has an answer for everything. Because a confident wrong answer costs more than an honest «I don't know».
We deliberately design agents so the escalation threshold is on the low side: a doubtful question, a sensitive topic, a conflict, a non-standard request, a sign the customer is annoyed — and the conversation goes to a human together with the context, so the customer doesn't have to repeat everything from the start. The human doesn't disappear in this scheme. The agent takes the volume and the routine and leaves the hard, risky part to people — but already sorted and prepared.
This, by the way, also removes the skeptics' main objection: «I don't want a robot deciding my customer's fate». It doesn't decide. It handles the simple, and on the hard part it calls you.
Voice adds its own traps
For voice agents, on top of the content guardrails come conversational ones — things that simply don't exist in chat. We've stepped on all of these more than once, so let's list them honestly.
- Barge-in. A person must be able to interrupt the agent mid-sentence — and it must go quiet and start listening, not finish its monologue over the other person.
- Background noise. A knock on the table, a cough, background chatter must not be taken as «the customer spoke» and throw the agent off. This is solved at the level of how the system detects speech, not «on faith».
- Silence. If the customer goes quiet, the agent must handle it properly — check back in, not freeze or start talking to itself.
- Latency. A long pause before the reply breaks the sense of a live conversation more than a less-than-perfect answer does. A short, timely line is often better than a rich one that arrives late.
None of these show up on the slide that says «our agent talks». All of them decide whether the conversation feels alive — or whether the customer hangs up in the first ten seconds.
How we test the agent before a customer ever hears it
Guardrails are worth nothing until you've proven they work. So before launch the agent goes through more than «we chatted, seems fine» — a separate testing stage. The logic is the same as in software engineering: if a behaviour isn't verified automatically, assume it isn't there.
Adversarial scenarios. We write a set of conversations that deliberately try to break the agent: extract a price, pull advice outside its competence, provoke it with rudeness, derail it with an instruction mid-chat, ask a trick question on the edge of the topic. Not the «happy path» — the worst cases on purpose.
A model playing the customer. To run dozens of such scenarios, we stand up a second model as a «difficult interlocutor», and it actually talks to the agent in a simulation — the way a biased customer would. This gives scale that manual testing can't.
An LLM judge against clear metrics. Each of the agent's answers is scored by a separate judge model against predefined criteria: did it avoid quoting a price, did it ground on a fact, did it escalate where it should, did it hold its tone. Not «by eye» but a score per metric — so results are comparable from version to version.
A regression suite. All these checks stay forever. Change the prompt, update the knowledge base, tweak one answer — the whole suite is re-run. So a fix in one place doesn't quietly break behaviour in another.
We deliberately build this test loop on the same technologies as the agent itself, and without expensive third-party platforms — so verification is part of every iteration, not a one-off ceremony before handover.
What guardrails don't do
Let's be honest, because it matters more than pretty promises. Guardrails reduce risk; they don't take it to zero. No serious team guarantees an agent will never once make a mistake — anyone who promises that either doesn't understand the technology or is being cute. Language models are probabilistic by nature.
So our stance is simple: the agent should cover the volume of simple, repetitive conversations where it is reliably correct, and hand off everything risky to a human. Plus monitoring after launch: we listen to real conversations, catch new edge cases we didn't foresee, and feed them back into the test suite. An agent's safety is not a «done and forgotten» state — it is a process that continues as long as the agent runs.
That is exactly why we don't sell a «box bot that can do everything». We build an agent for your process, with your guardrails, verified on your scenarios — and we stay close when reality throws in what wasn't in the plan.
