A conversation about integrating an old system almost always starts the same way: “There's no API.” What used to follow was a pause and an estimate for manual work; now there's an answer that sounds like a master key: just let an agent do the clicking instead of a person. Technically it works, and the demo is convincing — the agent opens a window, finds the field, enters the value and clicks “Save.” The hard question is a different one: what happens to this automation four months from now, when the software vendor moves the button two centimeters to the left.
The answer depends on what the agent relies on at the moment it acts — a written contract or a picture. Integration methods line up like the rungs of a ladder, where each next one gives you more reach and less to stand on. The sensible order is to go from the top down and stop at the first rung that covers the task.
The integration rungs, in order of increasing fragility
The first and sturdiest is a documented API. You work not with the program but with its written contract: which fields exist, what comes back in the response, what counts as an error. That contract changes too, but it changes with notice: it has versions, and the vendor has a support schedule for the old ones. A breaking change arrives with a warning and a date.
On the second rung are events and webhooks, where the platform itself pushes you a notification about a change. There is still a contract here, but delivery is no longer guaranteed: Bitrix24 states outright that events are not re-sent, and Shopify advises against relying on webhook delivery at all. We covered this class of failures separately in “Where your automation ends” — the link is at the end of this article.
The third is a ready-made connector or an iPaaS platform between your systems. You don't write code, and that is a real saving, but there is now one more vendor between you and the system, with its own release schedule. When the platform updates its API, the connector doesn't catch up instantly, and the window between those two events is where you live.
The fourth rung is file exchange: a scheduled export, a scheduled import, CSV or XML in a folder. It regularly gets skipped as outdated, and that's a mistake. File exchange doesn't give you real time, but the export structure in enterprise systems changes far less often than on-screen forms do, and a failure shows right away: the file either matches the expected structure or it doesn't. If the task can tolerate an hour's delay, this rung often turns out to be the cheapest of those that work reliably at all.
Next comes scraping a page or calling an internal, undocumented request that you spotted in the browser's “Network” tab. Formally, this is already working without a contract: you rely on markup and on an address that the vendor never promised you and is entitled to change on any given Tuesday.
The sixth and last is Computer Use. There is nothing to stand on at all: the agent sees what a person sees, that is, an image of the screen, and each of its actions is a guess about what is drawn at that point. Everything that was written down as text on the previous rungs has to be recognized afresh every time here.
What the measurements show
This field is measured in public. The OSWorld benchmark, from researchers at the University of Hong Kong, Salesforce Research, Carnegie Mellon and the University of Waterloo, sits an agent down at a real operating system and gives it work tasks. In the first version, published in 2024, humans completed more than 72% of the tasks and the best model 12.24%, and it failed at the simplest thing: it couldn't reliably work out where on the screen to click.
Over two years that part of the problem was largely solved, which is exactly why the second version of the benchmark came out in June 2026 — with 108 long end-to-end scenarios instead of short operations. The median task takes a skilled person about 1.6 hours, almost 70% of the tasks run longer than an hour, and the agent spends an average of 318 tool calls on one such task, against roughly 30 in the first version.
The results on these scenarios are as follows. On the main metric — a task is either completed or it isn't — the best result belongs to Claude Opus 4.8 at maximum reasoning effort: 20.6% of tasks completed, with a partial-credit score of 54.8%. GPT-5.5 is far more economical with tokens but plateaus at around 14%. As of October 2026, the benchmark leaderboard is topped by Claude Opus 5: 44.33% of tasks completed on the updated v2.1 task set — more than double, but still fewer than half.
Completion holds up only on short scenarios. The authors built the breakdown by duration on the previous generation of models — GPT-5.5 and Claude Opus 4.7 — so the overall 20.6% of the newer Opus 4.8 is earned on the short and medium stretches rather than evenly across the whole scale. On scenarios shorter than 45 minutes of human work, both models score 20–24%, and beyond that they drop fast. In the 137–163 minute bin, none of the tested models gets above 10% anymore, and on everything longer than 163 minutes the completion rate is zero for every one of them. This is a cliff, not a gradual decline. A Computer Use scenario has to be cut into short stretches with a check between them, because a long chain simply doesn't make it to the end.
Agents don't break where you expect
Intuition says the agent will miss with the mouse. The authors of the second version of the benchmark record something else: the models stumble neither on basic interface control nor on code. They lose constraints set at the start of the task, miss information that arrives while the task is already running, guess where they should have asked, and don't check their own result. What they handle worst is work that depends on hidden state — on what isn't visible on the current screen.
Here are six rows from the breakdown of difficulties across the 108 scenarios:
- visual-spatial precision — needed in 41.7% of tasks: hitting the target, aligning, checking at pixel level
- inferring implicit state — 39.8%: the value you need isn't written anywhere and has to be pulled from earlier records or logs
- tracking the state of many objects — 39.8%: keeping dozens of rows, records or edits consistent with one another until the end of the scenario
- resolving contradictions — 36.1%: two sources say different things, and you have to work out which one takes precedence
- working from instructions — 20.4%: extracting a procedure from a PDF or a video and applying it to a case the instructions don't describe
- conditions changing on the fly — 9.3%: an email or a chat message in the middle of the task changes the requirements
If the operation you're about to hand to an agent depends on the person doing it remembering an agreement from three weeks ago and knowing which of two price lists is current, you are placing automation at exactly the point where it is weakest today.
What the maker itself says about it
Anthropic lists the limitations of its computer use tool openly, and the list deserves a look before you plan anything. Latency, as the documentation puts it, may be too slow compared with regular human-directed computer actions, so the maker recommends scenarios where speed isn't critical — background information gathering, automated testing — and in a trusted environment. The model can make mistakes or invent coordinates when it determines where to click. Tool selection becomes less reliable in niche applications and when several programs are in use at once. Scrolling gets its own item on the list: in applications where scrolling doesn't take effect, the documentation suggests keyboard alternatives such as Page Down.
Focus on use cases where speed isn't critical (for example, background information gathering, automated software testing) in trusted environments.
— Anthropic, “Limitations” section of the computer use documentation
It's worth looking separately at what exactly leaves your perimeter, because it's easy to draw the wrong conclusion here. Computer use works as a client-side tool: the session runs on your side, and screenshots, mouse movements, keyboard input and files are stored in your environment, not with the model provider. But the screen images still go to the model — it processes them in real time as part of the API call, and they are exactly what you pay for in input tokens. Retention of those requests is governed by the general API data retention policy, and the mode itself is compatible with zero data retention, because your application determines where and how the data is stored. If customers' personal data is visible on the screen while the agent is working, that is a matter for a data processing agreement, not for an “everything stays with us” checkbox.
Where the maintenance cost comes from
The bill for Computer Use is structured differently from the bill for an API call, and that is worth building into the estimate before you start. The agent sees the system through screenshots, each of which costs from about a thousand to 1,800 input tokens, and it takes one at practically every step. Recall the order of magnitude from the benchmark: 318 calls per task against 30 in short operations. Spend grows with the length of the scenario, not with its value to the business — which is why two operations with the same benefit can differ tenfold in unit cost purely because of the number of screens along the way.
The second cost item is rework. An API integration lives until an announced version change. A screen-based integration lives until the next interface release, which nobody will tell you about, because for the vendor moving a button isn't a change to the contract — it never had a contract with you in the first place. What you need to plan here is not a one-off implementation but a regular review tied to how often that system is updated.
The third, and the nastiest, is silent failure. A script that has crashed is visible immediately. An agent that confidently clicked the neighboring button after the button moved keeps reporting success, and you will see the difference only in the data, sometimes weeks later. So what you need to monitor is the result of the operation in the receiving system, not the fact that the agent ran without an error.
When Computer Use is justified
Taken together, the conditions add up to a fairly narrow window, and it's more honest to list it in full:
- the upper rungs really aren't there — you have checked not only the public documentation but also partner access, export to a file and, for systems on your own server, reading the database directly
- volume stays in the dozens of operations a day: at thousands, the cost of screens and the error rate will outweigh manual work
- the scenario is short — minutes, not hours — or cut into stretches of that length with a check between them
- the process is stable — that system's interface is updated rarely, and you know how often
- the result can be verified by machine: there is somewhere to look and confirm the action was actually performed
- the error is reversible — the operation doesn't transfer money, doesn't delete records and doesn't go out to a customer without human confirmation
- there is an owner — a person who investigates failures and is accountable for the result
The first item filters out more projects than people expect. The most expensive mistake in this area isn't technical at all: a company builds fragile automation on top of the screen while having a nightly export within reach that nobody looked into, because nobody put the question to the vendor.
What to do before implementation
Start with one more attempt to find a contract. Asking the vendor about a partner API or a regular export takes one email and settles the matter more cheaply than any development work. The next step is to write the process down: the sequence of screens, the branching conditions, what success looks like and what failure looks like. An agent that acts on the screen has nowhere to pick up an unwritten rule, so everything that currently lives in an employee's head will have to be brought out.
Then come four things worth describing concretely rather than just naming. Checkpoints: after every meaningful step the agent verifies the state of the system — if it has created a counterparty, it reads that record and compares the EDRPOU code (the Ukrainian company registration number) with what it entered. The line of irreversibility: the agent prepares the payment order, and a person clicks the “Post” button. A rollback plan: a nightly dump of the table before the scenario runs, plus the name of whoever does this work by hand while the scenario is being reworked. And monitoring based on the result in the receiving system — not “the agent ran without an error” but “47 records appeared in the CRM yesterday, the same as in the source.”
This work is needed equally for Computer Use and for any automation method higher up the ladder. The only difference is that on the upper rungs you can get by without it for longer, while here its absence shows up within the very first month.
Auspex builds CRM automation and integrations, and in projects with old legacy systems this conversation comes up all the time. In practice, an inventory of what the system can expose to the outside — partner access, exports, the database — removes the question of Computer Use more often than it confirms it. That inventory is where our CRM and integrations audit begins; the link to it is below.