Evals before release: how to transform expectations into executable criteria

“The agent got better” is a feeling. “The agent resolved 18 of 20 critical cases, preserved the five negatives, and did not create prohibited effects” is a statement that can guide a release.

Evals transform product expectations into tasks, graders, trials and observable results. They do not eliminate uncertainty, but they prevent each change from relying solely on memory, demo, or confidence in the newest model.

Executive summary

Start evals before automating the entire flow.

A score is not total quality. It is evidence about defined properties.

Start with the product, not the metric

Before choosing framework, write:

• who uses the agent;
• what result you expect;
• that failure is unacceptable;
• that behavior is subjective;
• which state of the environment proves conclusion;
• what variation is tolerable;
• which decision the eval releases.

If two domain people disagree about what should pass, the problem is still in the specification.

Task success is not a single variable

An agent may produce the correct answer and violate policy. You may follow policy and not complete the action. You can complete and create rework later.

Separate dimensions:

gate may require all critical dimensions, not an average that compensates for security failure with good writing.

Choose grader by property

Code

Use test, schema, query, lint, or state inspection when the property is objective.

Model

Use rubric for aspects without deterministic checker, with examples and human calibration. A judge should not be given greater authority than the evidence he produces.

Person

Use expert when context, impact or subjectivity require judgment. Human review also calibrates automatic graders.

Combining layers is more robust than waiting for a universal checker.

Dataset is born from real work

A first suite can come from:

• frequent manual tasks;
• incidents and bugs;
• support tickets;
• cases that the team always demonstrates;
• adversarial inputs;
• decisions where the agent should escalate;
• cases in which he no should use a tool.

Don't just use happy examples. A one-sided suite teaches the system to always do what it should only do sometimes.

Capability and regression measure different things

• capability eval: What have we still not been able to do sufficiently?
• regression eval: What was already working and can't get any worse?

When a capability matures, its stable cases can migrate to regression. release needs to protect both directions: improve the frontier without losing ground.

Don't hide non-determinism

A successful attempt does not prove consistency. Rotate trials proportional to the risk and differentiate:

• chance of achieving at least one success in several attempts;
• chance of repeating success in all attempts;
• cost variance, steps and result.

An exploration tool can accept multiple attempts. An agent that performs financial effect may need much stronger consistency and gate.

Eligible eval and tracing sources support that baseline, outcome, and observability need to be calibrated by use case; they do not define universal FORGE thresholds. [R3-C1]

eval could also be wrong

Read traces and look for:

• ambiguous task;
• impossible reference;
• grader which penalizes valid solution;
• response leakage in context;
• dataset contaminated;
• different distribution of production;
• saturated score;
• encouragement to explore loophole;
• score improvement with worsening of outcome.

A eval is software and product hypothesis. It needs ownership, versioning and maintenance.

A simple gate of release

1. regressões críticas = 0
2. casos de segurança negativos = 100% bloqueados
3. capability alvo melhora sobre baseline
4. custo e latência dentro do budget
5. traces amostrados sem falha material nova
6. reviewer aceita os limites

The numbers above are framework, not universal thresholds. Each product defines risk and tolerance.

Evals do not replace production

Pre-release tests known scenarios. Production reveals real distribution, behavior change, integrations and effects that dataset did not anticipate.

Combine:

• evals offline;
• monitoring and traces;
• user feedback;
• controlled tests when there is traffic and base;
• periodic review of cases;
• incidents converted into regression.

If an incident does not change the suite or control, the system may repeat the failure in a different guise.

Evals accelerate model switching

Without a suite, a new model restarts the discussion via demos. With suite, the team compares in its own context:

• success by task class;
• consistency;
• total cost;
• latency;
• new failures;
• safety behavior;
• need for scaffolding.

The leaderboard informs possibility. The internal suite informs suitability.

What this article proves — and what it doesn't prove

Official sources and public practices support tasks, trials, graders, traces and signal combination. They do not prove that automated eval represents all product value, nor that LLM-as-judge is independent by definition.

This article offers a minimal design. Validity depends on the dataset, the environment, the reviewers and the decision linked to the score.

Conclusion

Evals makes expectations moot before release. They transform “looks best” into cases, properties, results, and limits that the team can review.

The goal is not to produce a pretty number. It is knowing what has changed, what has remained protected and what risk has not yet been measured.

Previous reading: The agent cannot be its own auditor. Next suggested reading: Design Partner is not a market.