What Should Never Be An Agent: Use The Benchmark Gap As Your Decision Criterion

Mostafa Dhouib·10 min read

What Should Never Be An Agent: Use The Benchmark Gap As Your Decision Criterion

The short answer. Published benchmarks that put agents on realistic computer-use tasks, the kind involving a browser, a file system and multiple applications, report task completion rates in the low tens of per cent. Humans doing the same tasks sit near ceiling. Treat that gap as a design input rather than a verdict. A low success rate is perfectly workable when verification is cheap and failure is free, because you can run the task, check the answer in seconds, and discard the misses. It is unacceptable when the action cannot be undone, or when checking the output costs as much as producing it, because then every failure is either permanent or paid for twice.

The benchmark numbers get used badly in both directions. One camp reads them as proof that agents do not work. The other dismisses them as unrepresentative of their own workload, which is sometimes true and always convenient.

Both miss the useful question. A success rate is not a pass or fail grade. It is a parameter, and what it means for your system depends entirely on two other parameters you control.

Why the gap is the right number to reason from

The computer-use benchmarks are the relevant ones precisely because they are messy. A model answering questions in a single turn is a different problem from a model operating a graphical application, keeping track of state across dozens of steps, recovering from a dialog it did not expect, and knowing when it is finished. The second is what people mean when they say agent, and it is the one where the measured rates are low.

The human comparison is what makes the number actionable. If both humans and agents scored in the low tens of per cent, the tasks would simply be hard and the gap would tell you nothing about the technology. Humans near ceiling on the same task set means the difficulty is not intrinsic. It is a capability gap, and capability gaps have a predictable shape: they close slowly in general and unevenly across task types.

So planning on today's rate is defensible. Planning on a rate you expect next year is not.

The two parameters that decide everything

Hold the success rate fixed and vary two things.

Cost of verification. How much does it cost to know whether the output is right? Measure it against the cost of producing the output in the first place. Cheap verification means a test suite, a type checker, a schema, a diff you can read in thirty seconds, a number you can compare to a known total. Expensive verification means reading the whole output carefully, reproducing the reasoning, or calling someone to confirm.

Cost of a wrong answer that gets through. Not the cost of a detected failure, which is just a retry. The cost of an undetected one. For a draft nobody acts on, near zero. For a payment, a schema migration, an email to a customer, or a configuration change on live infrastructure, unbounded.

Those two produce four quadrants, and the quadrants are the whole decision.

Cheap to verify, cheap to be wrong. Run the agent. This is where agents earn their keep at a low success rate, because you are effectively sampling until you get a usable result and the misses cost nothing. Drafting code against a test suite, generating candidate queries, proposing refactors, summarising for a human who will read the source anyway.

Cheap to verify, expensive to be wrong. Run the agent, gate the action. The verification is the gate. An agent can propose a migration if the migration is applied only after a check passes and a human approves. The low success rate becomes a throughput problem rather than a risk problem.

Expensive to verify, cheap to be wrong. Run the agent and accept that you will not know. This quadrant is more common than people admit, and it is where quality silently degrades. Research summaries, competitive analysis, documentation. Nothing breaks, so nothing surfaces, and the output's accuracy becomes unknown rather than bad. Our advice here is to pick a sample and verify it properly rather than verifying everything shallowly.

Expensive to verify, expensive to be wrong. Do not use an agent. This is the quadrant the title refers to. If you cannot cheaply tell whether the output is right, and being wrong is costly, then a low success rate means you are paying for the work twice and getting a worse result. The arithmetic does not improve with a better prompt.

A decision procedure you can run in a meeting

We use this as a sequence of questions, in this order, because each one can end the discussion.

One. Can the action be undone, and by whom? If reversal requires a person who is not on duty at three in the morning, treat it as irreversible. If it cannot be undone at all, stop here. The task is not an agent task, though a part of it may be: the agent can prepare the action and a human can take it.

Two. What is the check, named specifically? Not "a human reviews it." Name the artefact. A passing test suite. A schema validation. A total that must reconcile. A diff that must be non-empty. If nobody in the room can name a concrete check, you are in the expensive-verification half and you should say so out loud rather than discovering it later.

Three. What does the check cost relative to the work? If verifying takes a tenth of the time of doing, agents are viable at low success rates. If it takes most of the time, they are not, because at a low completion rate most of your verification spend is spent confirming failures.

Four. How many attempts are acceptable? A low success rate means retries. Retries cost tokens and wall-clock time, and in some systems they cost side effects, because a failed attempt that already sent an email cannot be cleanly retried. Multiply the per-attempt cost by the expected attempts and compare to doing it directly. This is the step that kills more candidate agent use cases than any other, and it is almost always skipped.

Five. What is the blast radius of a confident failure? The worst agent failure is not an error. It is a plausible wrong answer delivered with no signal. Ask what that answer touches. If it touches money, identity, safety, or a customer's inbox, the answer needs a gate regardless of what the success rate is.

If all five questions pass, build the agent. If question one or three fails, do not. If two or four fail, you may have a scoping problem rather than a rejection: shrink the task until verification becomes cheap.

Shrinking the task is usually the right move

Most tasks that fail this procedure are composites. A single request that spans six steps, three applications and a judgement call will score badly and will be expensive to verify, because verifying it means verifying all six steps.

Break it up and the parameters change. One step may be fully deterministic and belong in ordinary code. Another may be the genuine judgement call and belong with a human. The two or three in between may be cheap to verify individually, which puts them in the first quadrant even though the composite was in the fourth.

This is why the benchmark number is often misapplied. The benchmarks measure end-to-end completion of long, realistic tasks. Your system does not have to attempt long realistic tasks. It can attempt short verifiable ones, and the success rate on a short verifiable step is a different number entirely.

The honest limit

The benchmark figures we are reasoning from are published third-party results on realistic computer-use task sets, reported as task completion rates. We are quoting the shape, low tens of per cent against humans near ceiling, because that is what the sources support, and we will not put a more precise figure on it than that. Benchmark suites differ in what they count as completion, and a task set assembled by researchers is not your workload.

The procedure has a weakness we have run into repeatedly. Question three asks for the cost of verification relative to the work, and teams systematically underestimate it, because they imagine verifying a correct output. Verifying a wrong output costs more, since you have to find the error rather than confirm its absence, and at a low success rate you are doing that most of the time. If you want the procedure to be accurate, estimate verification cost on a failure, not a success.

And none of this addresses the case where an agent is worth running despite failing the procedure, because the task is not being done at all today. A task nobody has time for has no baseline cost to compare against, which breaks the arithmetic in a way we have not found a clean answer to.

FAQ

What success rate do agents actually achieve on realistic tasks? Published benchmarks on realistic computer-use tasks, involving a browser, a file system and multiple applications over many steps, report completion rates in the low tens of per cent, with humans on the same tasks near ceiling. That is end-to-end completion of long tasks. Success on short, well-scoped, individually verifiable steps is a different and much higher number.

Does a low success rate mean agents are not useful? No. It means usefulness depends on two other things: how cheaply you can check the output, and what an undetected wrong answer costs. When checking is cheap and failure is free, a low rate is fine because you discard the misses at no cost. When checking is expensive and failure is costly, the same rate is disqualifying.

Which tasks should never be given to an agent? Tasks where verification costs about as much as doing the work and being wrong is expensive. If you cannot name a concrete cheap check, and a confident wrong answer touches money, identity, safety or a customer, then a low completion rate means paying for the work twice and getting a worse result. Prompt engineering does not change that arithmetic.

How do I estimate the cost of verification? Estimate it on a failing output rather than a passing one. Confirming a correct answer is quick. Finding the error in a plausible wrong answer takes longer, and at a low success rate that is the case you will be handling most of the time. Teams that estimate on the happy path consistently conclude an agent is viable when it is not.

What if a task fails the decision procedure? Shrink it before rejecting it. Most failing candidates are composites of six steps across three systems, and the end-to-end task is both low-scoring and expensive to verify. Split it. Deterministic steps go into ordinary code, the genuine judgement call goes to a human, and the verifiable middle steps can go to an agent at a rate that works.

Do irreversible actions rule out agents entirely? They rule out the agent taking the action. They do not rule out the agent preparing it. An agent can draft the migration, assemble the payment batch or compose the message, with the irreversible step gated behind a check and a human. That split keeps the throughput benefit and moves the risk to where a low success rate does not matter.