Skyvern as RPA: what it automates, and where the browser boundary falls

What Skyvern actually is

Skyvern is an open-source browser-automation agent. Under the hood it is a Playwright-compatible runtime with a model layer bolted on: you describe a task in plain language, and instead of running a recorded click path, it reads the rendered page (both the DOM and the pixels) and decides what to do next. It handles the messy parts of real web work, including captchas and 2FA, and exposes both an SDK for developers and a no-code workflow builder for everyone else.

The reason this counts as RPA, and not just a chat toy, is that it executes end-to-end unattended runs against live websites. The reason people reach for it over UiPath or Automation Anywhere is the maintenance math: a vision-and-reasoning agent does not snap the moment a button moves twelve pixels or a field gets renamed. That is a real and useful difference. It is also entirely a story about the web surface.

The benchmark behind the claims

When Skyvern talks about state-of-the-art performance, the number is from WebVoyager. Read it carefully, because it tells you precisely what the tool is good at.

Fifteen sites: shopping, maps, travel, search, the kind of public web properties you reach from a stock browser. There is no SAP screen in the suite, no green-screen terminal, no Citrix-published desktop client, because those are not web pages. The 85.85% is an honest measure of browser competence. It says nothing about the desktop, and it was never meant to.

How a Skyvern run executes

Watching one run go by makes the boundary obvious. Every step lives in a browser tab.

The anchor: there is no desktop runtime

Here is the single fact that the ranking guides on this topic leave out. The word “RPA” historically covers desktop work: data entry into SAP GUI, posting to a mainframe terminal, keying a claim into an insurance thick client. Skyvern’s entire action space is the browser. No tier, free or enterprise, ships a Windows desktop runtime that can click a button in a native application that is not a web page.

That is not a knock on Skyvern. A browser agent that tried to also be a desktop agent would be two products. It is just the line you need to know before you scope a project. If your target app opens in Chrome, Skyvern is in play. If it opens as a Windows executable, a Citrix session, or a terminal emulator, the browser agent has nothing to grab onto, and you need a different mechanism entirely.

That different mechanism is the OS accessibility tree, the same interface screen readers use. Every Windows control exposes a role, a name, and a value to the accessibility API whether it lives in a browser or in SAP GUI. Mediar reads that tree to drive the desktop apps a browser agent cannot see, and it self-heals on a UI change for the same reason Skyvern does on the web: it matches on labels and roles, not on pixel coordinates or recorded selectors. The open-source Terminator SDK is how teams script that layer directly.

So how do you choose?

Do an honest inventory of where the work is stuck. If your backlog is SaaS dashboards, web portals, public lookups, and e-commerce flows, a browser-native agent is the right tool and Skyvern is a credible pick. If the bottleneck is a Windows desktop app with no usable API, an SAP GUI, an Oracle EBS form, a Jack Henry or Fiserv core, an Epic or Cerner thick client, or a mainframe green-screen, then no amount of browser cleverness reaches it, and that is exactly the layer Mediar was built for.

Plenty of real automation programs need both. The mistake is assuming a browser agent’s benchmark score transfers to the desktop. It does not, because the desktop was never on the benchmark.