A run without errors is not a correctly handled case

A clean run with the wrong result

Take a hypothetical claims-intake agent. The trace shows three successful tool calls: it looked up the policy, created the claim and sent the customer a confirmation. No errors, normal latency, normal token use. The customer, however, holds two policies, the lookup returned the first match, and the claim now sits on the household policy instead of the car policy.

Every technical signal is green, and the agent's own summary says the claim was registered. Arize's guide to agent evaluation makes the point directly: outcome checks should read the actual system state, not the agent's confirmation message. The confirmation is something the agent produced, so it cannot be the evidence that the agent was right.

Three questions with different evidence

Anthropic's guide to agent evals separates the transcript, meaning the record of outputs, tool calls and reasoning, from the outcome, meaning the final state of the environment, such as whether a reservation exists in the database. For a process agent that gives three separate questions:

• Run health: did the run finish, which calls failed, how long did it take and what did it cost? The evidence is spans and metrics
• Path: did the agent stay within the allowed steps, ask for approval where required and avoid loops? The evidence is the trace
• Outcome: is the resulting state of the business records correct for this case? The evidence is a query against the system of record after the run

Monitoring limited to run health, errors and latency answers the first question well and the third not at all. Outcome checks can feed the same telemetry and alerts; the gap lies in what is instrumented. Process owners care mainly about the third.

Writing an outcome check for a case

1. 1

   State the expected end state

   Describe it in terms of records, not actions: one claim exists, linked to policy P-2, with damage type storm and status awaiting assessment.

2. 2

   Read the system of record

   After the run, query the claims system directly with credentials the agent does not use. Do not reuse the tool output the agent saw.

3. 3

   Check what must not have changed

   No second claim, no change to the customer's address, no message to anyone other than the policyholder.

4. 4

   Score parts separately

   Right policy, right damage type and right status are separate checks. Anthropic recommends partial credit for multi-part tasks, which also shows which part fails most often.

What the trace is still good for

Grading the outcome does not make traces less important. When an outcome check fails, the trace shows where the case went wrong: an ambiguous lookup result, a tool argument the model invented or a document it never read. The OpenTelemetry semantic conventions for generative AI describe spans such as invoke_agent and execute_tool with attributes like gen_ai.tool.name and error.type. They are still marked as Development status, but they give different frameworks a shared shape for this data.

Some path rules are also hard requirements. If policy says a payout needs approval first, a correct payout without approval is still a failure. Anthropic warns against grading a fixed sequence of steps because it penalises valid alternatives; Arize suggests checking the requirements every valid path shares. In practice, write path checks only for the rules that are truly mandatory and leave the rest to the outcome.

Reading outcome and trace together

• Right outcome, compliant path: the case passes
• Right outcome, rule broken on the way: a failure, even though the record looks fine
• Wrong outcome, clean run: the most dangerous combination, because error and latency alerts stay quiet. Look at tool data, ambiguous inputs and the model's reasoning
• Wrong outcome with errors in the run: usually a recovery problem, where the agent carried on after a failed or partial tool result

Report the third group as its own number. It is the share of cases that dashboards limited to errors and latency cannot see, and the one outcome checks are there to catch.

When the outcome is hard to check

Not every result is a field in a database. A reply to a customer, a summary for an assessor or a payment that settles days later needs another approach. Delayed outcomes need a second check scheduled after the effect should have landed. Text needs a rubric, graded by a calibrated model judge or by people. Anthropic suggests giving model judges an explicit option to answer unknown and checking them against human experts.

A useful first exercise: take twenty recent runs that show no errors, check each outcome by hand against the system of record, and count how many were wrong. That number tells you whether outcome checks are a priority.