How to Automate a Legacy System That Has No API (Without Waiting for IT)

Every enterprise automation project we scope hits the same wall eventually, and it's never the AI. It's a system that has no API. A carrier portal the claims team logs into forty times a day. An ERP screen from 2009 whose vendor quotes eighteen months and six figures for integration work. A government filing site with no programmatic path by design. A tool that has an API on paper, gated behind an enterprise tier nobody will approve.

The traditional answer is RPA: record a script that drives the interface, then maintain that script forever, because it breaks whenever a page changes. Most RPA deployments we inherit are in a maintenance death spiral. Computer use agents are the current alternative, and after this month's model releases they're finally worth a serious look. This post covers when they make sense, what changed, and what has to be true before you point one at a production system.

What changed recently

Computer use has demoed well and deployed badly for two years, for one structural reason: the screenshot-reason-click loop. Every action was a full round trip, so a forty-click workflow meant forty inference calls, and somewhere in the middle the agent lost the thread or the page moved.

Muse Spark 1.1, which Meta shipped this month with computer use across desktop, browser, and mobile, made two changes that matter operationally. It generates batches of actions per step rather than reasoning one click at a time, which collapses the round-trip count. And it was trained to decide when to write a script instead of clicking at all.

That second one is the interesting part, and it's counterintuitive for a computer-use feature. Given "update the status field on these 200 records," a click-driven agent does 200 rounds of interface work. A model trained to notice a bulk path will reach for a CSV import, a batch endpoint, or a query — whatever the application already supports — and finish in one.

On our test workflow, roughly half the steps we'd scoped as "computer use" turned out not to need it once the model was allowed to notice that two of the three systems had usable programmatic paths after all. That's a useful and slightly humbling finding.

The rule: computer use is a last resort, and should be

The most valuable thing you can do before starting one of these projects is an honest inventory of what's actually unavailable.

Does an API exist that you've been told is unavailable? Frequently the answer is that it exists but is gated, undocumented, or owned by a team that hasn't responded. Two weeks of procurement is cheaper than a permanent automation you have to babysit.

Is there a bulk import or export path? Most enterprise systems have CSV somewhere. It's ugly, it's supported, and it doesn't break when someone redesigns a page.

Is there a database you can read directly? Read-only replica access solves a surprising share of "we need to get data out of X" problems.

Only when all three are genuinely no should you drive the interface. Computer use is slower, costlier per task, and more fragile than any of those alternatives. It earns its place solely because the comparison isn't against a clean integration — it's against a human doing data entry.

What the economics look like

When it does apply, the case is usually overwhelming, because the baseline is loaded human cost. A claims-status-check workflow taking a person four minutes across two portals, run 300 times a week, is roughly 20 hours of staff time. The agent equivalent, at current model prices, is a few dollars a day in tokens plus the infrastructure to run it.

Two costs people underestimate when they build the business case:

Maintenance is not zero. It's much lower than RPA, because the model adapts to a moved button in a way a recorded script cannot. But interfaces change in ways that break intent, not just layout, and someone owns that.

Review is not zero. Anything touching money, customers, or compliance needs a human approval step, and that step has a real cost per transaction. Budget it into the ROI or the model will flatter itself.

Guardrails, in the order we apply them

Computer use is the highest-blast-radius capability in the current toolkit, because the agent works through the same interfaces an employee does and inherits whatever that account can reach. Non-negotiables:

A dedicated service account, scoped minimally. Never a person's credentials. What the agent can do should be limited by the system's own permissions, not by instructions in a prompt.

A disposable environment. A VM or container destroyed after each run. Clean state per execution, limited reach if something goes wrong.

Approval gates on anything irreversible. Payments, deletions, outbound communications, customer-record changes. The agent proposes and a person approves. In our workflows this fires on a small minority of steps and has caught real errors.

Read-back before write. Any action with side effects re-reads the current value first. The classic failure in long automations is acting on data you read twenty steps ago.

Full trace capture and a step ceiling. Screenshots, actions, and reasoning retained; a hard cap on actions per run so a confused loop ends rather than continuing until someone notices.

None of this is model-specific. It's the price of admission, and it gets more important as tokens get cheaper, because cost stops being the thing that limits how much an unattended agent can do.

Where this actually belongs

The projects where computer use has clearly paid for itself, in our work: insurance carrier portals, legacy ERP screens where the vendor integration quote exceeded the automation's entire budget, and regulatory filing systems with no programmatic path. All share a shape — high-volume, structurally repetitive, no API coming, and a human currently doing it.

The projects where it's been a mistake: anything with an API that someone didn't want to wait for, and anything low-volume enough that the guardrail overhead exceeds the labor saved. If a task runs eleven times a month, a person should keep doing it.

The technology finally works well enough that the decision is a business question rather than a feasibility question. That's the actual news, and it means the analysis above matters more than the model choice.