Evaluate the work, not just the answer

A fluent response is a weak release gate

An assistant can produce a polished answer while reading the wrong record, overlooking a required exception, or making an unauthorized change. Evaluating only the final text misses those failures. For software that supports real operations, the test subject is the complete workflow: inputs, retrieval, decisions, tool calls, persistent changes, and the result presented to the user.

Two publications sharpen this distinction. Anthropic's January 2026 evaluation guide separates a transcript from the final state of the environment and describes several kinds of graders. AlphaEval, a research paper published in April 2026, proposes evaluation based on production requirements and complete agent products. These are useful design references, rather than universal performance guarantees. Their practical implication is to make the evaluation resemble the work the application is expected to do.

Start with a decision you need to make

An evaluation project becomes more focused when it answers a release question. Can a new model replace the current one for extracting structured fields? Does a retrieval change improve answers without exposing restricted material? Can the workflow complete a task with one fewer human checkpoint? Each question needs a different dataset and a different definition of an unacceptable result.

For a hypothetical document review assistant, separate factual extraction, interpretation, and action readiness. A date either matches the source or it does not. A recommendation may admit several reasonable answers. Permission to send that recommendation is another test entirely. Combining these into one score makes it possible for strong writing quality to hide a serious operational defect. Preserve the separate dimensions even when executives need a compact dashboard.

Build a small suite with deliberate coverage

A useful first suite should include common work, important exceptions, and cases where the correct behavior is to stop. Use realistic structures without unnecessarily retaining sensitive production content. For every case, record why it exists and what behavior it is meant to protect. This allows reviewers to distinguish essential coverage from examples that have become obsolete after a product change.

Include ambiguity intentionally. If two customers have similar names, a successful run may ask for clarification. If the available evidence conflicts, a successful run may return a qualified answer. A dataset that rewards completion in every case can teach a team to optimize away appropriate restraint. Reserve a portion of cases from routine prompt tuning, and periodically add fresh examples so the suite does not become a script the system has effectively memorized.

Use the simplest reliable judge

Use deterministic checks for things the application can verify directly: schema validity, correct record identifiers, required fields, permitted tool calls, and committed state. Use human reviewers when quality depends on domain judgment. A model judge can help scale a carefully defined rubric, but validate its disagreements against human decisions before making it a release gate.

Repeat selected cases to expose variability. A workflow that succeeds once and fails on the next attempt has a different operating profile from one that consistently asks for help. Keep the evaluation environment controlled enough to diagnose change, and record dependencies that may affect the result. When a test fails, make it easy to inspect the relevant evidence rather than requiring someone to read an entire conversation.

Document disagreements between reviewers. If two experts reach different conclusions, resolve the underlying requirement before encoding either answer as ground truth. Sometimes the right evaluation accepts several outcomes, provided each is supported by evidence. This work also improves product requirements: ambiguity discovered in a test is usually cheaper to address than ambiguity discovered after users have relied on the result.

Turn results into release policy

Set thresholds by consequence. A minor formatting defect may be acceptable during an experiment; disclosure of another customer's information should block release. Track latency, operating cost, and intervention alongside quality, because an improvement that doubles review effort may not improve the product. Compare versions on the same cases before attributing differences to a model or prompt.

After release, use production observations to improve the suite. A recurring user correction should become a candidate case, with appropriate privacy handling and a clearly stated expected outcome. Keep the process owned: someone must decide whether a failed check reflects a product defect, a flawed test, or a changed requirement. Evaluation becomes valuable when it changes decisions. A score that nobody uses to approve, stop, or revise a release is merely an expensive report.