Robotic process automation with UiPath, decomposed into the three products you actually license.

The shape of a UiPath deployment

Most explanations of UiPath conflate the three products. The marketing surface treats “RPA software” as one category. Inside an enterprise deployment, the three live on different machines, on different release schedules, and on different cost lines in the operations budget. A purchase order for a UiPath rollout names all three and calls out a separate line for the AI bolt-ons (Document Understanding, AI Center, the newer Agent Builder).

The flow looks like this: a developer authors a .xaml in Studio, publishes it as a NuGet package to Orchestrator, and Orchestrator schedules a Robot to pull and replay it. The diagram below is three nodes because the architecture is three nodes.

What happens in production: the four-stage workflow lifecycle

The textbook UiPath lifecycle has four steps. Three of them feel normal to an engineer who has shipped any kind of software: authoring, publishing, executing. The fourth, remediation, is the one that decides whether your RPA Center of Excellence is paying for itself. It is also the one most marketing pages skip past.

Why selectors break, and what that costs

The Robot is, mechanically, a function from (workflow.xaml, target Windows session) to a sequence of UI Automation calls. The function is deterministic by design. The non-deterministic part is the target session: applications change, labels rename, layouts shift, DPI scales differ, a SAP transport ships a small panel reorder, a banking core vendor pushes a quarterly UI patch. When the live UI no longer matches the recorded selector, the Robot does the only thing it can do, which is throw.

UiPath ships a UI Explorer to help a developer rebuild the selector after the throw, and the activity library has a “Use Application/Browser” wrapper that adds retries and waits. Neither changes the underlying matching strategy: there is one selector per activity and it must match. When it does not, the run fails. Multiply that across an enterprise with two hundred workflows and a quarterly application update cycle, and the maintenance backlog stops being a footnote and starts being a roadmap.

This is the single largest reason UiPath rollouts stall. It is not the licensing cost, which is bounded. It is the developer time it takes to keep two hundred selector-based workflows alive against a UI estate that updates without coordinating with you.

What an accessibility-API executor swaps in for each piece

Once you decompose UiPath into Studio, Robot, Orchestrator, and the selector, each of the four pieces has a concrete replacement. The replacements are not bigger or fancier; they are different in shape. Studio (a canvas) is replaced by a recording session. Robot (a closed-source agent with a selector engine) is replaced by an open-source Rust crate that walks four match strategies. Orchestrator (a separately licensed server) is collapsed into a Postgres queue with a small API. The selector (one XPath per activity) is replaced by a four-strategy cascade.

The replacements below are not architectural sketches. Each one cites the file in the open-source Mediar repository (under MIT on github.com/mediar-ai/terminator) where the work happens.

The runtime, in code

The single uncopyable fact for a UiPath buyer evaluating an alternative is the size and shape of the production runtime. A UiPath Robot is a multi-megabyte Windows installer with selector engines for Win32, browser, Java, SAP, mainframe, and PDF. The Mediar production executor is a single Rust file, exactly 871 lines, at:

crates/executor/src/services/typescript_executor.rs

Its job, end to end, is: pull a workflow off a Postgres queue, build the MCP arguments (file URL, secrets, trace id), and call the MCP execute_sequence tool against a Windows session. The MCP server in turn wraps the Terminator SDK, which is the part that actually talks to Windows UI Automation, the same accessibility surface a screen reader consumes.

Grep the file for gemini, openai, claude, or anthropic: zero matches. The model is gone from the runtime by the time the executor runs. The intelligence is in the authoring layer that emits the TypeScript file in the first place. That split, AI at authoring time and plain Rust at runtime, is what most enterprise compliance teams want when they say they will not accept a model in the hot path.

The legacy applications this matters for

The four-strategy cascade and the accessibility-API approach were built for a specific class of applications: Windows desktop systems that emit accessibility trees but no APIs and no stable XPath selectors. Browser-based AI agents do not help here because the data does not live in a browser. UiPath does help, by virtue of having shipped Win32 and SAP and mainframe selector engines for over a decade, but the maintenance cost on these targets is also where UiPath rollouts stall the most.

The buying decision, written down

For an organization with a mature UiPath Center of Excellence, stable workflows that have run unchanged for two years, and a roadmap that does not require new automation against new applications, UiPath is doing its job and a migration is churn. Keep it.

For an organization that has paid for UiPath and watched it stall, where the queue of automation requests is longer than the team that ships them, where new applications keep landing on the roadmap (a banking core upgrade, a new SAP module, a switch from Cerner to Epic), the decomposition above maps to an alternative architecture. Each piece of UiPath has a mechanical replacement. The replacement is not a feature checklist match; it is a different shape that costs less per workflow and adapts when the UI changes underneath.

The honest pitch is: keep UiPath running for the workflows it already runs, route new automation requests to an accessibility-API executor, and let the maintenance cost of each architecture make the long-term decision for you.