A dashboard tells you yesterday's error rate. A dashboard does not stop today's error.
Most AI evaluation products check a sample of answers, after the answers have already gone out, without stopping anything. Read their documentation and you find all three properties written down as features.
Mastra, a popular TypeScript agent framework, describes its scorers:
"Live evaluations run in the background without blocking your agent responses or workflow execution."
"The `sampling.rate` parameter (0-1) controls what fraction of outputs get scored."
In the background. Not blocking. A fraction of outputs. Set the rate to 0.1 and nine answers in ten reach your user with no score at all. The tenth gets a score after the user has already read the answer.
AWS offers online evaluation for agents on AgentCore, scored by language models acting as judges. The built-in judges come sealed:
"Built-in evaluator configurations, including their evaluator models and prompt templates, cannot be modified."
OpenAI's harness engineering team, writing in February 2026 about building a product with agents, stated the philosophy behind all of this more openly than anyone:
"The repository operates with minimal blocking merge gates."
"Test flakes are often addressed with follow-up runs rather than blocking progress indefinitely."
"In a system where agent throughput far exceeds human attention, corrections are cheap, and waiting is expensive."
I respect the candour, and for their case the trade holds. An internal product with fast rollbacks and engineers watching tolerates a bad merge. The cost of a wrong answer is one more pull request.
Change the setting and the arithmetic flips. A financial reconciliation. A medical billing claim. A security review saying no issues found. A wrong answer there is not cheap to correct, because by the time a sampled, asynchronous score arrives, somebody already acted on the answer. A dashboard tells you yesterday's error rate. A dashboard does not stop today's error.
So name what these tools are. Measurement. Good measurement, needed measurement. Not a gate. A gate sits between the answer and the reader, runs on every answer, and has the power to say no before anyone sees the answer.
Merlin's checks on the final answer are gates in exactly this sense. They run on every answer, and they block before delivery. The rule counting open tasks runs on every proposed final answer, not on a tenth of them. A citation pointing into a file the run never read fails the task close, every time, before the answer exists.
Blocking has a price, and I will not pretend otherwise. Our own gates have rejected correct work. In one run, our gate refused three correct Maven builds and one test run, each time with a message telling the model to run a build. The model concluded Maven was not installed, and the task closed without any build. A later post in this series covers the run, with the log. A wrong blocking gate is loud: you see the rejection, read the reason and fix the rule. A wrong sampled score is silent, and the answer already shipped.
The question to ask any vendor selling you AI quality: on what fraction of answers does your check run, and does a failed check stop the answer. If the answers are "a sample" and "no," you bought a dashboard.