Picture your Monday. A procurement system your company has run for years pushes a new release over the weekend, and by morning the bots that move purchase orders between it and your banking portal have stopped matching anything. They were built on CSS classes, IDs and xpaths, and those are gone. Someone on your team will spend the week rebuilding them. You have done this before, and you are wondering if there is a way to stop.
Coasty, an agent company, has written a post aimed at exactly that situation: computer use agents versus API-only automation in legacy enterprises. Its case against the maintenance treadmill is simple. RPA bots break when the interface changes. API-only automation, it says, "handles the clean cases, but legacy ERP, mainframe, and Citrix environments rarely expose stable APIs that cover the full workflow." So its answer is an agent that reads the screen, clicks and types the way a person would.
The line you will probably remember is this one: "A standard operating procedure written in plain English is already almost a prompt." If you have a binder of procedures for the people who run those portals, that sentence lands.
Before you take the post to your manager, check the numbers, because two of them carry the argument and neither is Coasty's own measurement. The claim that "up to 40 percent" of an RPA team's time goes to maintenance is attributed to unnamed analysts. The "50 percent or more" reduction in manual work is not a result at all. It is a threshold the post invents for deciding when to expand a pilot. Treat both as framing, not evidence.
What survives without them is the split the post recommends, and it is more honest than its headline. Keep RPA for "stable, high-volume, backend tasks." Use computer use agents for changing interfaces and exception-heavy work. Retire the brittle bots one process at a time. For you, that means no big-bang replacement, just a pilot on the process that breaks most. And it is an argument for both approaches, not against APIs.
Then comes the turn that the APIs.io catalog adds. Coasty is itself an API company. Its listing has 8 API pages, and they are the control plane for exactly the pilot the post describes. The Machines API and the Sessions API provision the virtual desktops. The Workflows API is where a repeatable procedure lives. The Runs API and the Schedules API execute and repeat it. The Predict API is the screen-reading step itself. The agentic access profile counts 72 operations, 42 of them acting and 5 human-in-the-loop. So the agent that stands in for the missing legacy API is driven by a well-described modern one. If you adopt it, your team's day-to-day work would be calling APIs, not clicking.
The measurement backs that up. Coasty scores 62.5 on the Kin Score, which is a strong band, with access clarity at 84.2, operational transparency at 68.4 and developer ergonomics at 67.3. Its Agent Readiness score is 48.7, agent-native, with idempotency, error semantics, OpenAPI examples, an MCP server and agent skills all lit. For you, that means something practical: a run you retry should not do the same thing twice, and errors should be readable by whatever is orchestrating the agent.
The record also has gaps, and the catalog filed them against Coasty. Contract governance sits at 4.5. On the agent side, reversibility and dry-run mode are unlit. That second gap matters most to you. The product's pitch is acting on legacy systems that cannot be rolled back, and a documented way to rehearse a run before it clicks anything is the missing piece. If the pilot touches your banking portal, you would want that rehearsal before you want anything else.
So here is what you take away. The vendor's headline asks you to choose a side, but its own argument and its own API record say otherwise: keep RPA where it is stable, put an agent where the screen keeps changing, and expect to manage that agent through an API. Discount the two statistics, since neither was measured by Coasty. And before you let it near anything irreversible, ask where the dry run is.
Read the original: https://apis.io/2026/11/04/coasty-argues-against-api-only-automation-and-ships-a-72-operation-api/