The real maintenance cost of UiPath brittle selectors

Industry reporting puts ongoing RPA maintenance at 15 to 20 percent of initial program spend per year, with HfS Research estimating that 70 to 75 percent of total RPA cost goes to implementation, maintenance, and support and only 25 to 30 percent to licensing. Forrester's RPA scalability work cited across the industry suggests over half of RPA portfolios stall before crossing ten robots, mostly under the weight of break-fix labor. A 2026 Automat post puts the steady-state effort split at 60 to 70 percent maintenance, 30 to 40 percent net new automations. A program quoted at $200K/year of license cost often runs $1M to $2M after you add the recurring services labor.

A UiPath selector is an XPath-like property bag (window title, control role, name, internal AutomationId, sometimes idx and parent path) recorded at design time and replayed byte for byte at runtime. Any drift mode that touches a recorded property breaks the resolver. The five canonical drift modes are label rewrites (Name change), theme changes (zero impact on the selector itself but fatal to any image-based fallback in the same workflow), AutomationId churn on an application patch, panel reorder that breaks XPath or idx-based paths, and modal popups inserted into the flow that the recorded path does not anticipate. Fuzzy selector matching reduces some breaks but introduces a different risk class: posting into the wrong control because the fuzzy match resolved an unintended element. That is the single worst break class for a regulated posting workflow.

Healing Agent is UiPath's runtime answer: when a selector fails, an LLM is invoked at runtime to propose a replacement against the live UI tree. It works in demos. In production it has three operating costs that any RPA Center of Excellence eventually has to put on a spreadsheet. First, every break is a token spend, scaling with queue volume; for a banking core or claims intake portfolio doing tens of thousands of runs per week, a 1 percent break rate means thousands of LLM calls per day. Second, latency stacks: a typical Healing Agent fix runs single-digit seconds in good cases and tens of seconds in bad ones, on top of the original step. Third, the same break can yield different selectors on different runs, which kills the deterministic audit trail any SOX-, HIPAA-, or SOC 2-bound workflow needs. Healing Agent does not eliminate the maintenance cost, it converts dev hours into per-break token spend and audit risk.

Move the model out of the runtime entirely. Mediar uses an accessibility-tree-first design: at authoring time a person walks the workflow once and Gemini Vertex AI converts the recording into a deterministic TypeScript workflow file in git. At runtime an 871-line Rust executor (crates/executor/src/services/typescript_executor.rs in the open-source Terminator SDK at github.com/mediar-ai/terminator) replays the file against the Windows accessibility tree via MCP. A grep for openai, anthropic, gemini, or claude in that executor file returns zero matches. There is no model in the hot path. Drift is absorbed by a four-tier element cascade (apps/desktop/src-tauri/src/focus_state.rs lines 168 to 196) and, for drift the cascade cannot absorb, a step-level ErrorStrategy::Fallback that jumps to a named recovery step and resumes the main path.

Tier 1 retries the failing element by its AutomationId, the OS-assigned identifier that survives most label and theme changes; a hit at this tier resolves in about 3 ms. Tier 2 retries by the parent window plus the bounding rectangle, which catches a renamed control that did not move. Tier 3 retries by visible text, the human-readable label a person would point to; a hit here resolves in about 40 ms. Tier 4 focuses the parent window so the run is in a known state and flags the step for human review. The cascade never silently types into a control the bot is not confident about. A break that survives all four tiers halts the run and pages a reviewer rather than posting into the wrong field.

A second drift layer lives at the workflow level. Every WorkflowStep in crates/executor/src/models/workflow.rs carries an on_error: Option<ErrorStrategy> and a fallback_id: Option<String>. ErrorStrategy is an enum with four variants: Stop, Continue, Retry, and Fallback. When a step is annotated on_error: Fallback with fallback_id pointing at another step, a failure routes to the recovery step and the run resumes the main path. The wiring is at crates/executor/src/mcp/executor.rs. This is how the workflow file absorbs structural drift the cascade cannot: a new modal dialog after Save (dismiss-modal step, then retry Save), a control type change from Edit to ComboBox (alternative selector step), a window split across two surfaces (window-switch step). The recorded file in git stays as it was; the runtime walks both layers; the diff for the new fallback step is a normal pull request.

Two real comparisons we have measured on customer estates. First, an LG-customer F&B chain running SAP B1 moved from UiPath to Mediar; their CFO reported a 70 percent reduction in total automation cost to the board, with the savings concentrated in RPA license cost and recurring maintenance hours per workflow per quarter. Second, a regional bank doing onboarding across Jack Henry green-screens cut their per-workflow ramp from 8 weeks to 2 weeks, mostly because the accessibility tree absorbed the patches that previously required a human-in-the-loop selector rebuild every release. Mediar's billing is $0.75 per minute of executor runtime, no per-seat licensing. The $10K turnkey program fee converts to credits with a bonus, so it is effectively prepaid usage. Drift handling is not a separate SKU because there is no runtime LLM cost on a break.

Yes. The Terminator SDK is MIT-licensed at github.com/mediar-ai/terminator. Install the npm package @mediar-ai/terminator, write a Selector chain in TypeScript, point it at any Windows app, then change the UI label and watch the four-tier cascade absorb the drift. The selector primitives, the locator, the cascade behavior, and the workflow executor are all in the repo. The cloud product wraps the same code with a Postgres queue, SOC 2 Type II controls, an authoring pipeline, and per-minute billing. The drift behavior of the cloud and the open-source SDK is identical because both call into the same Rust crates.