Desktop automation for the Windows apps RPA can't

The no-API problem: LOB software people re-key by hand

A large share of the software that runs a business has no API worth integrating against. It is a .NET or WinForms application from the 2000s, a WPF front end on an ancient database, a Win32 ERP or line-of-business tool from a vendor that shipped its last SDK a decade ago. There is no REST endpoint, no webhook, no supported export. The interface is the only interface.

So teams do the work by hand. Someone reads a record in one app and types it into another. Someone copies figures from a desktop screen into a spreadsheet every morning. Someone clears a backlog of data entry one form at a time. It is slow, it is error-prone, and it does not scale — but no connector reaches these apps, so it stays manual.

Classic RPA was built exactly for this gap. But recording fixed selectors and coordinates against a legacy UI is fragile: the moment a control moves, a version updates, or the layout shifts, the recording breaks and someone has to rebuild it. That maintenance is the tax nobody budgets for.

How it works: the native Windows accessibility layer

Windows ships an accessibility framework called UI Automation (UIA) — the same layer screen readers use to describe an app to a blind user. Standard WinForms, WPF, and Win32 controls publish themselves through it automatically. Each control exposes a role (button, edit box, list item, tab, checkbox) and a name (its label or accessible text).

Lapu AI reads that tree and acts on controls by role plus label — "the edit box labelled Customer ID," "the button labelled Post." Because it targets what a control is rather than where it sits, the automation is independent of screen resolution, DPI scaling, and theme. Move the window, change the display, switch to dark mode — the Save button is still the Save button.

When the tree is thin — an old control that draws itself as pixels with no accessibility metadata — Lapu AI falls back to OCR and vision, reading the screen the way a person would. The accessibility path is the primary route because it is precise and cheap; vision is the fallback for the cases where the app gives you nothing else.

A frontier model plans each step and decides what to click; the local tools carry out the clicks and keystrokes. No API is called against the target app. No selector graph is recorded. The model reasons about the live UI at runtime, which is why it adapts when the interface shifts instead of breaking.

The moat vs traditional RPA

Read this as buyer benefits, not a takedown. For a lot of legacy desktop work, the adaptive approach removes the exact costs that make RPA projects stall.

Industry context, not a Lapu AI measurement: across RPA programs, maintenance commonly runs 30 to 50 percent of build cost per year, and a comparable share of RPA initiatives stall before scaling. The adaptive approach targets that maintenance drag directly.

Where this approach stops — honest limits

A tool that claims to do everything is lying. Here is where RPA or a different tool is the better call.

• Unattended 24/7 scale

  For lights-out, high-volume processing with orchestration queues and SLA guarantees, purpose-built RPA is still the right tool. Attended, approval-gated work is the sweet spot here.

• Strict determinism at volume

  High-volume regulated processes that demand identical, deterministic execution every run favour a recorded RPA flow over a model reasoning step by step.

• Citrix, VDI, mainframe, custom-drawn UIs

  Citrix and VDI sessions, mainframe and 3270 emulators, and custom-drawn interfaces publish little or no accessibility metadata. You fall back to OCR and vision, with lower reliability.

• Windows-first, not full macOS parity

  These legacy line-of-business workflows are Windows-first. We do not claim full macOS parity for driving legacy Windows-native apps.

Example workflows

Concrete jobs the accessibility-driven approach handles well against legacy Windows software.

• Re-key between two LOB apps

  Read a record from a legacy WinForms ERP that has no export, then create the matching entry in a second desktop app that has no import — the cross-system re-keying a person does by hand every day.

• Extract from a Win32 app into Excel

  Walk a list view in an old Win32 line-of-business tool, pull each row by its accessibility label, and write a normalised sheet into the local Excel install — no ODBC, no database credentials.

• Batch data entry into a desktop form

  Take rows from a CSV on disk and fill a WPF or WinForms entry screen field by field, pausing for approval before each submit, so a 300-row backlog clears without a human typing it.

• Reconcile a portal against a local file

  Read values out of an internal desktop app, compare them against a spreadsheet on the machine, and flag mismatches for review — a check that would otherwise need a screen and a second monitor.

Who it's for

Explore further

• Automate a legacy Windows app without an API
• How to automate a WinForms application
• SAP GUI automation without scripting
• Lapu AI vs AskUI
• Power Automate Desktop alternative
• Best AI agent for desktop automation
• Best AI agent for document automation
• Best AI agent for screen scraping
• Best AI agent for data entry
• Best AI agent for invoice automation
• UiPath alternative
• How Lapu AI keeps automation safe
• AI automation on the desktop — the overview
• AI agent security — the model

Frequently asked questions

Can I automate a Windows app that has no API?

Yes. That is the point of this approach. Lapu AI drives the app through the native Windows accessibility layer — UI Automation — the same interface screen readers use. It identifies controls by their role and label rather than calling an API or a database, so a .NET, WinForms, WPF, or Win32 line-of-business app with no integration surface can still be automated end to end.

How is this different from RPA like UiPath or Power Automate Desktop?

Traditional RPA records fixed selectors and coordinates, so it breaks when a control moves, a version changes, or the layout shifts. Lapu AI reasons about the live accessibility tree at runtime and finds a control by what it is (a button labelled Save) rather than where it sits. That means less maintenance and no brittle selector graph. The honest trade-off: RPA still wins for unattended 24/7 scale, orchestration queues, and strict determinism on high-volume regulated processes.

How does UI Automation actually find the controls?

Standard WinForms, WPF, and Win32 controls expose themselves through the UI Automation (UIA) provider that Windows ships with. Each control publishes a role (button, edit, list item, tab) and a name (its label or accessible text). Lapu AI reads that tree and acts on controls by role plus label, which is independent of screen resolution, DPI scaling, and theme. When the tree is thin — a control that draws itself with no accessibility metadata — it falls back to OCR and vision on the pixels.

Does my data leave the machine?

Your files and application data stay on the machine — there is no Lapu AI cloud storage or remote workspace. When a step needs reasoning, only the minimal context that step requires is sent to the AI model provider; nothing more. It is local-first, not air-gapped. If a step genuinely needs to send some context to a model, it does. For fully disconnected environments, that distinction matters, so evaluate it against your policy.

Is it safe to run against production line-of-business systems?

Lapu AI asks before every sensitive action. Saving a record, changing data, or clicking a submit button surfaces an approval prompt with the proposed change before it happens; low-risk reads can be auto-approved. Every action is written to a local audit trail — what it did, when, and why — retained for up to 90 days. You review exactly what ran against the system.

What can this approach NOT do well?

Citrix and VDI sessions, mainframe and 3270 terminal emulators, and custom-drawn UIs that publish no accessibility metadata are limited — the accessibility tree is thin or absent, so you lean on OCR and vision with less reliability. It is Windows-first; there is no full macOS parity claim for these legacy-app workflows. And for unattended, high-volume, strictly deterministic processing with SLA guarantees, purpose-built RPA is still the right tool.

Do I need a per-bot license or a center of excellence to run it?

No. There is no per-bot runtime license and no center-of-excellence overhead. Lapu AI is priced per user — Free, $20, $60, and $100 monthly tiers, plus Teams and Enterprise on custom pricing. Attended automation runs on the operator's own machine, so a small team can start without standing up an RPA platform. Across the RPA industry, maintenance commonly runs 30 to 50 percent of build cost per year and a similar share of projects stall; the adaptive approach is designed to reduce that maintenance drag, not to match RPA's unattended throughput.

Which frontier model does it use, and can I bring my own?

Lapu AI ships with built-in frontier models, so there is no separate API key to provision to get started. The model plans each step and reads the accessibility tree or screen; the local tools carry out the clicks and typing under your approval. SSO/SAML, dedicated SLA, and custom deployment are available on Enterprise.