Is this just a unit test for prompts?

It is similar in intent, but broader in mechanism. A unit test usually checks a precise output from deterministic code. A blocking eval checks behavioural properties of a probabilistic system: correctness, refusal, formatting, tool use, or absence of a known regression. Some cases can be deterministic, while others need rubric scoring or a judge.

Should an LLM judge be allowed to block a deployment?

It can, but only when its rubric, examples, and failure output are explicit enough for engineers to review. Deterministic assertions are preferable where possible. Use a judge for qualities that are hard to encode, such as answer relevance or policy compliance, and monitor it like any other dependency that can drift.

What should go into the first blocking eval suite?

Start with known production failures, important happy paths, and cases where the agent can cause harm or confusion. Keep the suite small enough that developers read failures rather than bypassing them. Version the inputs, expected behaviour, judge prompt, scoring rule, and threshold with the agent changes they are meant to protect.

eval that blocks a deploy

An eval that blocks a deploy is a CI gate that runs behavioural tests against an agent, prompt, tool setup, or model configuration and fails the release when agreed quality rules are not met. It turns subjective prompt confidence into an automated release condition, similar to unit or integration tests.

The problem is that agent behaviour often changes without normal code visibly changing. A prompt edit, retrieval tweak, tool description, or model setting can make an agent stop refusing unsafe requests, call the wrong tool, or regress on cases that previously worked. Ordinary unit tests usually cannot express those expectations well, because the question is not just whether a function returned a fixed value, but whether the system behaved acceptably.

In practice, the team stores eval cases alongside the prompt or agent code. Each case contains an input, any setup state, expected properties, a scoring method, and a pass rule. CI runs the agent against those cases on a pull request or deploy path. Some checks are assertions, such as valid JSON or a required tool call. Others use rubrics, golden examples, or an LLM judge. The build fails if the result crosses the configured boundary.

The trade-off is that blocking evals add latency, maintenance, and judgement calls to delivery. They can be flaky if the model, judge, data, or environment is unstable. They can also create false confidence if the suite only covers easy happy paths. The honest answer on thresholds is that it depends on the risk of the feature, the stability of the eval, and the cost of a bad release.

Engineers meet this in GitHub Actions, other CI systems, deployment pipelines, and model-adjacent release tooling. A good job uploads enough evidence to debug a failure: the prompt version, inputs, outputs, tool traces, judge rationale, and scores. The common misunderstanding is that evals must be perfect before they can block. They do not. They need to be narrow, explainable, versioned, and trusted enough to prevent known regressions.

Go deeper

Agents & MCPThe eval that blocks a deployWire evals into CI so a prompt change cannot ship on a hunch.Open the lesson

Common questions

Is this just a unit test for prompts?: It is similar in intent, but broader in mechanism. A unit test usually checks a precise output from deterministic code. A blocking eval checks behavioural properties of a probabilistic system: correctness, refusal, formatting, tool use, or absence of a known regression. Some cases can be deterministic, while others need rubric scoring or a judge.
Should an LLM judge be allowed to block a deployment?: It can, but only when its rubric, examples, and failure output are explicit enough for engineers to review. Deterministic assertions are preferable where possible. Use a judge for qualities that are hard to encode, such as answer relevance or policy compliance, and monitor it like any other dependency that can drift.
What should go into the first blocking eval suite?: Start with known production failures, important happy paths, and cases where the agent can cause harm or confusion. Keep the suite small enough that developers read failures rather than bypassing them. Version the inputs, expected behaviour, judge prompt, scoring rule, and threshold with the agent changes they are meant to protect.

Every term