Why Computer Use Doesn't Scale on Legacy Desktop Apps

A computer-use agent demo is genuinely impressive. The agent navigates the GUI like a person, clicks buttons, handles error popups and types data into fields, and it does all of that on a legacy system nobody has a usable API for. Then the team wires it into the pipeline that actually runs the business and reaches for it on every step, and that is where it stops working. Not because an agent cannot be a step. Because every step it runs costs seconds of wall-clock time and a model call somebody pays for.

That is the whole argument. A computer-use agent is a legitimate component, and there are steps where letting a model work out what to do is exactly the right call. It is a poor default. You pay for it twice on every action it takes, once in wall-clock time and once in inference spend, and customers who have tested computer use against Minicor report Minicor running the same automation up to 11x faster. Then there is the part that is harder to put a number on: an agent that decides its own actions gives you nothing to inspect before it touches a customer's system. Engineering teams building AI products for legacy desktop systems get into trouble at the point where computer use stops being a component and becomes the whole automation. 100% computer use is the version that does not scale.

What It Costs to Put a Model in Charge of a Step

Legacy desktop software is the hardest place to do this, and the software itself is a large part of why. A desktop app has no API contract, so nothing holds it to a response time. Screens repaint at their own pace, a modal dialog can appear at any point, and running the app over Citrix or RDP puts more distance between the agent and the pixels it is reasoning about. Every other call in your pipeline can tell you roughly when it will come back. The agent driving that desktop cannot, and the desktop is half the reason.

Agent latency is non-deterministic. The same task can finish quickly on one run and take far longer on the next, because the model works the task out from scratch again each time rather than remembering it. The OSWorld-Human benchmark (arxiv.org/abs/2506.16042) measured end-to-end latencies in the tens of minutes for tasks that typically take humans just a few minutes, and found that large model calls for planning, reflection and judging account for most of that time. That variance is affordable in one place and not in ten. If one step in a workflow has no latency ceiling, you design the workflow around it, which is ordinary engineering. If every step is like that, there is nothing left to design around.

This unpredictability forces you to set timeouts so high that they become meaningless. A timeout generous enough to cover the agent's worst run means that single step can hold a worker thread for as long as the agent wants it. Retry policy inherits the same problem. A slow run and a hung run look identical from the outside, so you cannot tell whether to keep waiting or fire the request again, and firing it again at a legacy desktop app risks writing the same record twice. In a high-volume environment, this leads to rapid resource exhaustion. A handful of stuck agents can back up your entire message queue, causing a cascading failure that brings down the rest of your system. None of that is a reason never to use one. It is a reason to know what each one costs you, in seconds and in spend, before deciding how many of them your workflow should contain.

Why It Gets Worse as You Add Volume

One agent driving one desktop app is fine. The trouble starts when you have twenty of them, or one of them running a thousand times a day. When an agent runs as a standalone tool, someone will tolerate a long wait. But once that agent is wired into a multi-step pipeline, the entire chain inherits the agent's worst-case performance. This is a particular problem for teams managing automations at scale who need to move a steady volume of work through the same path every day.

Computer-use agents also frequently run slower than the humans they are meant to replace. When this computer use agent speed is plugged into a larger system, it becomes the bottleneck that governs everything around it. The fast steps either side of it stop mattering, because throughput is set by the slowest link and that link is the one whose duration you cannot predict.

Scaling out does not fix it, and here the desktop matters again. Each concurrent run needs its own Windows session on its own machine, so more throughput means more machines, and every one of those machines sits idle while a model decides what to click. You pay for the box and the inference at the same time, on every action, forever. Queue depth is where this shows up first. When the stage in the middle has no predictable duration, work arrives faster than it clears, and the backlog is not a spike you can size for because you do not know what you are sizing against. It is also one of the reasons automations break or stall on legacy desktop apps. Without a deterministic execution path, the system cannot optimize for speed or resource utilization. You are left with a chain that is only as fast as its slowest, most unpredictable link.

The Other Half Is Governing Them

Speed is the half you can measure. The other half is that you cannot say in advance what an agent is going to do.

A script exists before it runs. You can read it, and it does the same thing on Tuesday that it did on Monday. An agent that decides its own actions produces its behaviour during the run, so the only record is the log written afterwards. For one agent on one internal task, that is a tradeoff a team can live with. For twenty agents writing into twenty customers' systems of record, it is a governance problem, because nobody can answer what any of them will do to a given record until after it has already happened.

That question is not academic in healthcare, finance, or anywhere else the data is regulated. It is the gate a buyer puts in front of you before your integration goes live, and answering it from logs written after the fact is a far weaker position than answering it from the thing that is going to run. The longer version of that argument is here: audit trails for automated EMR writes.

Volume makes this worse the same way it makes latency worse. One unpredictable component is something a team can keep an eye on. Twenty of them, each making its own decisions against a live system, is not something anyone can keep an eye on.

The Word Automation Already Contains a Speed Claim

A system that is slower than a human operator is not an automation. It is a demonstration. You are building this because your customer's data has to reach their system of record faster than someone can type it in by hand. If the agent takes longer than that person did, the case you made for the integration never arrives, and you are paying inference costs to do the job more slowly than it was already being done.

The reason is that the agent works the task out again on every run instead of remembering it. A person who has done the job a hundred times does not re-read the screen to find the Save button. The agent does, every time, and each of those decisions costs a model call as well as a delay.

True automation must mimic that muscle memory. It must execute as code, not as a series of slow, expensive inferences. If you cannot say an automation will beat the person doing the work today, you have not justified building it. Apply that test one step at a time. A few steps will pass it with a model deciding what to do, and most will not, which is why what you do by default matters far more than what you do in the exceptions.

Where Minicor Sits

Minicor's answer is to make the deciding happen when the automation is built rather than every time it runs. Agents handle the parts they are good at: understanding complex legacy UIs and building the initial workflow logic. The automation is authored via a coding agent through Minicor's MCP. But the resulting automation is stored and executed as deterministic Python code.

By running as code rather than reasoning from scratch on every run, Minicor gets the predictability of an ordinary API call. Minicor reports one to two seconds per step, and since a run is step count times per-step time, the total is something you can work out for your own workflow instead of discovering it afterwards. Customers who have tested computer use against Minicor report Minicor is up to 11x faster at running the automation. That lets engineers treat a Minicor job as a standard API endpoint with a bounded latency ceiling. You can call a Minicor endpoint, expect a structured JSON response, and build a reliable timeout around the execution.

Minicor's own internal tests report 96-99% click accuracy. The bulk of the reasoning happens when the automation is authored and when it is repaired after a UI change, not while it is executing against the live system. Minicor is SOC 2 Type II certified and HIPAA compliant, with run and step level logs and a video replay of every run. The point of all of it is that the step you are composing into your workflow behaves like the other steps. It returns, and it returns roughly when you expected it to.

Conclusion

The hype around computer-use agents tends to ignore what happens to the clock once the demo ends. In a demo, a long wait is acceptable. In a pipeline that other stages depend on, it is a fatal flaw. You can build on a step whose duration you know. You can afford one step you have to design around. What does not scale is 100% computer use, a workflow where every step is that step, each one spending seconds and inference budget to rediscover something it already worked out yesterday, and none of them able to tell you what it will do before it does it.

Engineering teams need steps that behave like an API even when the thing on the other end is a UI. Minicor turns a legacy desktop workflow into an endpoint you can call and time. Keep the model for the steps that genuinely need one, and run the rest as code.