A useful natural-language failure rule names the required behavior, when it applies, and the evidence that can prove a violation. “The agent should be helpful” is too broad. “When a customer requests cancellation, do not claim it is complete unless the cancellation result confirms completion” is a rule a reviewer can inspect.
Natural-language rules are valuable when the behavior varies across conversations. Their flexibility also makes vague definitions expensive: they generate findings that people cannot agree on.
Start with an observable obligation
Write the rule as four parts: scope, obligation, evidence, and exceptions. For example:
Scope: customer requests cancellation of an active subscription.
Obligation: describe cancellation as complete only after a matching
subscription result confirms the required terminal state.
Evidence: customer request, subscription identifier, tool result,
and the assistant's completion statement.
Exceptions: a pending request may be described as submitted, not completed.
Unknown: required action evidence was not captured.This is a proposed rule specification for your team. Whether a product can evaluate every field depends on the evidence it receives and the rule engine it exposes.
In Agnost, the Violations guide describes rules for expected behavior and reviewing the supporting conversation evidence. It explicitly distinguishes a classified finding from enforcement. Critical authorization checks still belong in application code.
Rewrite vague rules before collecting alerts
| Vague instruction | More useful rule | Evidence required |
|---|---|---|
| Do not hallucinate | Return-window claims must match the applicable retrieved policy | Policy version, applicable context, answer |
| Do not waste tools | Flag repeated successful reads of unchanged data without a new purpose | Inputs, scope, results, timing |
| Escalate correctly | After an explicit transfer request, either initiate an available transfer or explain why it cannot be completed | Request, transfer state, final response |
| Follow policy | State the required cancellation terms before asking for final confirmation | Current terms and ordered messages |
The rewritten rules are deliberately narrower. Separate them instead of building one giant “quality” rule whose score mixes cost, accuracy, politeness, and tool execution.
Include counterexamples in the definition
A customer might ask, “Can I cancel next month?” That is not necessarily an instruction to cancel now. A repeated search may be justified because the customer changed countries. A transfer may be unavailable outside operating hours.
Collect these near misses before enabling alerts. Ask two reviewers to label a small set independently, then discuss disagreements. If they disagree because the product policy is unclear, repair the policy first. An evaluator cannot make an ambiguous business decision consistent by itself.
Preserve cases where evidence is missing. Forcing every run into pass or fail hides instrumentation gaps and creates false certainty.
Version the rule like application behavior
Save a rule identifier, definition, owner, effective date, and labeled examples. When you change the wording, run both versions against the same review set. A lower violation count after a rule edit is not evidence the agent improved.
For each finding, retain the rule version and the smallest evidence excerpt needed to support it. If the finding depends on tool state, include that state rather than asking reviewers to infer it from a fluent answer.
Alert thresholds should reflect severity and volume. A rare incorrect external action may require immediate review. Repetitive phrasing may be better summarized in a weekly quality review. Avoid sending every low-confidence classification to an on-call engineer.
Measure usefulness to the reviewer
Track confirmed findings divided by reviewed findings, plus missed failures from a separate sample. Review time also matters: a precise label with no useful evidence can take longer to investigate than a narrower rule with a clear record link.
This approach is consistent with defining measurable criteria before evaluating an application, as described in Anthropic’s evaluation guidance. The particular rule templates here are our suggested implementation method, not a universal scoring standard.
Start with one failure that already costs your team time. For an action claim, use the false-success guide. For repeated lookups, use the duplicate-call guide. A rule earns its place when it finds a problem you can verify and act on.