A supplier promises that its agent scores well on a difficult benchmark. That sounds encouraging. Your first customer, however, asks about an order placed under an old email address, changes the request halfway through, and needs a reply before the afternoon delivery run.
The benchmark and the customer may be testing different things.
Public benchmarks help researchers compare systems under defined conditions. Your business also needs evidence about its sources, permissions, exceptions, and finished outcomes. A useful evaluation connects those two levels without pretending they are interchangeable.
What the major benchmarks measure
The descriptions below identify original research, not current leaderboard rankings. Results change with the model, tools, prompting, task subset, environment, and evaluation method.
| Benchmark | What the original work examines | How to use it |
|---|---|---|
| AgentBench | Language models acting in eight distinct interactive environments. | Examine whether the tested environments resemble a capability your workflow requires. |
| GAIA | General-assistant questions involving reasoning, browsing, multimodal information, and tools. The original collection contains 466 questions. | Look for evidence about finding and combining information; test your own action controls separately. |
| WebArena | Functional completion of tasks in reproducible websites spanning several domains. | Study browser task performance and verify behavior on your particular interfaces. |
| SWE-bench | Repository changes addressing real software issues. The original paper describes 2,294 problems across 12 Python repositories. | Evaluate software work using an identified dataset version and execution environment. |
| BIG-bench | A broad collection of language-model capability tasks. | Use relevant tasks as background evidence, then evaluate the complete business process. |
Do not transfer a score from one benchmark to another. A repository patch result does not measure customer-service quality. A correct answer does not prove that the system can safely send it to the intended recipient.
Historical figures also need historical labels. WebArena’s original paper reports 14.41% success for its best GPT-4-based baseline and 78.24% for humans in that evaluation. Those figures describe the published experiment. They are not a current ceiling for browser agents or a prediction of your project’s success. Original WebArena study.
Ask what was tested before asking who won
Record the benchmark version, exact split, system configuration, available tools, limits, and scoring rules. Identify whether the result concerns a single attempt or allows retries and selection among several answers. Include the cost of all attempts when cost matters.
Ask whether examples used for training, prompt tuning, or demonstration overlap with the evaluation set. Repeatedly adjusting a system against the same cases can make that set less useful as an independent check.
A score without its denominator is hard to interpret. “Nine out of ten selected tasks” carries different evidence from a large, representative evaluation. Report exclusions, failed runs, timeouts, and missing results rather than silently removing them.
These questions do not make public benchmarks useless. They make comparisons more meaningful.
Write a business acceptance contract
Start with one job. For a draft delivery-status reply, an accepted result might require the correct order, current tracking information, no invented delivery promise, an appropriate handoff when records conflict, and no message sent without the required authorization.
Separate content quality from action correctness. A beautifully written message can fail because it concerns the wrong customer. A correct lookup can fail because the system exposed an unrelated record.
| Dimension | Question to answer | Evidence |
|---|---|---|
| Task result | Did the required work get completed? | Saved artifact or verified destination state. |
| Factual support | Are material claims supported by appropriate sources? | Source identifiers and relevant passages or fields. |
| Permission | Were records and actions within the authorized scope? | Access and action decisions. |
| Recovery | Did a failure produce the intended retry, stop, or handoff? | State transitions and reconciliation record. |
| Human effort | How much inspection and correction remained? | Review and maintenance time. |
| Cost | What did all attempts cost? | Model, tool, infrastructure, and relevant labor costs. |
Some failures should block release even when the average looks good. Decide those conditions before evaluating. An unauthorized disclosure should not disappear inside a favorable writing-quality score.
Build a useful case collection
Collect ordinary cases, difficult but valid cases, and cases the system should decline or escalate. Include missing information, changed instructions, stale records, denied access, conflicting sources, and interrupted operations.
Keep representative evaluation separate from stress testing. A deliberately hostile test collection reveals weaknesses; it does not estimate how often those conditions occur in daily work. Label each collection and report its results separately.
For workflows with external actions, include a timeout after the destination has accepted the request. The expected behavior is to establish the outcome or preserve uncertainty, not blindly repeat the action. Include cancellation and restarting while approval is pending.
Use a development set for iteration and a held-out set for the release decision. Protect the held-out examples from routine prompt tuning. Refresh cases as the business changes while retaining enough stable cases to detect regressions.
Use reviewers deliberately
Give reviewers a rubric with concrete anchors. “Good answer” is vague. “All material factual claims have source support, missing information is explicit, and the next step is clear” is easier to apply.
Have reviewers score a shared sample and discuss disagreements. For subjective work, record both their judgments and the reason for meaningful differences. A second reviewer can catch a problem, but agreement is not proof that both are right.
An AI judge can help triage outputs or apply a consistent preliminary rubric. Validate its judgments against qualified human review on your own task. Keep model, prompt, and rubric versions. Do not assume a judge’s confident explanation establishes its accuracy.
Calculate results without hiding unfinished work
Suppose a constructed example contains ten attempted cases: seven accepted, two rejected, and one with an unresolved outcome. Accepted outcomes per attempted case is 7 ÷ 10, or 70%. Report the unresolved case separately. Dropping it and reporting 7 ÷ 9 answers a different question.
If all attempts cost $20 and seven outcomes are accepted, direct run cost per accepted outcome is about $2.86. That figure excludes review, implementation, and maintenance unless those costs are added. It also says nothing about the severity of the rejected cases.
These numbers are arithmetic examples, not measured agent results. In an actual pilot, preserve raw counts and the definitions behind each rate. Use uncertainty estimates appropriate to the sample and decision; a small clean sample cannot establish a rare failure rate.
Turn evaluation into a release decision
Evaluate changes to the model, prompt, retrieval collection, tools, permissions, and workflow. Investigate which cases changed and why. An improvement in average speed may come with worse handling of exceptions.
A staged release can move from controlled examples to shadow work, reviewer-approved drafts, and carefully selected external actions. Each stage should have its own evidence and owner. Shadow work should not trigger customer-facing actions through an overlooked integration.
Keep a versioned record of the decision: what was tested, what passed, what remains uncertain, who accepted the scope, and how the workflow will be stopped or reverted. Continue observing quality, costs, and unresolved work after release.
For implementation details, use agent development. For adoption and operating measures, use business implementation. Return to the agent collection for related topics.