What is RPA? The definition, and the one part every guide skips

The part everyone agrees on

Open any explainer and the definition is nearly identical: a software robot watches what a person does in an app, builds a list of those actions, then repeats them by driving the same graphical interface a human would use. Think of a macro that is not confined to one spreadsheet. It logs into systems, copies a value out of one screen, pastes it into another, clicks Submit, and moves to the next record. It is fast, it does not get bored, and it does not fat-finger a digit at 4pm.

The reason RPA exists at all is the API gap. In a clean world, two systems talk to each other directly through an interface built for machines. In the real world, the system holding the data, a 1990s SAP GUI, a mainframe green-screen, a core-banking terminal, exposes nothing a normal integration can call. The only interface it offers is the one a human stares at. RPA automates that interface. That is the whole pitch, and it is genuinely useful.

Every guide stops here, adds a list of benefits, and ends. But the definition describes what RPA looks like, not what makes one RPA bot survive a year in production while another dies on its first Tuesday. That difference comes down to a single mechanism nobody writes about.

The question every definition skips: how does the robot find the button?

“It clicks the button” hides the only hard problem in RPA. A screen is a grid of pixels. There is no button there, just colored rectangles and text. Before a robot can click anything, it has to decide which thing on screen is the button it wants. How it answers that question determines everything about whether the automation is robust or brittle. There are three ways to do it.

The third row is the same data a screen reader uses to announce a screen to a blind user. Every well-built Windows app already publishes it through the UI Automation API, whether or not anyone uses it. An RPA bot that reads that tree does not care where the button sits or what it looks like. It asks the operating system, “where is the control whose role is Button and whose name is Post,” and the OS answers with the current position. Move the button, restyle it, bump the resolution: the query still resolves.

What a robust locator actually looks like

This is not theory. In Mediar’s desktop recorder, the moment you click a control once, the code in apps/desktop/src-tauri/src/mcp_converter.rs reads the accessibility node under your cursor and writes a selector in this exact form:

// from a recorded click, generated at capture time
let element_role = ui_element.role();          // "Button"
let element_name = ui_element.name();           // "Post"

let selector = if !element_name.is_empty() {
    format!("role:{element_role} && text:{element_name}")
    //   ->  role:Button && text:Post
} else {
    format!("role:{element_role}")
};

No coordinate is saved. No screenshot is saved. The unit of memory is role:Button && text:Post, and selectors chain across windows, for example process:chrome >> role:Document. That single design decision is why the same recording survives the UI update that would have killed a coordinate-based or image-based bot. You can read the grammar yourself: the engine is the open-source, MIT-licensed Terminator SDK, described by its authors as “Playwright for Windows.”

Why this is the real cost of RPA

When teams say their RPA program “stalled,” they almost never mean it failed to build. They mean it failed to stay built. A bot bound to pixel positions or saved images needs a person to repair it every time a vendor ships a release, moves a field, or renames a label. Multiply that across hundreds of automations and the maintenance line item dwarfs the build cost. The locator mechanism you picked on day one is what sets that bill.

This is also the honest line between approaches. Browser-based AI agents are strong on modern web SaaS. But if your data lives in SAP GUI, an Oracle EBS form, or a Jack Henry green-screen, a browser agent has nothing to grab onto. The accessibility-tree approach exists precisely for the desktop and legacy layer where the others do not reach. For a closer look at why those locators differ, see selectors: Selenium paths vs the accessibility tree.

What happens when an RPA step runs

Stripped to its core, every RPA action is the same short loop, repeated thousands of times an hour. The locator strategy lives inside the first step, and it quietly decides whether the rest of the loop succeeds.

For the data-structure view of that loop, how a whole automation is stored and executed step by step, read how RPA automation actually runs.

So what should you actually use?

If you are evaluating RPA, the most useful question is not “what is RPA” but “how does this tool find elements, and what happens when the UI changes.” The mature platforms, UiPath, Automation Anywhere, Blue Prism, Power Automate, can all do the work. The difference shows up in the maintenance bill and in whether they reach your legacy desktop apps at all.

Mediar’s bet is the accessibility-first one described above: watch a workflow once, execute it through Windows accessibility APIs, self-heal when labels and layouts shift, and keep the engine open source so the locator logic is inspectable rather than a black box. Pricing is usage-based at $0.75 per minute of runtime with no per-seat licensing. It is SOC 2 Type II certified and HIPAA compliant, and runs on-prem or in the cloud. If your workflows are stuck on SAP, Oracle, a core-banking system, or an EHR, that is the layer it was built for. If everything you automate is modern web SaaS, a browser-native tool may serve you just as well, and it is fair to say so.