For twenty years, three words ended every automation conversation I sat in. "It has no API."
The finance system had no API. The scheduling tool had no API. The ancient warehouse app held together with a support contract and prayer had no API, and the vendor wanted six figures to build one. So the work went to humans. People typed numbers from one screen into another screen all day, and we called it a process.
Those three words stopped working this year.
The benchmark moved while nobody was watching
Computer use models work the way a temp worker works. They look at the screen, move the pointer, click, type, read the result. No integration. No vendor negotiation. No API.
When the OSWorld benchmark launched, the best model finished 12.24% of real desktop tasks. Humans finished 72.36% of the same set. The gap looked permanent.
In August 2026, the OSWorld leaderboard showed Qwen3.8-Max at 86.1%, with several Claude models a point behind. The machines passed the human number and kept going.
Worth noting: the leaderboard itself warns about reading those rows too confidently. Scores vary by evaluator, test rig, attempt budget and tool access, and some numbers come from the vendors themselves. Treat 86% as a direction of travel, not a promise about your Tuesday afternoon.
Still, the direction is one way. Your legacy system lost its last excuse.
An excuse expiring is not a plan
Here is where I watch teams get it wrong.
The no-API problem was never a pure technical wall. It worked as a budget filter. It kept bad automation ideas out, because anything involving the old system needed a business case big enough to fund integration work. Expensive doors keep out casual visitors.
Remove the door and everything walks in. Someone in operations points an agent at the finance screen on a Thursday, it works, and by the following quarter four departments depend on a thing no engineer reviewed, no one tests, and nobody owns.
You did not gain an integration. You gained an undocumented one.
The screen is an interface nobody agreed to
Every API you build carries promises. A schema. Versioning. Error codes. A changelog. Someone to shout at when a field changes type.
A screen makes none of those promises. The vendor moves a button in next month's release and owes you nothing, because clicking their button was never part of the deal. Your automation did not fail loudly, either. It clicked something else.
Silent wrong answers beat loud failures in one respect only: they take longer to find.
So treat the agent as what it is. A new integration layer with the weakest contract in your estate. Then engineer around the weakness instead of pretending it is absent.
What I want in place before one of these touches production
Read before write. The first month is reporting only. It reads screens, extracts data, writes nothing back. You learn the failure modes on work where mistakes cost nothing.
A blast radius, set in advance. Which accounts, which records, which value limits. An agent with a human's credentials owns a human's reach, and humans have far more reach than anyone audits. Give it its own login with its own permissions, scoped tight.
Idempotency at the boundary. Screen work fails halfway. The click landed, the confirmation page timed out, the retry submits the invoice twice. Design for a retry to be safe, because retries are coming.
An evaluation set you own. Thirty real tasks with known correct outcomes, run weekly against your actual system. Public benchmarks tell you about someone else's desktop. Your thirty tasks tell you about yours, including the week the vendor ships a redesign.
A log of every action, in your format. Screenshots and click coordinates are not an audit trail. Record the intent, the record touched, the before value, the after value. Your auditors will ask. So will you, at 2am.
A stop button an ordinary person reaches. If halting the agent needs an engineer with shell access, you have no stop button.
None of this is exotic. It is the standard you already apply to a payments integration. The novelty is applying it to work arriving through a screen instead of a socket.
The question changed shape
For two decades the question was "is integration possible here?" Technology answered it. The question now is "should this connection exist at all, and who owns it when it breaks?"
Second question is harder, because it has no vendor. Nobody sells you ownership.
I have seen this pattern before, in a smaller form. Spreadsheets. A finance person builds a model, it becomes load bearing, it runs the quarterly numbers, and eight years later a business depends on a file with one author who left in 2019. No review, no tests, no owner. Screen agents follow the same curve at higher speed and with write access.
The fix is old and boring. Write down which processes matter. Anything load bearing gets an owner with a name, a test, and a review date. Anything else stays firmly in the sandbox.
What I would do this month
Pull the list of systems your team has labelled "no API" over the past five years. The list is a to-do list now, and it has been quietly shaping your strategy while claiming to be a technical fact.
Sort it into three piles.
Pile one: work worth automating and worth a proper integration. Fund the API. The screen route is a bridge, not a destination.
Pile two: work worth automating where the system has months left to live. A screen agent with the guardrails above earns its keep here. Retirement date in the ticket.
Pile three: work nobody should automate, because the process itself is broken. Automating a broken process produces the same mess faster. Fix the process first, or delete it.
Most teams find pile three is bigger than they expect. Years of "we are blocked by the old system" hid a pile of steps nobody had examined since 2014.
The part I find uncomfortable
Every argument above assumes your people stay in the loop somewhere. Once an agent works a screen faster and longer than a person does, the loop tightens on its own. Review becomes rubber stamping. Rubber stamping becomes a checkbox. A checkbox becomes nothing.
I have no clean answer to this beyond making review a real job with real time attached, rather than something squeezed between other work. Attention nobody schedules is attention nobody gives.
The excuse expired. Your legacy system is reachable now, whatever the vendor says. So the choice returns to you, where it belongs.
Which of your "we cannot automate this" systems was never a technical problem at all?