15. Evaluating an Agent Beyond Its Final Answer

The task required reading a real directory, returning at most five entries, modifying nothing, and avoiding the network. An answer can invent five plausible names without reading. It can also be correct after an unauthorized request.

Text quality alone misses the defining runtime behavior.

Four metric layers

These do not collapse safely into one score. A correct answer with a security violation remains a constraint failure.

Fix the evaluation conditions

Comparison fixes task text, fixture snapshot, model and version, tool schemas, permission policy, network conditions, and maximum turns and budget.

The four captured CLIs used different models, protocols, and tools. Claude Code and Grok did not complete the primary request. The data supports structural comparison of observed traces, not an overall product ranking.

Deterministic graders first

Programs can check file existence, JSON structure, zero writes, event order, and call counts. Human or model grading is reserved for explanation quality and other properties without deterministic assertions.

A model grader records rubric, model version, prompt, and reasoning. Its score is a measurement with limited repeatability, not objective truth.

Failure cases are part of the benchmark

Success-only tasks never exercise the state machine, idempotency, or recovery path.

Efficiency is multidimensional

Codex used one compound Shell call; Kimi used two parallel calls. One boundary is not automatically better than two. Merging can hide partial failure; separation adds scheduling and context cost.

Efficiency includes end-to-end latency, model turns, Tokens, tool duration, and recovery cost.

Reports show distributions and failure traces

An average hides rare expensive or unsafe runs. Latency includes P50, P95, and maximum. Token reporting includes task total and per-turn growth. Constraint failures link to individual traces rather than only a percentage.

Each version comparison reports sample count, passes, non-comparable runs, and environment differences. A request stopped by account configuration is “not executed” for tool metrics, not a tool success or failure.

Thresholds depend on metric type

Security constraints use zero-tolerance gates: unauthorized writes and secret transmission must not occur. Performance metrics use bounded variance and distribution review. Model-graded metrics require human calibration so a grader upgrade is not mistaken for an Agent improvement.

Every summary metric drills down to trace, event, and grader evidence. Otherwise evaluation shows that a number changed without identifying the runtime layer responsible.

From one experiment to a regression suite

Every discovered failure becomes a case containing input, environment, expected events, and terminal state. Prompt, schema, model, and permission-policy changes rerun the suite.

The objective is not to prove permanent correctness. It is to measure which tasks improved, which constraints regressed, where failures stop, and whether recovery remains valid.

The packet capture has now become a runtime inspection framework. The system prompt is one input. Reliable Agent behavior comes from the closed loop of context, tool contract, permission, state, event trace, and evaluation.

Evaluate the model-runtime combination

Changing schema, permission, compaction, or retry budget changes results even with the same model. A report fixes model, runtime, tools, environment image, and budgets.

SWE-bench evaluates repository state with executable tests over 2,294 real GitHub issues. SWE-bench τ-bench compares final database state with a goal and uses pass^k to measure repeated reliability. τ-bench

Under ideal independence, success in all k runs is approximately p^k; actual Agent errors can be correlated, so repeat the runs directly. pass^k asks whether every run succeeds, unlike pass@k, which asks whether at least one attempt succeeds.

A correct end state can still involve irrelevant secret reads, skipped confirmation, or duplicate sends. Grade outcome, constraints, process, recovery, and efficiency separately before any aggregate score.

TUA-Bench, released in June 2026, contains 120 terminal tasks spanning documents, email, live web use, and scientific and engineering work with deterministic setup and execution-based grading. TUA-Bench Public benchmarks provide comparability; sanitized product tasks provide representativeness; failure and attack suites test runtime boundaries.