A model tops a leaderboard, so you try it on a document you work with every week. It misses the footnote, confuses two versions and writes a confident answer. The benchmark may be accurate. Your disappointment can be accurate too.
A benchmark asks how a system performs on a defined collection of tasks under particular conditions. Your work may use different documents, require different tools or punish a small mistake much more severely.
Find out what was actually measured
A score can describe a base model, a model with tools or an entire agent system. Those are different things. Search access, a code runner, a larger time budget and repeated attempts can change the result.
Anthropic’s agent evaluation guide describes an evaluation as a set of tasks, attempts and grading procedures. It also emphasizes the surrounding system: instructions, tools and the environment in which the model operates.
Before comparing two numbers, look for the test version, available tools, number of attempts and definition of success. If those conditions differ, a higher score does not isolate the model’s contribution.
That does not make benchmarks useless. They can show progress on well-defined capabilities and suggest what to investigate. They are a starting point for a purchase or deployment decision, not the completed decision.
Build a small test from work you recognize
Pick a handful of real tasks with answers you can check. Remove private information unless the service and your organization permit its use. Keep the original input unchanged across tools.
For a research assistant, one task might ask for the differences between two product announcements. Another could contain an outdated page alongside a correction. For a document assistant, use a table with a note that changes how one row should be interpreted.
Include at least one case where the right response is to say that the available material is insufficient. A system that always produces an answer can appear productive while quietly manufacturing missing facts.
Write the success criteria before running the test. “Accurately identifies the revised deadline and cites the relevant paragraph” is easier to assess than “gives a good summary.”
Count repair work
Suppose one model produces an answer in 20 seconds that takes five minutes to check. Another takes a minute but produces a result you can verify in 30 seconds. The second may fit your workflow better.
Those numbers are an illustration, not measured results. They show why response speed alone is a weak productivity measure.
Record the time spent correcting errors, reformatting output and repeating instructions. Note whether failures are easy to spot. An obvious refusal costs a retry; a plausible but incorrect number may travel into a report.
Also separate a cheap draft from an action that changes something. Anthropic’s discussion of agent design explains why adding autonomous steps brings cost and complexity. A tool that writes a usable draft may still need strict controls before it sends messages or modifies records.
Repeat the awkward cases
Generative systems can behave differently on repeated attempts. Run important tasks more than once and retain the failed outputs. Do not quietly replace a bad attempt with the best of five unless your actual workflow includes five attempts and a reliable selection process.
A compact record is enough: input, configuration, result, correction time and failure type. Repeat the same set after a model or product update. Keep a few tasks separate from the examples used to tune your instructions, so you can check whether the improvement generalizes.
For software that can act on your behalf, also read our inbox permission guide. An evaluation should include what a system is allowed to do when it gets confused.
