In August 2025, EY surveyed 975 C-suite leaders across 21 countries on AI governance. The results were bleak: 99% of organizations reported AI-related financial losses in the prior year, and 64% reported losses exceeding $1 million — averaging $4.4 million per affected company. The survey did not identify a shortage of detection tools. It identified a shortage of governance.

That distinction matters. The AI observability ecosystem is well-supplied. Arize, LangSmith, Helicone, and a dozen others have built sophisticated hallucination evaluation frameworks. LLM-as-judge pipelines, faithfulness scorers, groundedness metrics — the tooling exists and much of it works. The problem is architectural, not instrumental: detection tells you an agent produced a bad output. It does not, by itself, determine what happens next.

When agents are connected to production systems — sending emails, updating records, initiating workflows — "what happens next" is the only question that matters.

Why Detection Runs Too Late

Hallucination detection in production AI systems is almost universally retrospective. An agent completes a reasoning chain, generates an output, and the output is routed to an evaluator — a faithfulness scorer, a groundedness check, an LLM judge — which surfaces a confidence signal. If the signal is below threshold, an alert fires or a flag appears in a dashboard.

By the time the evaluator runs, the agent has already acted. In agentic architectures where outputs directly trigger downstream tool calls — calendar invites sent, database entries written, API requests dispatched — detection after the fact is forensics, not prevention.

This problem compounds at scale. Most teams sample between 1% and 5% of production traffic for evaluation. Hallucinations concentrate in the long tail: uncommon intents, edge-case entities, corner inputs that appear rarely but trigger the most confident-sounding wrong answers. Sampling almost guarantees you're evaluating the wrong traffic.

There's also the evaluation quality problem. LLM-as-judge pipelines — using a model to grade another model's output — have documented failure modes: they share biases with the model under evaluation, they correlate with output length rather than factual accuracy, and they require significant calibration to behave consistently across task types. The pipeline is not neutral. A previous post in this series covered why LLM-as-judge fails in production in detail; the failure modes haven't disappeared.

The net effect: detection systems produce signals. Those signals often arrive after the relevant action has already propagated downstream. And the signals themselves require careful interpretation.

None of this means detection is useless. It means detection is necessary but not sufficient for protecting production systems from hallucination-driven failures.

The Missing Layer: Fallback Enforcement

The piece most teams haven't built is a fallback enforcement layer — a mechanism that intercepts an output when it fails a quality check and routes it somewhere other than the downstream action it was about to trigger.

There are three fallback patterns that hold up in production:

Halt and escalate. When an output falls below a defined quality threshold — factuality score, groundedness score, confidence percentile — execution stops and the case is routed to a human reviewer before any downstream action occurs. This is the highest-overhead pattern, appropriate for high-stakes workflows where the cost of a bad action significantly exceeds the cost of delay.

Graceful degradation with caveat. The output is delivered but flagged — with explicit language indicating it could not be verified against available context, or that confidence is below threshold. This works well in customer-facing applications where a delayed response is worse than an uncertain one, and where the end user can decide how to act on the information.

Reroute to a more conservative path. The agent is redirected to a simpler, more constrained version of its task — narrower scope, fewer tool calls, a retrieval-only path with no synthesis — that is less likely to hallucinate but still produces useful output.

What all three patterns share is a runtime dependency: they require the ability to intercept an output before it reaches its intended downstream destination, evaluate it against a policy, and execute a different code path based on the result. This is not an evaluation pipeline. It is a policy engine.

That distinction is what most of the observability tooling doesn't provide. Evaluation surfaces signals. A policy engine acts on them.

The Architectural Gap in the Observability Ecosystem

The major observability platforms — Arize, LangSmith, Langfuse — are built primarily around post-hoc evaluation. They are excellent at answering the question: "What did my agent do, and was it right?" They are not built to enforce what happens when the answer to that question is no.

This is a coherent product choice. Evaluation and enforcement are different problems with different latency requirements. An LLM-as-judge evaluation might add hundreds of milliseconds. An enforcement layer that intercepts production traffic has to add almost nothing — any meaningful latency penalty invalidates the architecture for real-time applications.

The engineering consequence is that teams typically build enforcement manually, if at all: a bespoke script that reads evaluation scores from a monitoring dashboard and attempts to wire up conditional logic in the application layer. This is fragile, hard to audit, and disconnected from the governance intent behind the original evaluation design.

How Waxell Handles This

Waxell Observe instruments agent execution at the framework level — 200+ libraries auto-instrumented with 2 lines of code — and exposes output validation policies as a native runtime control. Quality policies in Waxell include output monitoring across 50+ policy categories, with enforcement actions that fire inline with execution: halt, escalate, route to human-in-the-loop, or log with caveat.

The enforcement runs at 0.045ms p95 latency — fast enough to intercept production traffic without adding perceptible delay to agent responses. The output monitoring surface provides full trace visibility for every evaluation that fires, so teams can audit not just what their agents produced but what governance decisions were made and why.

For high-stakes workflows where a hallucinated output could trigger irreversible downstream action — financial transactions, healthcare documentation, infrastructure changes — Waxell Runtime applies policy enforcement before each step executes, not after. Governance is native to the execution environment, not retrofitted on top of it. Every decision is checkpointed; every workflow can be paused for human review at any point without losing execution state.

The practical effect: an agent in a Waxell-governed environment that produces an output failing a quality policy doesn't deliver that output to its downstream action. It routes to whatever fallback behavior the policy specifies. The detection and the enforcement are the same system, not two separate pipelines requiring manual integration.

Teams building in RAG architectures can also use Waxell's testing environment to evaluate output quality against their specific document corpus before deploying to production — catching failure modes under controlled conditions rather than discovering them in live traffic.

FAQ

What is the difference between hallucination detection and hallucination governance?
Detection identifies that an agent produced a bad output. Governance determines what happens next — whether the output is blocked, rerouted, escalated, or delivered with caveats. Most observability tools provide detection. Governance requires a policy engine that can act on the detected signal at runtime, before the output reaches its downstream destination.

Why does detection after the fact create risk in agentic systems?
Unlike traditional software, agentic systems act — they write to databases, send messages, trigger workflows. If detection fires after the action has been taken, the damage is already done. The enforcement window is between output generation and downstream action propagation, which in fast-moving agentic pipelines can be milliseconds.

How does LLM-as-judge evaluation fit into a fallback enforcement architecture?
LLM-as-judge is one signal among many that can trigger a fallback policy. It's useful for semantic quality assessment but has documented failure modes at scale. A robust enforcement architecture combines multiple signal types — groundedness scores, confidence percentiles, retrieval faithfulness — and applies policy logic across them, rather than treating any single evaluator as authoritative.

What hallucination rate should enterprise teams target in production?
Target is task-dependent. Enterprise chatbots running on general knowledge queries report approximately 18% hallucination rates in uncontrolled settings. RAG-governed systems in the same environments reduce that to 3–8%. High-stakes applications in legal, healthcare, and financial domains typically require rates below 1%, which is only achievable with retrieval governance, output validation policies, and human-in-the-loop escalation for edge cases.

Does adding an enforcement layer slow agents down significantly?
At Waxell's p95 latency of 0.045ms for governance evaluation, no. The latency penalty is imperceptible in real-time applications. The execution cost comes from human escalation paths — halt-and-escalate workflows add human review time, not compute time. Teams typically route only the traffic that fails quality thresholds through escalation paths, keeping the median latency profile unchanged.

Can these fallback patterns work with agents that use tool calls extensively?
Yes, but the enforcement point shifts. For tool-call-heavy agents, the most important interception point is the decision to call a tool based on a hallucinated premise — for example, an agent that queries a database with a fabricated entity name. Pre-execution policy enforcement, as in Waxell Runtime, checks the tool-call intent before the call is dispatched, not after the response is received.

Sources

1. EY 2025 Responsible AI Pulse Survey (August–September 2025, 975 C-suite leaders, 21 countries) — EY Global Newsroom

2. AI Hallucination Rates and Benchmarks 2026 — Suprmind AI

3. Arize Phoenix Hallucination Evaluator — Arize Documentation

4. LibreEval: Open-Source RAG Hallucination Benchmark — Arize AI

5. HN discussion: "Ask HN: How are you preventing LLM hallucinations in production systems?" — Hacker News