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, and it works. The cost is the build. You record the flow in a studio first, then keep a selector library in sync with every screen it touches. When the vendor ships a new version, someone updates those selectors and re-tests the flow. That maintenance is the tax nobody budgets for.

How it works: the driver layer, not the mouse and keyboard

Most agents that "use a computer" take a screenshot, guess where the button is, and click those coordinates. Lapu AI works one layer down. It talks to the application's own automation layer — the same interface a screen reader uses — so it addresses the button labelled Save, not the pixel at 412,283.

On Windows that layer is UI Automation (UIA), which ships with the OS. 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.

Three things follow, and for recurring work the third is the one that matters. It does not take over the machine — the operator's mouse and keyboard stay free while a task runs. It does not break when a window moves or a screen is reconfigured. And it does not drift on the fiftieth repeat: a named element is still named the same thing on run fifty as on run one.

That is a different failure mode from either alternative. Coordinate-driven agents — Anthropic's computer use, OpenAI's ChatGPT Agent — reach anything visible on screen, but the click depends on the screen not shifting. Mature RPA is selector-based rather than coordinate-based, so it is far steadier than that; its cost is the recording step and the selector library someone maintains afterwards. Lapu AI needs neither: you describe the task in plain language and it resolves the elements at runtime.

Lapu AI keeps both modes and picks one per application. It can also drive real keyboard and mouse input, and it does so where that is genuinely the better tool, not only where nothing else is left. SAP GUI is the clearest case: driving real input means a customer never has to ask IT to switch on sapgui/user_scripting, a setting many organisations deliberately keep off. In that mode the agent does occupy the mouse and keyboard while it runs, and the three properties above describe the driver-layer path.

When the tree is thin — an old control that draws itself as pixels with no accessibility metadata — there is no driver layer to talk to, and Lapu AI falls back to OCR and vision. That fallback is real and it carries the same fragility as any coordinate-level approach. The driver layer is the primary route because it is precise and cheap; screen-level control is the last resort, not the default.

A frontier model plans each step and decides which element to act on; the local tools invoke that control under your approval. 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: in RPA programs the recurring cost is rarely the licence — it is keeping recorded selectors working as vendors ship updates, and that cost scales with the number of flows you own rather than how often they run. 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. There is no driver layer to address, so Lapu AI falls back to OCR and vision — with the fragility that implies.

• 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
• How AI automates invoice processing end-to-end
• 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?

Both drive applications through the same underlying automation layer — mature RPA is selector-based, not screenshot-based — so this is not a reliability takedown. The difference is what you build and then maintain. RPA asks you to record the flow in a studio and keep a selector library in sync with every vendor update. Lapu AI resolves elements at runtime from a plain-language description of the task, so there is no recording step and no selector graph to own. The honest trade-off: RPA still wins for unattended 24/7 scale, orchestration queues, and strict determinism on high-volume regulated processes.

How is this different from Anthropic computer use or ChatGPT Agent?

Those agents are coordinate-driven: they take a screenshot, locate the target visually, and click those coordinates. That reaches anything visible, including remote sessions and custom-drawn interfaces where no automation metadata exists. It also means the click depends on the screen not changing — a moved window, a different resolution, or a dialog that opens half a second late can put it in the wrong place — and the agent occupies the mouse and keyboard while it runs. Lapu AI addresses named elements through UI Automation instead, so a task can run while the operator keeps working. It also supports driving real keyboard and mouse input and uses it where that is the better fit — SAP GUI, so the customer never has to enable sapgui/user_scripting — and reads via OCR and vision where an app publishes nothing to address. The difference from a coordinate-driven agent is that input is the second choice, not the only one.

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 the recurring cost is rarely the licence — it is keeping recorded selectors working as vendors ship updates, and that cost scales with the number of flows you own rather than how often they run; 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.