Agent evaluation

Agent evaluation tests an agent against a defined task and standard of success. Because an agent can act over multiple steps, evaluation may need to examine both what changed in the environment and how the system got there. AgentBench is a research example built around interactive environments and the reasoning and decisions needed to operate within them. Its benchmark results describe the evaluated setups, not a general certificate of competence. 1

Define what success means

OpenAI’s evaluation guidance recommends defining an objective, selecting a dataset, choosing metrics, comparing runs, and continuing evaluation as the application changes. It also recommends calibrating automated metrics against human judgments. This is vendor guidance for development practice. It does not show that any particular dataset or automatic judge is sufficient for a different application. 3

For an original encyclopedia example, a task could be: correct a protocol explanation using the supplied authoritative revision, while preserving the article’s history. “The final paragraph sounds convincing” would be an incomplete criterion. A test could inspect whether the claim matches the revision, whether the source link resolves to the intended evidence, and whether the previous version can still be recovered.

Those criteria would need a declared environment: which source snapshot is available, what tools may be used, which article revision is the starting point, and what stopping limits apply. This proposed example would keep that information with the test result. Otherwise, a change in the source or starting state could be confused with a change in agent behavior.

Outcome and interaction are different evidence

τ-bench combines simulated user conversations, API tools, domain policies, and annotated goals. Its evaluation compares the resulting database state with the expected state, with additional output checks where specified. It illustrates why a final conversational message alone may not establish task completion. Its users are model simulations, so the study should not be described as observing real customers. 2

For the correction example, a claim that an edit succeeded would need a corresponding artifact or state change. An interaction record could also reveal that the agent read the wrong source, repeated an operation, or exceeded its allowed scope despite eventually producing an acceptable paragraph. These are separate questions the proposed test would inspect; the benchmark citation does not establish that this site already inspects them.

Averages can hide inconsistency

τ-bench distinguishes success at least once across repeated attempts from success on every attempt in a set of trials. Its pass^k metric measures the latter, averaged over tasks. This is different from pass@k, which concerns finding at least one successful attempt. Neither metric alone captures every aspect of an application, and trial counts and conditions need to accompany any reported result. 2

In the illustrative correction task, repeated runs could expose inconsistent citation choices. A report would distinguish the proportion of successful runs from a selected best run. It would also record incomplete or stopped runs rather than silently excluding them. No benchmark statistics or performance claims for this encyclopedia are supplied here.

Design cases that expose a boundary

The example would include a missing source, a source that contradicts an earlier article, and a request that cannot be completed within its limits. Memory would need a case where an old conclusion has been superseded. Retrieval-augmented generation would need to distinguish finding evidence from accurately using it. Prompt injection would add an untrusted instruction within a document.

A source can be unavailable without the correct behavior being to invent a replacement claim. In that case, an explicit unresolved outcome could be the expected result. Defining such outcomes before running the example would make the evaluation more informative than judging the answer’s tone afterward.

Read a result with its scope

AgentBench’s interactive tasks and failure analysis make the environment part of the result. A score from those tasks cannot establish performance on all orchestration designs or tool permissions. 1 For the encyclopedia example, a reviewable report would therefore name the tested configuration, the task set, the observed failures, and what remains untested. Passing that report’s tests would support a bounded conclusion about those tests, while broader factual and operational claims would still need their own evidence.