Suppose a product presentation claims 85% autonomous completion. This is an illustrative score, not a reported benchmark result. Before deciding whether it is impressive, ask what happened inside the successful group as well as the remaining 15%. Did the service complete the requested work, satisfy its permissions and leave a recoverable record? A system that avoids asking for help may look autonomous while moving unresolved work to somebody else’s queue.
A completion percentage can be entirely accurate and still answer the wrong deployment question. The benchmark may test a fixed set of instructions in a controlled environment. The buyer may need a service that recognizes missing authority, preserves records and hands unusual cases to someone else. Neither is an unreasonable objective. The mistake is treating them as the same objective without examining the test.
The distinction is especially important for AI agents because their outputs can be changes to a system rather than sentences about it. A convincing final message can accompany an incorrect database update. A correct update can accompany a misleading explanation. An evaluator interested in the real outcome needs to inspect both, with success conditions defined before seeing the result.
Read the label beneath the score
WebArena, introduced in 2023, built reproducible web environments and evaluated functional task completion. OSWorld, introduced in 2024, provided computer tasks with setup configurations and execution-based evaluation across applications. Their importance here is methodological: they make the environment and resulting state part of what is tested. Their early baseline scores should not be presented as measurements of today’s leading systems.
A reported result still depends on the configuration around the model. Which tools were available? Could the agent use a direct API or only a visual interface? How many steps and how much time were allowed? Was it given a prepared account and a clean starting state? Changes to those conditions can make two apparently similar percentages measure different opportunities to succeed.
The unit of observation also matters. A single action, a complete task and a sequence of tasks performed over a day have different boundaries. If an agent successfully opens a record but fails to save the required edit, an action-level measure may record progress while a task-level measure records failure. Neither count should be relabeled to resemble the other.
Human assistance belongs in the label. A result obtained with an operator selecting the best plan or repairing intermediate errors can demonstrate a useful assisted workflow. It does not establish unassisted performance. Omitting the operator’s contribution can make both the automation and the work required to use it difficult to assess.
Unpack a workflow rather than multiply a headline
An ordinary connected task might require finding the right record, interpreting a policy, checking permission, making a change and confirming the result. Each step introduces a possible failure. A strong ability to interpret instructions does not guarantee correct record selection, and reliable record selection does not guarantee that the final external effect was completed exactly once.
There is a tempting piece of arithmetic: if five independent steps each succeed 95% of the time, the chance that all five succeed is about 77.4%, because 0.95 raised to the fifth power is approximately 0.774. This is an illustrative mathematical model, not a measured estimate for an AI product. Real errors may be dependent, steps may recover and workflows may branch.
Its useful lesson is to ask about the whole chain. One failure can prevent the requested outcome even when most actions looked good. But simply multiplying unrelated benchmark accuracies is not a legitimate way to predict deployment reliability. The probabilities would need compatible definitions and evidence for their relationship. A neat calculation cannot supply those assumptions.
Recovery changes the chain too. A tool may fail temporarily, after which the agent retries successfully. A retry may also repeat an action that actually completed despite a lost response. The evaluator should distinguish a failed attempt followed by a correct outcome from a duplicate external effect. Counting tool calls alone reveals neither.
Two fictional systems take the same hundred requests
Now replace the large percentage with a deliberately invented evaluation. There are one hundred requests. Seventy can be completed under the test’s operating rules. Thirty require a human handover because necessary authority or information is missing. This distribution is chosen to explain the measurement problem; it is not a claim about typical customer service.
System A completes sixty-five requests correctly, completes five incorrectly and hands over thirty. System B completes sixty-eight correctly, completes seventeen incorrectly and hands over fifteen. In this example, all of A’s handovers are the required ones; B hands over fifteen required cases and mishandles the other fifteen. Neither system has silently solved an exception that the rules say it cannot.
| Outcome in this illustrative test | System A | System B |
|---|---|---|
| Correct autonomous completion | 65 | 68 |
| Incorrect autonomous completion | 5 | 17 |
| Correct human handover | 30 | 15 |
| Total requests | 100 | 100 |
If autonomous completion means any case the system closed without a person, A scores 70% and B scores 85%. If correct handling includes the required handovers, A handles 95 requests appropriately and B handles 83. B delivers three additional correct autonomous completions alongside twelve additional errors. The trade-off is visible only after the outcomes are separated.
There is no universal price for those errors. A reversible formatting mistake and an unauthorized disclosure have different consequences. The organization needs to define error categories and acceptable treatment before turning the table into a purchasing decision. A weighted score can help summarize a chosen policy, but the weights are judgments that should remain inspectable.
Nor does the example prove that conservative systems are always preferable. An assistant that hands every request to a person would preserve some boundaries while providing little automation. Appropriate escalation is useful when it identifies a real limit. Unnecessary escalation creates work and delay. The evaluation needs both kinds of case instead of rewarding either maximal confidence or maximal refusal.
Run it again without selecting the best take
One successful run does not establish consistent performance. The same request can produce different paths on different attempts. A product used repeatedly has to be assessed with that variation in mind, particularly when a rare error carries a significant cost. Replaying the task once after a failure and reporting only the successful replay changes the meaning of the result.
The June 2024 tau-bench paper makes that distinction explicit. Its pass@k asks whether at least one of k trials succeeds; pass^k asks whether all k succeed, averaged across tasks. A service promising repeatable handling needs the second question as well as the first. These definitions describe the benchmark, not a score for current products.
The paper also exposes a limit of checking the final state. Its simulated retail rules require confirmation before a return. Yet the authors acknowledge that the reward can count a run as successful even if the agent omits that confirmation: the database and required response information may still match. The evaluator’s success flag is therefore necessary but not sufficient for compliant handling in their example.
That is a sharper procurement question than asking for one more leaderboard result. Which obligations does the automatic checker actually observe? Where a step needs consent, the audit must inspect the conversation and action sequence as well as the saved record. Otherwise a team could optimize a genuinely reproducible score while leaving the unmeasured obligation unresolved.
An evaluation report should disclose the number of attempts, the selection rule and any human intervention. If the system is allowed to try several plans and select one, that can be a legitimate operating design. It needs a way to identify success, an account of total cost and a comparison under equivalent conditions. The best take should not masquerade as the only take.
Repeated tests should reset what needs resetting. A record altered during an earlier attempt can make the next task easier, harder or simply different. Accounts, caches, documents and application state all deserve attention. Reproducibility depends on restoring the relevant conditions rather than only copying the same natural-language instruction into a new chat.
The handover has an outcome of its own
Escalation is not complete when the agent writes ask a person. A usable handover identifies the unresolved question, preserves relevant work and routes it to someone able to act. The person should not have to reconstruct the entire interaction from an unstructured transcript. A system that refuses safely but loses all context can still create a poor service.
Timing matters as well. A correct handover after a long sequence of unnecessary attempts may consume more staff attention than an earlier, well-identified limit. That does not justify skipping an essential check. It suggests measuring how the system recognizes the boundary and what useful information it passes onward, rather than treating all escalations as a single undifferentiated failure count.
The receiving workflow needs capacity. If a service automates routine work but sends exceptions to a queue nobody monitors, its apparent productivity can coexist with unresolved users. The evaluation should follow those cases far enough to show what the operating arrangement actually delivers. A successful AI component does not by itself establish a successful end-to-end service.
Test what changes after launch
A controlled benchmark can provide a stable comparison precisely because it limits variation. A live application changes: interfaces move, policies are revised, accounts expire and data takes unfamiliar forms. A deployment test should include the variations relevant to its use without pretending that a small test can enumerate every future situation.
Record the model and application versions, tool permissions and operating policy used for the accepted result. A later model upgrade or connector addition can change behavior even when the user-facing product name remains the same. Retesting should follow changes that affect the workflow, not only the release of a new model family.
Operational evidence can then complement the initial benchmark. Track the outcome categories that matter, preserve privacy and investigate recurring failure types. A dashboard dominated by average speed may hide a growing tail of unresolved cases. A dashboard dominated by errors may miss that the system is handling a different mix of requests. Definitions and denominators need to remain visible.
Cost needs a similarly complete boundary. Model usage is one item; tool services, retries, operator review and repair can add others. A cheap first attempt followed by a lengthy investigation may be expensive to operate. Conversely, a more costly attempt can be worthwhile if it reliably removes work that a person would otherwise need to do. The comparison should follow completed outcomes under the intended policy, rather than price each generated token as if every token created the same value.
Time should be reported in terms the service actually promises. The average duration can improve while a minority of requests wait much longer. A user with a deadline experiences their own request, not the arithmetic mean. Looking at the distribution and the reason for longer cases helps distinguish an expensive but necessary handover from an agent stuck repeating an unproductive action. A clear stopping condition can limit the latter without pretending that every difficult task is quickly solvable.
Finally, leave room to discover that the task definition was wrong. If users consistently need a different outcome from the one the benchmark rewards, optimizing the score can make the product less useful. An evaluation should be stable enough for comparisons and open enough to correction when its assumptions fail. Changing a test for that reason needs documentation; silently changing it to improve the number needs scrutiny.
The large 85% can now return to the page, accompanied by a meaningful label. It should say what was attempted, under which conditions, how success was established and what happened to the rest. The benchmark remains valuable. The workflow evaluation tells the organization whether that value survives contact with its own responsibilities.
Sources & context
This article draws on the sources linked in the text. Analysis and illustrative scenarios are identified separately from reported findings.
Our corrections policy
