Two booking changes with the same answer
“Your booking has been moved to Friday” does not show whether an agent checked the right conditions, touched someone else's booking, or successfully saved the change. Those questions require evidence beyond the final response.
This hypothetical evaluation example is not a product measurement. A verified customer requests a change to booking R42. The service requires approval of the new time and price before saving. Two runs produce the same final booking state and answer.
- Run A retrieves the booking, presents availability and price, obtains approval, and saves.
- Run B retrieves the booking, checks availability and price, saves, and then requests approval.
Run B violates the service's approval order even though its answer and final state are correct. Detecting this requires a check of approval before saving in addition to response quality.
Recording events and judging them are separate jobs
OpenAI Agents SDK tracing records events including generation, tool calls, handoffs, and guardrails. A separate rule must establish which recorded behavior fails. Tracing documentation
For the booking case, connect the run ID, booking ID, lookup result, proposed change, approval target, save request, and save result. Pass the approval condition only when the approved content matches the saved content and approval precedes saving. Missing approval evidence should trigger investigation rather than an assumption of permission.
Final-state checks serve another purpose. The τ-bench research evaluates task completion by comparing the final database with an annotated goal state. τ-bench A booking evaluation can similarly inspect test data to confirm the intended reservation changed and unrelated reservations did not.
Incomplete logs cannot prove the absence of prohibited actions. Connect tool execution records to the business system's change history, and decide how to retain the necessary evidence without storing excessive sensitive data.
Allow valid alternative paths
Making Run A's exact sequence the only acceptable path can reject a necessary repeat lookup. If the price changes, presenting it again and obtaining renewed approval may still satisfy the service's conditions.
AWS AgentCore documentation distinguishes exact tool-sequence matching, matching in order with additional calls, and matching without order. Ground truth evaluations The business requirement determines which is appropriate. Approval before saving requires order; two independent reads may not.
Tool names alone also cannot detect a save directed to the wrong booking ID. Combine ordering checks with checks of arguments and saved state. When a model judges the usefulness of the response, do not allow a high aggregate score to cancel an explicitly detectable violation.
Compare changes against the same cases
Include rejection, changed prices, missing permissions, and interrupted save responses alongside normal booking changes. For an interrupted response, check whether the agent resends before establishing if the first save succeeded. Run old and new versions with the same initial data to distinguish improved answers from worse actions.
Report response quality, saved state, prohibited actions, and missing evidence separately. Track latency and cost as additional measures. Repeat runs to test whether success depends on a fortunate attempt; τ-bench likewise distinguishes reliability across trials from success once.
Convert new production failures into reviewed, anonymized reproduction cases. Passing the accumulated tests cannot guarantee safety in unrepresented situations. Connecting evaluation to execution records makes it possible to explain which business condition a particular change broke.