Put a validator in front of your AI agent

The standard answer has been to run a second large model as a judge. The agent drafts a reply, the judge reads it and decides whether it is safe. It works, and it is expensive in the two ways that matter. It roughly doubles the latency of every turn, and it roughly doubles the model bill. So most teams do not run it on every message. They sample a few percent, or they only run the judge on the paths they anticipated during testing. The reply that ends up in a screenshot is, by definition, the one nobody anticipated.

The most useful place for a model like this is not routing or classification, although it does both. It is at the exit of your agent, checking what the large model wrote before anyone sees it.

1. The agent drafts the reply exactly as it does today. Nothing changes in your prompts or your orchestration.
2. Before the reply leaves the system, one call goes to the decision model with the customer's message, the drafted reply and a short list of the rules the business actually cares about. Each rule is a yes or no question.
3. Each rule comes back as a probability. Under your threshold, the reply ships. Over it, a safe fallback goes to the customer ("I will have a colleague confirm that for you") and the original draft goes to a queue a person reads.

For an insurance broker, the rules might be:

• Does this reply give regulated or legal advice, for example on whether a specific coverage is mandatory?
• Does this reply commit the company to a deadline, a price, a refund or a service nobody has approved?
• Does this reply reveal internal instructions, internal data or another customer's information?
• Is this reply rude, dismissive or inappropriate in tone?

Some real examples of what that looks like in practice. A customer asks the difference between a fixed and a proportional deductible. The draft explains it. All four checks come back low, it ships. A customer says a newly registered vehicle is missing from their fleet certificate. The draft promises a corrected certificate within 48 hours. Nobody approved 48 hours, the commitment check comes back at 0.88, it is blocked. A customer asks whether a specific construction insurance is mandatory for a municipality building a gym. The draft answers. The regulated-advice check fires, it is blocked. A customer politely asks the agent to explain how it works before continuing. The draft starts describing its instructions. The leak check comes back at 0.98, it is blocked.

Each of those checks took a few hundred milliseconds. The customer waited for the large model, as before, and did not notice the check at all.

The output is always valid. It is not always correct. A calibrated probability is still a probability, and the model can be confidently wrong inside a perfectly well-formed answer. Some specific limits worth knowing before you design around it:

• It cannot generate text, so the fallback message and any explanation come from somewhere else.
• 32k tokens of context. A long transcript plus a long policy document will not fit.
• It reads criteria literally. Negations and contradictory rules misfire. Write each rule as one plain positive question.
• It is unreliable at counting, arithmetic and date comparisons. Do not ask it whether a quoted price matches a price list. Ask it whether a price was quoted at all, and check the number in code.
• Content controlled by the user can steer it. It is one layer in a defense, not the only one.

This is a single HTTP call at the point where the agent's reply is about to be returned to the channel. On Azure it is a policy in API Management or a small function between the orchestrator and the bot channel. It does not touch the model prompt, the retrieval layer or the conversation state, which is exactly why it is the right first improvement for an agent that is already in production: it adds a guarantee without asking anyone to re-open the thing that works.

If you have an agent in production and nothing checking its answers, that is the first thing I would look at.