You will stop prompting. Here is what has to be true first.

There is a version of this that everyone can already picture.

You open your laptop on a Monday. Nothing is waiting for you. The three vendor quotes that came in over the weekend have been pulled out of your inbox, put side by side, and the outlier flagged. The invoices are filed. The candidate who replied on Saturday has a draft response sitting in your drafts folder, written in a way that sounds like you, referencing the thing you talked about on the call in March. Two subscriptions renewed and one of them is flagged because you stopped using that tool in April.

You did not ask for any of it. You turned something on six weeks ago and it has been running since.

That is the shape of where this goes. Not a smarter chat box. Not a better prompt. Work that gets done in the gap between when you notice it needs doing and when you would have gotten to it.

Everyone in this space says some version of that. The interesting question is not whether it happens. It is what has to be true for it to happen, and why nothing shipping today can get there from where it stands.

The arithmetic nobody puts on a landing page#

Start with the thing that governs all of it.

An agent doing a multi-step task succeeds only if every step succeeds. That makes task success the product of per-step success rates:

P(task) = p^n

Where p is how often a single step works and n is how many steps the job takes.

This looks harmless until you put numbers in it. An agent that gets each individual step right 95% of the time sounds excellent. Over a thirty-step task it completes 21% of the time. Over fifty steps, 8%.

Run it backwards and it gets worse. If you want a task to succeed 90% of the time over twenty steps, the per-step reliability you need is:

p = 0.90^(1/20) = 0.995

99.5%. Per step. Every step.

That is the gap between a demo and a product. It is why agent demos are astonishing and agent products are exhausting. The demo is five steps. The work is thirty.

And it explains the published numbers better than any narrative about model quality does. On long-horizon web tasks that span multiple sites and many steps, the strongest frontier systems complete about 44.5% of them. On OSWorld, which tests real desktop work across applications, the human baseline is 72.36% and the leading agent sits at 63.5%. These are not bad systems. They are systems running into an exponent.

Our own number sits at the short end of the same story. On Online-Mind2Web, the public board for browser agents, Melvin scores 95.0% on our own run of the same 300 tasks. Those tasks are short. The distance between that figure and the 44.5% on long-horizon work is not a distance between models. It is the exponent, and it is why we spend our time on the loop rather than on the leaderboard.

The standard response is to retry. Run it again, run it four times, tokens are cheap now. That works when failure is free to undo. It is not what happens on a computer. You cannot un-send an email. You cannot un-submit a form. Attempt two does not start from a clean slate, it starts from whatever attempt one left behind. Retrying a stateful, irreversible action is not sampling the same distribution twice. It is sampling a worse one.

So there are two levers, and only two. Raise p. Shrink n.

The 16-point gap#

Here is the finding that should reframe how you think about this, and it comes from coding agents rather than from anyone selling desktop automation.

Take Claude Opus. Run it inside Cursor on Terminal-Bench 2.0: 93%. Run the same model, unchanged, inside Claude Code: 77%.

Sixteen points. No fine-tuning. No different weights. No prompt engineering on the task. The only variable was the harness, meaning the loop around the model: how it manages context, when it truncates, how it recovers from errors, what it checks.

It is not an isolated result. Letta Code running Claude Opus 4.5 scored 59.1% on Terminal-Bench 2.0 against Claude Code's 41.6% on the identical model. Eighteen points, same story.

The people who study this have started calling it the harness effect, and the practical version is blunt: the infrastructure around the model moves results more than swapping to an entirely different frontier model would.

There is a companion observation from the same research that is worth reading twice. Codex CLI, analyzed step by step, handles individual actions cleanly but loses coherence on chains beyond step three or four. The analysis is careful to say this is not a model limitation. It is a harness characteristic.

Losing coherence past step three or four is p^n with a human-readable label. The agent is not getting dumber. It is accumulating unchecked assumptions, and by step five it is reasoning about a world that has quietly diverged from the real one.

What Claude Code actually has#

Coding agents can run for hours. Not five minutes, hours, and come back with something correct. That is not because the models are better than the ones driving browser agents. It is often the same model.

It is because a code environment hands the agent ground truth for free.

Tests pass or they fail. The compiler errors or it does not. git diff shows exactly what changed, byte for byte. Every one of those is a program returning a result, not the model's opinion about whether it did well. The agent proposes, the environment disposes, and the disagreement is settled by something that cannot be talked out of its answer.

That is the whole trick. Not persistence. Verifiability. The persistence is downstream.

An agent that can check its own work at every step can run indefinitely, because errors get caught where they happen instead of compounding into step thirty. An agent that cannot check its work is running blind and reporting confidently, and the length of the run is just how long it takes to be wrong at scale.

Now look at what a GUI agent has. It clicks something. The screen changes. It reads the screen. Did it work? The only witness is the agent's own interpretation of a rendering, which is precisely the thing that is unreliable.

There is no compiler for clicking a button.

Why the cloud cannot close this#

Every serious agent product shipping right now runs on a machine in a data center. The user's machine is a viewer.

That is a reasonable engineering choice. It scales, it is uniform, it is easy to reset. And it puts a ceiling on this problem that no amount of model improvement lifts.

The environment is a stranger. A fresh VM has no files, no history, no prior state. It knows what it was told in the prompt and nothing else. When an instruction is underspecified, and instructions are almost always underspecified, it either asks or it guesses. Guessing is where multi-step tasks go wrong quietly.

The verifiable surface is thin. In a cloud browser you can check a URL and query a DOM. You cannot read back the file that was supposed to land in the user's Documents folder, because there is no Documents folder. You cannot confirm the draft is sitting in Mail, because there is no Mail. The actions with real consequences happen where the checking cannot follow.

Nothing accumulates. Every run starts from approximately zero. The system does not get more reliable because you used it more, it gets more expensive.

The result is a set of products that are impressive per task and static across tasks. Which is fine for a demo and wrong for the Monday morning described at the top of this piece. Work that happens without you asking requires trust, trust requires reliability, and reliability requires the ability to check.

Verification is the last mile#

If p is the lever and there is no compiler for a GUI, the job is to build one.

Not a model that reviews the work. That reintroduces the exact problem, because now you have an unreliable narrator grading an unreliable narrator. A deterministic check: a piece of code that goes and looks at the world after the action and returns pass, fail, or unverifiable.

Concretely, this is what it looks like:

The file was written. Read it back off disk. Confirm the size and the content. Not "the agent said it wrote the file." The bytes are there or they are not.

The files moved. Confirm they exist at the destination and are gone from the source. Both halves, because a copy that did not delete is a different outcome than a move.

The note was created. Query the note store by ID and confirm the body contains what it was supposed to contain.

The draft exists. Look in Drafts for a message with that recipient and that subject. If it is not there, the agent's report that it drafted a reply is a claim without evidence.

The calendar event landed. Fetch by identifier, confirm the summary and start time match what was asked for.

The page ended where it should have. After a browser task, read the final URL and assert the confirmation element is present. Not a screenshot the model interprets. A query with a boolean answer.

Three states, and the third one matters as much as the first two. Pass means checked and correct. Fail means checked and wrong. Unverifiable means there was nothing to check, and it is never quietly rounded up to pass.

Some actions genuinely have no artifact. Whether a drafted reply is good is not a thing a program can settle, and pretending otherwise is how you end up with a verifier that reports success it cannot substantiate. Those stay human-approved. The honest system knows the difference and shows you which is which.

In our own runs, verification currently covers 41% of executed actions, with 59% returning unverifiable. That second number is the one we watch. It is a measure of how much of the system is still running on trust. Today every one of those unverifiable results has the same cause: a shell action for which no verifier is registered yet. That is a list of verifiers to write, not a mystery.

What it unlocks#

Verification sounds like a safety feature. It is closer to an engine.

It stops the compounding. A failed check at step five ends the run at step five instead of feeding a bad assumption into twenty-five more steps. That is p^n interrupted rather than endured, and it changes both the failure rate and the bill. On our instrumented failed runs, 52% of the tokens were spent after the first failed step. Catching failures at the point of occurrence removes that spend, which cuts the average tokens per failed run roughly in half.

It makes memory safe. A successful run can be stored and replayed the next time the same job comes around, which turns an expensive twenty-step agent execution into a cheap deterministic replay. But only if you know it succeeded. Without verification you cache broken paths and replay them with total confidence, forever. Verified runs are cacheable. Unverified ones are not, ever.

It detects staleness. When a stored routine replays and the check fails, that is not a mystery. That is a signal the world changed and the routine needs repair. The expensive agent runs again on that one step, finds the new path, and the routine is fixed for everyone before most people hit the break.

It compounds. This is the part that matters for the Monday morning. A system with verified memory gets more reliable and cheaper the more it is used, because every successful run is an asset. A system without it gets neither. Over a long enough period those two curves are not competing products, they are different categories.

Where this actually ends up#

The version of this that arrives is not an agent that never asks you anything. Some things require you: a service has to be authorized once, an irreversible action deserves a look, a judgment call is a judgment call.

The version that arrives is an agent that stops asking about the things it can confirm for itself.

That is a smaller claim than "you will never lift a finger" and a much larger one than what ships today. It means the routine work runs and finishes and you see that it finished, with evidence, not with a summary. It means the exceptions come to you and the rest does not. It means turning three routines on in October and finding in December that they have quietly done about 200 runs, thirty-odd hours of work at ten minutes a job, that you never thought about again.

Getting there is not waiting for a better model. Two independent measurements put the harness ahead of the model by sixteen and eighteen points on identical weights. The leverage is in the loop.

And the loop has to run where the work is. On the machine with the files, the mail, the history, and the applications that never had an API. Not because local is a philosophy, but because that is the only place the checking is possible.

An agent you can trust is not one that is confident. It is one that can be wrong in a way you find out about.

The verification and token figures are from our own instrumentation: 479 actions logged by the verifier in gate mode on 1 and 2 September 2026, and 28 failed runs with per-call token usage out of 866 instrumented runs. The December figure is arithmetic, not a measurement: three weekday routines over the 66 working days from October to December is 198 runs, and ten minutes a job is our assumption for what each replaces. Published figures are as reported by their sources at the time of writing.

Melvin Laboratory