Four posts into arguing that forms and screens recede as agents improve, I owe the other side its due. The direction is right; the timeline is easy to overstate. Anyone who has watched an agent demo and then handed it a real piece of work knows the feeling: the demo was a performance, and the job was a marathon.
What the long-horizon numbers say
Computer-use agents have improved fast on short, self-contained tasks. But benchmarks built from long, realistic work tell a more sober story. OSWorld 2.0, published in mid-2026, consists of 108 long-horizon workflows drawn from everyday and professional work. A human takes a median of roughly 1.6 hours to complete one. Agents need on the order of three hundred tool calls per task, around ten times the original benchmark’s thirty. The best system tested completed about one in five of them outright, scoring a little over half on partial credit. Another model plateaued near thirteen percent.
Read that carefully: the claim isn’t that agents can’t do useful work. A system that gets most of a ninety-minute workflow right is genuinely valuable. The claim is that “mostly right” is a different product from “reliably done”, and an interface can only recede as far as the reliability behind it.
Why long workflows are harder than long chains of short ones
Errors compound. If each step is ninety-five percent reliable, a hundred-step workflow succeeds a fraction of one percent of the time. Length punishes small error rates harshly.
State is implicit. Real work depends on things nobody wrote down: what was agreed on a call last week, why a field is left blank, which customer gets special handling. People carry that in their heads. An agent that can’t see it behaves sensibly and wrongly.
Environments change underfoot. Pages load late, dialogs appear, a screen is rearranged after an update. Agents that drive an interface the way a person does inherit all the fragility of the interface.
Recovery is the hard part. A person who makes a wrong turn notices and backs out. Agents often press on, compounding the mistake with confidence.
What to do with that, today
Prefer actions over clicks. An agent calling a well-defined capability directly is far more reliable than one operating a screen designed for humans. This is the quiet argument for the open protocols that let products expose their capabilities, covered in When Your Product Becomes a Tool.
Shorten the horizon. Break a long workflow into checkpointed stages, each with a verifiable result, so an error is caught after ten steps, not a hundred. This is the state-machine view of agents, applied.
Make partial completion a first-class outcome. If the agent can get seventy percent of the way, design the handoff so a person picks up the remainder with full context rather than starting again. That is the exception queue from The Interface That Remains earning its keep.
Measure on your workflows, not the leaderboard. A public benchmark tells you the field is moving. Only your own eval set, built from your own cases, tells you whether your agent has earned a rung on the trust ladder.
Reconciling this with the thesis
None of this contradicts the argument of the series. It sets its tempo. The interface recedes action by action, as reliability is demonstrated, not all at once because a model got smarter. Two years from now the same benchmark will look different; the people who built checkpointing, exception handling and evals will be the ones able to take advantage of it, while those who waited for the capability to arrive will start from nothing.
The sensible stance is neither “agents will do everything” nor “agents can’t be trusted.” It is to pick the workflows where the horizon is short or the damage is bounded, start there, and let evidence move the line.
Nobody Wants a Form — a five-part series on the interface in an agentic world
- Nobody Wants a Form
- The Trust Ladder
- What a Workflow Really Is
- The Interface That Remains
- One Framework for the Agentic PM
A companion to the series above — Why Agents Still Fail at Real Workflows — you are here.
Related: When Your Product Becomes a Tool · An Agent Is a State Machine, Not a Loop.
Leave a Reply