How RPA automation actually runs

An automation is a sequence of steps, not a recording

When people say “the robot does the task,” the robot is walking an ordered list. In Mediar’s executor, the unit of work is a WorkflowSequence: a list of WorkflowStep entries plus the variables and inputs they read from. You can see the exact shape in the Rust source at crates/executor/src/models/workflow.rs.

A single step is small and explicit. It names a tool_name (the action), the arguments that action needs, a timeout, a retry_count, and, crucially, an on_error rule. That last field is where the resilience lives. Here is one step that posts an invoice number into a SAP field:

Read it in plain terms: find the text field whose accessible name is “Vendor invoice no.” and type the invoice number into it. Give it 15 seconds. If it fails, try up to two more times. If it still fails, do not stop the whole run; jump to the reopen_sap_transaction step and recover. Nothing in that step references a pixel coordinate or a recorded XPath. It references the field by what the operating system already calls it.

What happens when one step fires

The executor does not poke at the screen directly. It dispatches each step as a tool call over MCP to the machine running the target apps, which reads and acts on the accessibility tree and returns a result. On a failure, the step’s on_error rule decides what happens next.

Because the target is identified by its accessible name rather than a screenshot or a brittle selector, a cosmetic change to the UI, a moved panel, a restyled button, usually does not move the name. That is the mechanism behind “self-healing”: there is no pixel matcher or recorded coordinate to invalidate in the first place.

The part most RPA tutorials skip: the failure model

Anyone can record a happy path. The hard part of production automation is what happens when something goes wrong, and that is exactly where generic RPA guides go quiet. Mediar splits failures into two categories in crates/executor/src/config/retry.rs.

For the infrastructure bucket, the default retry policy is concrete and lives in the same file:

On top of that engine-level retry, every step you author has its own on_error choice from four options: stop the run, continue past it, retry the step a set number of times, or fallback to a named recovery step. A traditional bot gives you one global try/catch the developer has to wire up. Here the failure plan is part of each step’s definition.

Selector-based RPA vs accessibility-tree automation

The engine design is not academic. The payoff shows up as time and money on real desktop workloads. At one mid-market insurance carrier, claims intake went from 30 minutes per claim to 2 minutes, which their own AP-team headcount math put at roughly $750K a year. A regional bank cut onboarding from 8 weeks to 2 weeks. A regional healthcare group saved about $210K a year on patient intake. None of those run on a clean API; they run on SAP GUI, banking core screens, and EHR clients, the legacy desktop layer where an accessibility-tree agent works and a browser-only agent cannot reach.

When RPA automation is the wrong tool

Automating through the UI is the right move when there is no clean way in underneath it. If a system already exposes a stable API, call the API; it will be faster and steadier than driving a screen. And if the workflow is a brand-new browser-only SaaS flow, a browser-based agent may fit better than a desktop one. Mediar is built for the opposite case: the no-API legacy desktop systems where teams have either watched a UiPath project stall or are staring at a six-figure implementation quote. That is where reading the accessibility tree earns its place.