An argument with source code
AI agents replace UiPath only when the model runs at authoring time, not at runtime.
Every other take on this question lands in one of two places. UiPath says agents complement RPA, never replace it. The agentic AI crowd says the bots are dying and a model at runtime will replace them. Both are wrong in the same way. They skip the question that decides whether the replacement holds in production: where does the model live in the workflow lifecycle. The version that ships at enterprise scale puts it at authoring time. The version that demos beautifully and stalls at audit puts it at runtime.
Direct answer (verified 2026-05-01)
Are AI agents replacing UiPath RPA? Sometimes. The agent architectures that hold up in audited enterprise workflows split the model and the runtime: the model converts a single recording into a deterministic workflow file, then a plain code executor replays that file with no model in the hot path.
UiPath has confirmed the same split publicly: the classic Robot still runs deterministic RPA, and UiPath Agent Builder is bolted on for the cognitive layer. The pure agentic replacement (LLM-in-the-loop on every UI step) has not shipped at scale yet, anywhere. The Mediar runtime is open source at github.com/mediar-ai/terminator.
The boundary line
Picture a workflow lifecycle as four stages. Someone records the target workflow. Some component converts that recording into a replayable artifact. The artifact lives somewhere. Something reads it and drives the OS. The boundary line is the question of which of those four stages the model touches.
UiPath puts a human (the certified Studio developer) at stage two and a deterministic Robot at stage four. Pure agentic AI puts the model at stage two and at stage four. The replacement that actually works puts the model at stage two only and ships deterministic code to stage four.
Where the model lives in a working AI-agent replacement
Recording
human walks the workflow once, six event types are captured
Authoring (model lives here)
Gemini Vertex AI converts the recording into a TypeScript workflow file
Workflow file in git
deterministic .ts artifact, code-reviewed, versioned
Executor (no model)
871-line Rust crate replays the file via MCP and Windows accessibility APIs
The runtime, in source you can read
One way to test whether a vendor genuinely puts the model at authoring is to read the runtime. Mediar's production executor is a single Rust file, exactly 871 lines, at:
crates/executor/src/services/typescript_executor.rsIts job is mechanical: 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 wraps the Terminator SDK, which is the part that talks to Windows UI Automation. Grep the file for gemini, openai, claude, or anthropic: zero matches. The model is gone from the runtime by the time this file runs. That single property is what makes the AI-agent framing pass an enterprise compliance review instead of getting shelved.
“The four-strategy match cascade in apps/desktop/src-tauri/src/focus_state.rs, lines 168 to 196, walks automation id, then window plus bounds, then visible text, then parent window. Most application updates are absorbed by one of the first three. A single selector miss does not fail the run.”
typescript_executor.rs at runtime, github.com/mediar-ai/terminator
Why pure agentic systems stall at the door
Three things break when the model runs at every step. Latency stacks: a single LLM call per UI action turns a 90-second invoice workflow into a 20-minute one, which is unacceptable on a queue of 5,000 invoices a day. Audit fails: a compliance officer cannot sign off on a workflow whose action sequence is decided by a non-deterministic model on every run, because the action set is different on every run by definition. Regression hides: a model version bump silently changes which button gets clicked, and the reconciliation team finds it three days later in a downstream number that does not balance.
None of those failures are theoretical. They are why every enterprise pilot of a fully agentic desktop agent we have seen ends in a procurement note that says the architecture is not production-ready. The hybrid split keeps the parts of agents that are useful (intent inference from a recording, semantic labeling) and removes the part that is not (a model in the replay loop).
The shape of a workable AI-agent replacement
Five properties decide whether an AI-agent claim against UiPath holds in production. They are mostly architectural, not feature checklist items.
When an AI agent actually replaces a UiPath workflow
- The model runs once at authoring time, not at every step
- Output is a reviewable artifact (a TypeScript file in git, not a chain of in-flight model calls)
- The runtime reads the artifact and calls the OS, with no model in the hot path
- When the UI shifts, a fallback cascade absorbs the change instead of throwing
- Every step writes an audit row your compliance team can read without asking what the model decided
When the AI-agent pitch falls over
- An LLM is called on every UI step at runtime (latency stacks, token bills compound, behavior drifts release to release)
- The agent has no recording layer and tries to plan from a screenshot every run (works in demos, fails on the 200th SAP transaction of the day)
- Selectors are still pixel matchers under the hood; the AI just renames them
- There is no deterministic artifact for an auditor to read; the workflow is the model's prompt
What this means if you are sitting on a stalled UiPath rollout
The honest path is parallel, not migration. Stable workflows that have run unchanged for 18 months on UiPath are paying for themselves; touching them is churn. The workflows worth moving are the ones where the selector maintenance has stalled development for more than three months, or where the queue of new automation requests is permanently longer than the team that ships them. That is the pattern we see most often at mid-market banks on Jack Henry, Fiserv, or FIS, and at insurance carriers on claims intake against legacy desktop systems.
For those workflows, the AI-agent replacement is not a feature checklist match against UiPath. It is a different architecture with the model at authoring and plain code at runtime. Read the executor source before you sign anything. If a vendor cannot point at the equivalent file in their stack, the boundary line is somewhere you do not want it.
Move one stalled UiPath workflow onto an AI-agent replacement, on the same call.
We record the target workflow once, watch the authoring layer emit the TypeScript file, and replay it against your environment. No slides, no benchmarks, just the actual artifact that ships.
Frequently asked questions
Are AI agents really replacing UiPath RPA?
In specific workflow categories, yes. The replacements that survive enterprise audit and reliability share one architectural choice: the model runs at authoring time, not at runtime. A human records the workflow once, the model converts the recording into a deterministic workflow file, and the runtime replays the file with no model in the loop. Pure agentic systems that call an LLM at every UI step have not held up at scale. UiPath itself has split its product line along the same boundary: classic RPA Robot for execution, AI Center and Agent Builder for the bolted-on cognitive layer. The category name is moving from RPA to agentic automation, but the production architecture is still hybrid.
Why does putting the model at runtime fail in production?
Three reasons. First, latency: an LLM call per UI action stacks into 30 to 60 seconds of wall time per step, which is fine in a demo and unacceptable on a queue of 5,000 invoices. Second, audit: a compliance officer cannot sign off on a workflow whose action sequence is decided by a model on every run because the action set is non-deterministic by definition. Third, regression: a model upgrade silently changes which buttons get clicked, and you find out three days later when reconciliation breaks. The hybrid version (model at authoring, code at runtime) keeps the model where its strengths matter (understanding intent from a recording) and out of the place where determinism matters (replay).
How can I tell whether a vendor's AI agent runs the model at runtime or only at authoring?
Ask one question: what is the exact artifact your runtime reads, and what programs interpret it. If the answer is 'a prompt and a screenshot', the model is in the runtime. If the answer is 'a code file in git that we generated once and now replay', the model is at authoring. Mediar's runtime artifact is a TypeScript file. The executor that reads it is a 871-line Rust crate at crates/executor/src/services/typescript_executor.rs in the open-source repo at github.com/mediar-ai/terminator. You can grep that file for gemini, claude, openai, or anthropic and find zero matches. That single check disambiguates the architecture.
What about UiPath Agent Builder and Autopilot? Isn't that already an AI-agent replacement for UiPath RPA?
UiPath Agent Builder is an addition to the existing platform, not a replacement. The base UiPath Robot still runs the same selector-based architecture it has run since 2014; Agent Builder bolts agentic capabilities on top via the existing Robot runtime. UiPath has been clear in its own communications, including the 2024 Forward conference and recent diginomica coverage, that the strategy is hybrid: keep deterministic RPA for the workflows that need it, layer agents on top for the parts that need cognition. The marketing pivot to agentic automation is real; the engineering pivot is gradual. Buyers should treat 'replacing UiPath RPA with an AI agent' the same way: the workflows that move are the ones where a deterministic replay is enough, paired with a smarter authoring layer.
What does an AI-agent replacement look like for a Windows desktop workflow against SAP GUI or a banking core?
Concretely: a developer or analyst opens the Mediar desktop app, hits record, and walks the workflow once on the same machine that normally runs it. The recorder captures six event types defined in apps/desktop/src-tauri/src/recording_processor.rs at line 250: button_click, browser_click, text_input_completed, browser_tab_navigation, application_switch, file_opened. Those events plus snapshot accessibility trees go to the authoring pipeline, which emits a TypeScript file. The file is checked into git and queued. From then on the executor pulls it off the queue, calls MCP execute_sequence, and the Terminator SDK drives Windows UI Automation, the same accessibility surface a screen reader uses. Re-recording for a new workflow takes hours, not the weeks of selector authoring a comparable UiPath rollout would take.
When the application UI changes, what happens?
A UiPath Robot resolves a recorded XPath-style selector at replay; a UI change that breaks the selector throws and the workflow fails. Mediar's executor walks four match strategies in apps/desktop/src-tauri/src/focus_state.rs lines 168 to 196: automation or accessibility id, then window plus bounds, then visible text, then parent window focus. Most enterprise UI patches (a label rename, a panel reorder, a control id change) are absorbed by one of the first three. The point is not magic recovery. It is that a single selector miss does not fail the run, which compounds at any organization with more than a handful of workflows touching the same UI estate.
What does this cost compared to UiPath?
UiPath public list pricing starts around $420 per month per attended Robot, plus per-Studio-seat developer fees and per-tier Orchestrator licensing. Enterprise contracts at the RPA Center of Excellence level commonly land in the $100K to $500K-plus range for the first year, with annual renewals. Mediar charges $0.75 per minute of executor runtime, plus a $10K turn-key program fee that converts to credits. A workflow that runs 10 minutes a day costs roughly $1,575 a year in runtime. The comparison the marketing site cites (around 20% of UiPath cost) is at typical small-to-mid enterprise volumes; savings shrink at very high concurrency and grow on long-tail workflows.
Should we keep UiPath running while we test an AI-agent replacement?
Yes. The honest path is parallel. Keep UiPath running for stable workflows that have not changed in months and pay for themselves at current selector maintenance costs. Route new automation requests, especially the ones stalled for selector breakage, to the AI-agent authoring path. Compare in production over a quarter on three numbers: time from request to first run, count of failed runs per 1,000 invocations, and developer hours per workflow per month. Whichever architecture wins the third number wins the long term, because it is the only one that compounds.
Where does this not work?
Two places. First, browser-only flows on modern SaaS where a stable API exists. If the data lives behind an OpenAPI spec, an API-first integration beats both UiPath and a desktop AI agent on cost and reliability. Second, workflows that need true free-form planning that cannot be captured by recording (multi-day case investigations, fraud triage, novel exception handling). For those, agentic systems with the model at runtime are still the right answer. The boundary is recording-shaped repetitive work on legacy desktop systems with no API, which is where UiPath rolled out in the first place and where the selector-vs-accessibility tradeoff actually matters.
Adjacent guides on the same topic
Keep reading
Robotic process automation with UiPath, decomposed into the three products you actually license
Studio, Robot, Orchestrator. The mechanical job each one does, where each one fails in production, and what an accessibility-API executor swaps in. Source-cited against an open-source 871-line Rust runtime.
RPA is two regex bets. If you want to know whether a bot will hold up, read those regexes.
Every working RPA system bets on which UI attributes survive a release. Two regular expressions in 144 lines of Rust make that bet visible: id tokens get stripped, role plus name are what the diff layer trusts.
Mediar: the company, the founders, and the open-source SDK
Background on the Y Combinator backed company at mediar.ai, the open-source Terminator SDK on github.com/mediar-ai/terminator, and how the open-source pieces fit into the commercial product.