Evaluating AI agents: a successful tool call is not a finished job

The search succeeded, but the answer belonged to a different device

A colleague asks an AI for a device's maintenance deadline. The AI calls document search, opens material containing a deadline, and returns a date with a citation. Suppose the material describes an older model. The search log shows success, but the colleague's question remains unanswered. This is a hypothetical example for examining evaluation.

Tool use creates failures that the appearance of an answer cannot reveal. An agent may select the right function with the wrong arguments, retrieve the correct material but miss a condition, or complete several actions without saving the result. A single label of “agent failure” does not identify what to repair.

Research available by January 1, 2025 supplied components for measuring these distinctions. ReAct and Toolformer address action selection and use of observations; WebArena, SWE-bench, and OSWorld address completion within an environment. Our conclusion is to compare agents through jobs with inputs, actions, and evidence of completion, rather than capability lists. These sources do not establish a simultaneous market-wide transition.

Separate obtaining external information from using it

ReAct version 3 interleaves reasoning traces and task-specific actions, using observations to select subsequent actions. Its question-answering setup includes Wikipedia search, lookup within pages, and committing to an answer. Applied to our hypothetical example, this provides a place to decide to search another document when the first lacks a required condition.

External search does not improve every task automatically. In the paper's comparison using the same PaLM-540B model, HotpotQA exact-match accuracy was 27.4% for ReAct and 29.4% for chain-of-thought prompting (CoT). FEVER fact-verification accuracy reversed the order: 60.9% versus 56.3%. Different tasks and measures cannot be reduced to a single advantage from search access.

The first Toolformer paper proposes self-supervised learning from a small number of demonstrations to decide which API to call, when, with which arguments, and how to use the result in subsequent generation. Its tools include calculation, question answering, search, translation, and a calendar. Where ReAct addresses the reasoning-observation loop, Toolformer addresses incorporating calls into learning.

Together they motivate examining tool selection, arguments, and interpretation of results separately. A search response does not establish a matching model number or incorporation of the deadline's conditions. Read intermediate records to locate where a condition was lost, rather than simply to admire a fluent explanation.

Measure web work by its final state, not its number of clicks

WebArena version 2 evaluates functional completion across long action sequences in working websites for e-commerce, forums, collaborative software development, and content management. It provides an environment for relating individual abilities, such as opening a page or entering text, to completion of a whole task.

That version reports 14.41% end-to-end success for its best GPT-4-based agent and 78.24% for humans. These are results for the tasks, environment, and agent configuration at that time, not for current models or an organization's website. They reveal a gap worth measuring between convincingly interpreting a request and completing the specified work.

In a hypothetical internal ticket-registration task, text entered into a form differs from a correctly saved record for the intended case. Successful submission to the wrong destination could be counted as an operational success while missing the error. Defining the final-state check first clarifies both the necessary actions and the information that must be read along the way.

Code and screen operations need different completion checks

The first SWE-bench paper collects 2,294 problems based on real GitHub issues and corresponding fixes across twelve Python repositories. A model receives a codebase and problem description and edits relevant files. Evaluation checks that previously failing tests pass and previously passing tests continue to pass.

This separates plausible code from fixing the problem while preserving existing behavior. Passing the selected tests still does not establish every unmeasured quality or operational requirement. Use tests as evidence for an artifact while retaining the scope they actually check.

The first OSWorld paper provides 369 tasks involving web and desktop applications, file operations, and workflows across applications, with initial-state configuration and execution-based evaluation scripts. Its environment supports Ubuntu, Windows, and macOS; support does not mean equivalent performance was measured on every operating system. Saved files and application state require checks different from code tests.

For a hypothetical document task, seeing a table on screen is insufficient if the required values were not saved to the specified file. Conversely, some jobs can succeed with a slightly different appearance if the requested data is correctly retained. The checker should match the person's desired result, making one score for all agents difficult to interpret.

A common experiment interface does not make tasks identical

The first BrowserGym paper puts multiple web-agent benchmarks under common observation and action formats, using AgentLab for experiment management and analysis. It addresses the difficulty of tracing comparisons across fragmented execution systems.

A shared format makes it easier to compare models, exposed information, permitted actions, and trial settings. Yet answering an information question and updating a record still have different meanings of success. A common action interface does not produce a ranking applicable to every business task.

For the maintenance example, fix the document-search method, answer construction, and source versions when comparing alternatives. Changing the material and time limit along with the model makes improvement harder to attribute. Measurability includes both a repeatable environment and records explaining which conditions changed.

Product building blocks help implement the job being evaluated

AWS's April 2024 Bedrock Agents update describes defining functions and parameters and returning control to the calling application. The model can select an operation while an existing application performs it. This is a product example of separating action selection from the place where execution occurs.

Google's Vertex AI Agent Builder announcement combines building capabilities including search and conversation. Claude's May 2024 tool-use announcement likewise connects natural-language requests to defined tools and APIs. These are implementation choices, rather than measurements proving the user's job succeeded.

For the hypothetical deadline question, define the searchable documents and returned fields, then implement their use in an answer. Retrieving the correct material, applying it to a contract, and returning the correct date each need checks. When choosing building tools, examine where those checks can run as well as how many functions can be added.

Anthropic's agent design guide distinguishes workflows following predefined paths from agents whose models select the process. If the material and sequence are fixed, choosing actions freely each time may offer little benefit. Compare a simple design against the requirements and measure the time and failures introduced by additional flexibility.

A deadline-answering task also needs conditions for returning unknown

Apply the research to a scorecard for the opening example. Include the device model and contract in the input and define accessible document repositories. A deadline in a document is not final until its applicability to that model, contract, and period is verified. The following is our evaluation proposal, not a product deployment result.

Include changed model numbers, updated deadlines, and missing contracts alongside answerable cases. Always returning “unknown” can reduce wrong answers while leaving the colleague's research burden intact. Record the fraction answered under the conditions, evidence mismatches, and returns to review separately.

Also measure calls, waiting time, and the person's repeat research. More correct answers save little work if the colleague must reread every document each time. Compare whether the response lets a person verify the necessary passage and applicability conditions using the same set of questions.

Legible failures make the next improvement possible

The period's sources address different problems: selecting actions, measuring completion in real environments, and constructing executable jobs. Rather than claiming one method solves them all, the useful conclusion is to connect those layers in evaluation. Compare jobs for which a team can explain where a condition was lost, what state remained, and what a person had to check again.

The colleague in the opening example needs an applicable maintenance deadline and its evidence more than a report that search succeeded. If the deadline cannot be established, they need to know what to verify next. Designing an agent as measurable work means locating failures that can be repaired and helping the person use the result they delegated.