Test decisions with Evals

Overview

Evals answer: At this exact moment, does the agent make the right next decision?

An Eval provides a mock conversation state, lets your assistant or squad respond at selected checkpoints, and judges the result. Use Evals for decisions such as whether to ask a question, call a tool, transfer a caller, refuse a request, or give a specific kind of answer.

Evals are path dependent: the messages before a checkpoint establish the exact situation being tested. Use Test outcomes with Simulations when you care about the result of a complete conversation and want the caller and agent to reach it through different valid paths.

Test decisions that matter

Focus on decisions that are frequent, hard to reverse, or costly when wrong, such as:

• Collect missing information: Ask for the caller’s timezone before booking.
• Use tools correctly: Send the agreed date and time to the booking tool.
• Follow access and policy rules: Require identity verification before sharing account details, and refuse requests to bypass it.
• Handle tool failures: Explain that a booking is not confirmed when the tool returns an error.
• Transfer callers: Route a billing dispute to the Billing team.

Start with a narrow question. “Does the agent handle appointment booking?” is too broad for one checkpoint. “After the caller provides all required details, does the agent call the booking tool with the agreed time?” is specific enough to diagnose.

Provide only the context the decision needs

Build the mock conversation up to the moment just before the decision. Include relevant user, assistant, system, and tool messages so the agent sees the same facts and constraints it would have at that point in a real call.

Include:

• Facts already provided by the caller.
• Questions the agent already asked.
• Applicable policy or system instructions.
• Tool results the agent must interpret.
• Any unresolved ambiguity that should affect the next action.

Remove unrelated turns. Extra context makes the reason for a failure harder to understand and can accidentally change the behavior under test.

Test both sides of the boundary

For every important action, test when it should happen and when it should not. This prevents a prompt change from fixing missed actions by triggering the action everywhere.

For an appointment-booking agent, a useful group of Evals looks like this:

Add cases close to the boundary, not only obvious examples. Ambiguous dates, partial account details, similar tool names, and conflicting requests often reveal more than another straightforward happy path.

Choose the simplest judge that fits

Evals support exact matching, pattern matching with regular expressions (regex), and AI judges. Exact checks can also validate tool calls and their arguments.

Use exact response text only when the wording itself is a requirement, such as a mandated disclosure. For most customer-facing replies, judge the meaning so harmless wording changes do not break the test.

Give an AI judge one clear pass/fail question. For example:

Pass only if the assistant says the appointment is not yet confirmed and gives
the caller a clear next step. Fail if it implies that the booking succeeded.

Avoid broad criteria such as “The response was good.” If you care about correctness, policy compliance, and tone, use separate checkpoints or checks so the failure remains actionable.

Test an AI judge against responses that informed reviewers agree should pass and fail. If the judge disagrees, refine its criterion before using it as a release check.

Keep each Eval focused

A mock conversation can contain more than one checkpoint, but each checkpoint should test one decision. Give the Eval a name that states the condition and expected behavior, such as:

• asks for timezone before booking
• does not refund an ineligible order
• transfers urgent safety concern to specialist
• does not confirm after booking tool error

Focused Evals are easier to review, reuse, and update. They also make it clear whether a change improved one decision while breaking another.

Turn real failures into regression tests

When a production call contains a wrong decision, use the relevant messages to create an Eval. End the mock context immediately before the mistake, then define the correct next action.

After the first Eval reproduces the failure:

Do not copy the entire call unless every turn is needed. Preserve the facts that caused the decision and remove customer data that the test does not require.

Review failures before changing the agent

A failed Eval can mean the agent made the wrong decision, but it can also mean the mock context was incomplete or the judge was too strict. Review the actual response and ask:

• Did the agent have all the information needed to pass?
• Would two reviewers agree with the expected decision?
• Did an exact or regex check reject a valid response?
• Does the AI judge describe one objective clearly?

Fix the test when it does not represent the intended situation. Fix the agent when the failure is fair. Keep the expected decision stable unless the product or policy requirement changes.

Avoid common pitfalls

Next steps