Agent adoption on legacy enterprise systems
The reason your last RPA project stalled was not the model. It was the review loop. Here is the 4-week analyst-led pilot we run instead, and the one mechanism that makes it ship without an RPA Center of Excellence in the middle.
Direct answer (verified 2026-05-07)
Skip the multi-quarter Center of Excellence cycle. Run a 4-week analyst-led pilot on one workflow that already lives on a legacy Windows desktop app: pick a 5-10 minute task that runs 100+ times a week, record it once in step-by-step mode so a domain expert approves each captured action, replay against the OS accessibility tree (no pixel matchers, no selectors), and measure runtime cost against current FTE cost. Expand workflow by workflow, not platform by platform.
Source: Mediar product behavior at apps/desktop/src-tauri/src/workflow_recorder.rs:28 and the public turn-key program at mediar.ai/turnkey.
Why most adoption plans get stuck before week one
The standard enterprise AI agent rollout plan reads like a consulting deck. Establish a Center of Excellence. Train two certified developers. Build a Phase 1 workflow inventory. Pick a showcase process. Build it in Studio. Hand it to ops. Stage a steering committee.
By the time anyone sees a working bot, two quarters have passed and the analyst whose workflow you automated has changed three steps that the developer never saw. The bot fails on the first day in production. The CoE blames the analyst. The analyst stops trusting the team. The next workflow does not get a champion.
The expensive part of adoption is not the agent. It is the round trip between the person who knows the workflow and the person who builds the bot. The cheapest way to fix that is to make those two people the same person.
The one mechanism that changes the math
The Mediar desktop client opens with a Recording Mode dialog with two options. Continuous captures everything; it is the right choice for a quick first draft. Step-by-step is the one that matters for adoption: the recorder pauses after every meaningful event (a Click, a Keyboard input, a Hotkey) and asks the operator to approve, edit, or discard the captured action before the next one is recorded.
The pause is enforced by a static atomic in the Rust recorder at apps/desktop/src-tauri/src/workflow_recorder.rs:28: a STEP_BY_STEP_RECORDING: Lazy<Arc<AtomicBool>> that gates the event stream. When it is true, the recorder routes each event through a PendingAction payload (the WAITING_FOR_EVENT enum at line 41 tracks whether we are waiting on a click, a key press, or a hotkey) and surfaces it to a small review window. The analyst is the gatekeeper, not the model.
Why this matters for adoption: the analyst who runs the workflow today is the one who signs off on every captured action. There is no handoff from a developer to ops. The output is a workflow file the analyst can read and rerun on the same machine, against the same desktop app, the same day.
The recording loop
The 4-week pilot, week by week
The pilot is scoped so that an analyst, an IT contact, and a finance sponsor can finish it without anyone asking permission to start a new program. Each week has one deliverable and one decision.
Week 1 — Pick the workflow, not the platform
One workflow that already runs 100+ times a week on a legacy Windows desktop app: SAP GUI, Oracle EBS, Jack Henry, Fiserv, Epic, eClinicalWorks, or a mainframe terminal. 5-10 minutes per execution. The analyst who runs it today is in the room. No developer required.
- Run a stopwatch on three real executions. Write down the median, the worst case, and where the analyst pauses to think.
- Multiply by frequency. If the math is under 50 hours a year of saved analyst time, pick a different workflow.
- Get IT to confirm the desktop app is reachable on a standard Windows VM. That's the only IT ask in week 1.
Week 2 — Record once in step-by-step mode
The analyst opens the desktop app, picks 'Step-by-step' in the recording mode dialog, and walks through one execution end to end. After every meaningful event (a click, a typed value, a hotkey) the recorder pauses and asks the analyst to approve, edit, or discard. The output is a workflow file the analyst can read.
- The pause is enforced by a static atomic in the recorder (
STEP_BY_STEP_RECORDINGatapps/desktop/src-tauri/src/workflow_recorder.rs:28) that gates every Click, Keyboard, and Hotkey event. - The analyst owns the review loop. There is no separate "developer hands ops a finished bot" step.
- If the analyst gets it wrong, they redo a single step, not the whole recording.
Week 3 — Replay against the accessibility tree, not pixels
The agent re-executes the recorded workflow. The input layer is the OS accessibility tree (the same interface a screen reader uses), so it finds each control by role and automation_id, not by pixel position or fragile selector. When SAP ships a support pack and labels move two pixels, the workflow does not break.
- Run the workflow against ten real input cases the analyst has handled before. Compare every output field by field.
- The execution log records (step_id, tool_name, before, after, duration_ms) per step. The analyst signs off on the first ten clean runs.
- Anything ambiguous gets surfaced as
ErrorCategory::Unknownfor human review, not silently retried.
Week 4 — Measure runtime cost vs FTE cost, then decide
The agent has now run the workflow at scale for at least one full week. Pull the numbers. At $0.75 per minute of runtime, an automation that runs in 2 minutes costs $1.50; the same workflow at 20 minutes of analyst time costs roughly $13 in fully loaded labor. If the math is not at least 5x, kill the pilot. If it is, queue the next workflow.
- The $10K turn-key fee converts to credits, so week 4 is mostly checking that real billing matches the projection.
- The next workflow gets recorded by the same analyst, in the same way. There is no separate "scale-out" project.
- If you have an existing RPA Center of Excellence, this is when you tell them what the analyst built without them.
The four blockers the pilot is designed to dissolve
Every stalled enterprise AI agent project we have seen failed for one of these four reasons. The pilot above is shaped to take each one off the table by week two.
The CFO blocker
Six-figure RPA quotes that promise nothing for nine months. Mediar runs at $0.75 per minute of execution with a $10K program fee that converts to credits. A 4-week pilot scoped to one workflow is below the threshold most CFOs need to approve in a meeting.
The IT blocker
No new API. No new firewall rule. The agent runs on a Windows VM in your perimeter and reads the apps the same way a screen reader does. SOC 2 Type II, HIPAA, and on-prem available.
The analyst blocker
The analyst who runs the workflow today owns the recording. Step-by-step mode lets them approve every captured action before it executes. They are not handing their job off to a black box; they are reviewing a workflow file they can read.
The maintenance blocker
RPA bots break when UIs change. The accessibility-tree input means the agent finds controls by role and automation_id; a label rewrite or a panel reorder does not break it. Match-by-bounds and match-by-text fallbacks handle the rest.
What the math looks like at the end of week 4
The pilot is not a vibe check. It is a real measurement against the fully loaded labor cost of the workflow today. The numbers below are the medians from real Mediar deployments, not press release rounding.
The math the CFO actually cares about: a 500-claims-a-week workflow at 10 minutes per claim drops to 1 minute, which is roughly 75 hours of analyst time saved every week. At fully loaded cost that is around $12K a month in saved labor against roughly $1.5K a month in runtime. The 8x ratio is not what makes the rollout work, but it is what makes the second workflow easy to approve.
Where the pilot expands next
A pilot that ships exactly one workflow does not change the org. The expansion plan after week 4 is workflow by workflow, not platform by platform. Each new workflow gets the same analyst-led recording loop, the same accessibility-tree replay, and the same billing model. The legacy systems below are the ones we have shipped recordings against in the field.
Each entry has at least one production workflow
Legacy desktop systems Mediar has shipped against
SAP GUI
Order-to-cash, MIRO, master data
Oracle EBS
Forms-based ERP and procurement
Jack Henry
Bank teller and core banking
Fiserv
Account servicing and reconciliation
FIS
Core banking and lending
Epic
EHR chart entry and chart review
Cerner
EHR ordering and documentation
eClinicalWorks
Patient intake and billing
Mainframe terminals
TN3270 and AS/400 green-screens
SAP B1
Mid-market ERP and inventory
Excel + custom Win32
Decades of internal tooling
Salesforce desktop
Through the Windows client
Want to scope a 4-week pilot on one of your workflows?
30 minutes with a Mediar founder. We pick the workflow together, you walk away with a runtime estimate and a recording plan.
Frequently asked
Frequently asked questions
Why does adoption stall at the desktop layer specifically?
Because that is where the work that nobody wants to do still lives. Modern SaaS exposes APIs; legacy desktop apps do not. Browser-based AI agents skip this layer entirely. RPA tools cover it but ship a developer-first authoring tool (UiPath Studio, Power Automate Desktop in build mode) that requires a Center of Excellence to operate. The analysts who run the workflows day to day are not in the build loop, so the bots that ship do not match what the analysts actually do, and the projects stall during user acceptance.
Do we need an RPA Center of Excellence to run a Mediar pilot?
No. The 4-week pilot deliberately routes around the CoE pattern. A domain expert records one workflow in step-by-step mode, the agent replays it against the accessibility tree, and the team measures runtime against FTE cost. If you have a CoE, this is information you can take to them after the pilot proves the workflow at scale. If you do not have one, you do not need to build one.
How is step-by-step recording different from UiPath's recorder?
UiPath's recorder captures actions and dumps them into Studio for a developer to clean up. Mediar's step-by-step mode pauses after every meaningful event (Click, Keyboard, Hotkey) and asks the operator to approve, edit, or discard before the next event is recorded. The output is a workflow file an analyst can read and rerun. The implementation is in the desktop client at apps/desktop/src-tauri/src/workflow_recorder.rs, gated by a STEP_BY_STEP_RECORDING atomic at line 28.
What happens when the legacy app gets a UI patch and labels move?
The agent uses the accessibility tree, so its primary match is by role and automation or accessibility ID. Those survive most label rewrites and panel reorders because they are the properties the OS uses to identify the control to a screen reader. If the ID has changed (a new SAP support pack can do this), the agent falls back to match-by-window-and-bounds, then match-by-visible-text, then a window-only focus. UiPath-style pixel matchers and CSS-style selectors break on the first patch; the accessibility-tree approach typically does not.
What is the actual cost compared to a UiPath rollout?
Mediar charges $0.75 per minute of runtime plus a $10,000 turn-key program fee that converts to credits with a bonus. There is no per-seat licensing. A 500-claim-a-week workflow at 10 minutes each that drops to 1 minute saves about 75 hours a week, roughly $12K a month in fully loaded labor against roughly $1.5K a month in runtime. We have moved an LG-customer F&B chain off UiPath onto Mediar and their CFO has the savings at 70 percent.
Why do this analyst-led, instead of paying a systems integrator to build it?
Because the analyst is the source of truth about what the workflow actually does, and the analyst is also the reason it has to keep working. A systems integrator records one path, ships it, and disappears; six months later the bot breaks on a corner case the integrator never saw. An analyst who built and approved the workflow themselves owns the maintenance loop and can fix it in the same step-by-step UI in minutes.
What if the workflow involves a PDF input?
PDF or scanned-document data extraction is a first-class input source. The agent parses the document, populates the structured fields the analyst approved during recording, and types them into the desktop application end to end. Insurance claims intake, invoice processing, and patient referral flows all live in this pattern.
Can we run this on-prem behind our existing security perimeter?
Yes. Mediar is SOC 2 Type II certified and HIPAA compliant. On-prem deployment is supported. The agent runs on a standard Windows VM inside your perimeter, and the open-source Terminator SDK at github.com/mediar-ai/terminator is available if your team wants to extend the runtime or write custom workflows.
Adjacent reading
AI agents on legacy desktop systems with no API
How accessibility-tree input lets an agent operate SAP GUI, Jack Henry, Epic and mainframe terminals end to end.
Enterprise AI agent governance on legacy systems
Step results, error categorization, and audit logs that satisfy an RPA Center of Excellence review.
Finance AI agent on legacy desktop
PDF invoice into SAP MIRO, end to end, billed by the minute.