Running Computer-Use Agents on Systems That Have No API

Short answer: most legacy industrial systems will never get a modern API. Computer-use agents are the first class of automation that doesn't need one—they drive the existing interface the same way your team does, which means you can ship useful automation without touching the system of record.

The legacy-systems problem at mid-size industrial

Walk into any mid-size manufacturer or distributor and you'll find a stack nobody designed on purpose: an ERP from the Bush years, a warehouse system from a vendor that was acquired twice, a proprietary pricing portal your biggest supplier makes everyone use, and a dozen internal spreadsheets that exist because none of the above talks to each other. This is not a data-quality problem. It's an access problem: most of the useful data is trapped behind interfaces that were built for humans to look at, not for machines to consume.

Why API-first integration usually fails here

• No API exists. The AS/400 screen is the API. The vendor portal is the API. Your only programmatic access is pretending to be a human.
• The API exists but IT won't open it. Security team said no. The upgrade hasn't landed. The credentials live with a consultant who left in 2019.
• The API exists but it's broken. Half the endpoints return stale data. The vendor charges per-call fees you can't justify for a $200/mo workflow.
• Integration vendors quote $200K for something worth $20K. The middleware industry was built on this gap, and it prices itself out of mid-size budgets.

What computer-use agents do differently

The agent logs in the same way your team does. It takes a screenshot, reasons about what's on screen, clicks, types, and reads the result. No API keys, no middleware, no change request. You write the task in plain English, give it credentials to an existing account, and check the output. If the interface changes, the agent adapts the way a human would—it still recognizes the “Submit” button, even if it moved.

Three deployments worth trying first

• Supplier portal pricing & availability checks — an agent logs into your top 10 vendor portals nightly, pulls current price and stock for the SKUs you care about, and writes the results to a sheet or your CRM. What used to be a buyer's Tuesday morning is now a 6am batch job. Pairs naturally with procurement automation.
• PO and shipment status aggregation — an agent visits each carrier and vendor portal, collects open PO statuses, reconciles them against your ERP, and flags anomalies. Customer service stops calling around; they open one screen.
• Compliance and warranty submissions — an agent fills out the OEM warranty form, the safety-incident filing, the monthly regulatory upload—the high-volume, low-variation work that always runs late because nobody wants to do it.

Reliability patterns you want from day one

• Human checkpoints on anything irreversible — the agent proposes a PO; a human approves before it submits.
• Idempotent rerun — if the agent crashes halfway through a batch, restarting doesn't double-post. Build this in on day one; don't discover it after the fact.
• Structured output, not screenshots — the agent should hand you JSON or CSV, not a folder of PNGs. The reconciliation logic lives on the structured output.
• Logged, auditable sessions — every action the agent took, stamped and replayable. This is how you pass an audit and how you debug when a vendor changes their layout.

What it doesn't replace

Computer use is not a substitute for fixing the data that matters long-term. If your item master is a mess, an agent will productively re-key the mess faster than before. You still need catalog-truth work and, for customer-facing AI, an AI-ready infrastructure layer. Think of it as the automation that pays for the data cleanup, not a substitute for it.

Next read: the computer-use primer and how we deploy agents on retainer.