// the take
OpenAdapt watches a person or a computer-use agent do a GUI task once — in a browser, Windows/macOS/Linux app, or over RDP/Citrix — then compiles that run into a deterministic program that repeats it with zero model calls per run. It's aimed at teams doing the same high-stakes data entry (EHRs, payer portals) over and over, where a computer-use agent's per-step model cost and screen-reading mistakes are the problem.
The core idea is sound and they prove it: instead of trusting a 'Saved' message on screen, the program reads the record back from the actual system of record after each write, and their fault-injection test shows the screen alone missed 54 of 72 bad saves while a full DB read caught all of them. It picks the most reliable automation layer per step — DOM, Windows UI Automation, macOS Accessibility, AT-SPI — falling back to pixel matching only where nothing else exists (RDP/Citrix), instead of defaulting to screenshots everywhere like most computer-use stacks. The repair flow (halt before saving, propose a fix, require human approval) is the right shape for anything touching real patient or financial records, and the MCP integration means an agent calls a compiled workflow as one tool instead of driving the screen step by step.
The read-back verification that's the whole selling point only works if you have independent read access to the system of record — API, DB, or a second session — which a lot of apps you'd want to automate simply don't expose; without it you're back to 'finished but unverified'. Platform coverage outside web is thin and mostly toy-validated: macOS is '3 of 3 saves in TextEdit,' Linux is one GTK3 app in CI, and Citrix has no run against a real session yet, so treat anything beyond the OpenEMR web demo as unproven for your app. Each application still needs its own 'qualification' before a compiled program is trusted to run, which is real per-app engineering effort — the same maintenance burden traditional RPA has, just moved earlier in the pipeline. The headline benchmarks are self-run on small sample sizes (30-62 runs) against synthetic or modified test copies of apps, not independent or production-scale evidence, and some capabilities (cloud dashboard, receipts) appear to sit behind a paid plan rather than in the open-source core.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →