Every automation project has a moment where it looks nearly finished. The agent handles the main path. The demo works. Most runs go through. And then the last stretch — the part between “mostly works” and “we can rely on it” — turns out to be most of the work.
That last stretch is where computer-use agents will be won or lost.
Reliability compounds
Consider a workflow with thirty steps. If an agent gets each individual step right 98% of the time, that sounds excellent. But the chance of getting all thirty right in a row is 0.98 to the power of thirty — about 55%.
In other words: an agent that is almost always right at each step can still fail nearly half of the jobs it starts.
The math works in the other direction too. Push each step to 99.9%, add verification that catches most of the remaining errors, and the end-to-end rate climbs dramatically. Small improvements in step reliability — and especially in error recovery — have outsized effects on whether a job actually finishes.
The long tail is the job
The happy path is easy to automate. Real work is full of things that aren’t on it:
- A session that times out halfway through.
- A multi-factor prompt that appears only on some days.
- A page that loads slowly, or loads in a different order.
- A button that was renamed in last week’s release.
- A scanned PDF instead of a text one.
- A duplicate record, a missing field, a customer who is always a special case.
None of these are exotic. Each is rare on its own; together, they show up constantly. A human operator handles them almost without thinking. An agent has to be built to handle them on purpose.
Measure jobs finished and verified — not steps attempted.
What finishing requires
Agents that finish the job tend to share a few properties.
They verify outcomes, not actions. Clicking “Save” is an action. The outcome is a record with the right values in it. Good agents read back what they did and confirm that the world now looks the way it should.
They recover instead of stopping. When something unexpected happens, they try another path: refresh, re-authenticate, search instead of navigate, wait and retry. They distinguish between a transient glitch and a real problem.
They are safe to rerun. If a job is interrupted, running it again must not pay an invoice twice or send a duplicate email. Idempotency is a product feature.
They escalate with context. Sometimes the right move is to ask a person. The difference is in how: a precise question, the evidence, and the exact state of the task — not “something went wrong.”
They learn each environment. Every company’s systems have quirks. Agents that remember those quirks get steadily better at a customer’s specific workflows.
The metric that matters
If you are building in this space, the most important number on your dashboard is not how many steps your agent can take or how many tasks it attempted. It is the share of jobs completed and verified without a human having to fix them.
Around that number sit a few others worth tracking:
- Cost per completed job, including retries.
- Time to completion, end to end.
- Human minutes spent per hundred jobs.
- The most common reasons jobs fail — named, counted, and shrinking.
The opportunity in the last mile
The last mile is hard, which is exactly why it is valuable. Anyone can build the first 80%. The companies that win will be the ones that grind through the long tail until “almost done” becomes simply done.
That is the kind of team we want to hear from.