OpenAdapt GUI Automation with Independent Effect Verification

Why OpenAdapt verifies records instead of trusting save banners

OpenAdapt addresses a specific weakness in GUI automation: an application can display a successful save while the intended record is absent, altered, or attached to the wrong item. The project targets staff who repeatedly enter approved information into electronic medical records, payer portals, and desktop applications, including systems accessed through Citrix or remote desktop. Its purpose is narrower than general-purpose agent control. It enters information already approved for entry, then determines whether the declared effect actually exists.

The README distinguishes several terminal states, which is an important design choice. `Done and checked` means the entry was saved and read back for confirmation. `Stopped before saving` means a mismatch prevented the change, so the documentation says nothing was written. `Blocked before saving` covers a rule, approval, or right-record check that stopped execution before a save. The other states acknowledge uncertainty. `Check the record` means a save may have succeeded but requires human inspection, while `Didn't finish` says the run report records what is known about whether anything was written.

This distinction prevents every incomplete run from being presented as success. It also means OpenAdapt is not appropriate for a task whose result cannot be inspected independently. The setup requires a second way to read the record, such as a report, API, or read-only login. Without that evidence path, the project may finish steps, but it cannot honestly produce a verified result.

Inside OpenAdapt's demonstration compilation and replay loop

A person, or a local agent watched by a person, records a demonstration. OpenAdapt compiles that demonstration into a program that can run again without a generative-model API in its control loop. The repository describes this flagship compiler as living in `openadapt-flow`, while the main `openadapt` package supplies the CLI and browser driver needed for the bundled tutorial. The replay operates through the same visible application interfaces used by staff rather than requiring a new integration with each target system.

The output is governed as an automation artifact. A named person admits the program before production use, and a change to the automation goes live only after approval. Before a run reports `VERIFIED`, it checks every declared effect at the required evidence tier. A caller must preserve a halt as a halt instead of converting it into success.

The implementation is local-first for recorded runs. Recordings and screens remain on the computer running the automation unless sharing is approved. A routine run makes no AI model calls. This does not mean OpenAdapt is an AI-free product, since capture, machine learning, evaluations, and other capabilities are available as opt-in extras, but generative inference is not part of the normal replay control loop. The README also describes agent access: an external computer-use agent can call an OpenAdapt program, and OpenAdapt Execute can perform final entry for another AI product and return the verified result.

Installing OpenAdapt and running the synthetic clinic tutorial

OpenAdapt requires Python 3.10, 3.11, or 3.12. On those versions, upgrade the package and launch the documented first run. The package includes the CLI, demonstration compiler, and browser driver required by the public quickstart, so a second package installation is not required for that command.

python -m pip install --upgrade openadapt
openadapt quickstart --break-it

The quickstart performs two runs against a synthetic clinic task on the local computer. The first should finish as `Done and checked`. The second uses `--break-it` to make the test server reject the save after the application presents its save state. According to the README, the record check then finds no saved record and stops the run for a person to inspect.

For Python 3.13 or newer, the documented package path changes because the engine, agent bridge, and `rapidocr-onnxruntime` dependency publish requirements below Python 3.13. Use the following command instead:

uv tool install --python 3.12 openadapt

The package asks Playwright to download Chromium on the first browser action. Linux users must satisfy the host system-library prerequisites before that download. The repository states that `openadapt doctor` and Flow check these prerequisites. The synthetic quickstart is the first useful check because it exercises both the accepted path and a mismatch that must not be reported as verified.

Verification receipts, screenshots, and operational review

Every run produces a report. A run ending in `Done and checked` also produces a receipt recording what was checked and the result. The documented receipt omits typed values and screenshots, reducing its exposure to operational data, although that design choice does not replace controls for the local run reports, recordings, or screen captures.

OpenAdapt can verify that it is operating in the correct patient's chart before typing. This right-record check is separate from checking whether the intended data was saved. If the interface changes, the automation attempts to locate the same field again or stops. It does not treat an unfamiliar screen as permission to improvise.

Human involvement remains part of the operating model. Staff are expected to review runs that stop, screen changes require proposed fixes and team approval, and an uncertain save requires a person to check the record before any retry. The service described in the README adds another layer: the team shows the task once, OpenAdapt builders test it against the customer's cases, and a customer employee approves changes before release.

This design is useful where false completion has business consequences, but it also creates process work. Someone must own stopped runs, uncertain saves, interface regressions, and program approvals. OpenAdapt reduces blind trust in the target application's UI; it does not remove the need for accountable operations.

OpenAdapt's constraints against conventional RPA and API automation

A conventional RPA script usually follows UI controls and may accept an application's success indicator as completion. OpenAdapt instead models declared effects and demands an independent check at a required evidence tier before reporting `VERIFIED`. That difference is most valuable when a save operation can fail after the UI appears successful. It adds an evidence requirement, but it gives the run report a concrete basis for distinguishing completion, uncertainty, and a halt.

An API integration is a different approach. It sends structured requests and receives structured responses without controlling a GUI. That can avoid screen-coordinate and interface-change problems, but the README specifically positions OpenAdapt for existing EMRs, payer portals, Citrix environments, and desktop applications that may not offer a practical write integration. OpenAdapt uses the screens staff already use, while its verification still benefits from a report, API, or read-only login.

The trade-off is clear. OpenAdapt can automate systems that are awkward to integrate directly, but a reliable evidence source must still exist. A workflow with no readable saved state, or one where checking the effect is as difficult as repeating the entry, is a weak candidate. Likewise, application integration is preferable where an official API provides the required transaction and authoritative response without GUI dependence.

OpenAdapt release state, dependencies, and upgrade obligations

The repository is not archived. Its last push was on 2026-10-16, and the listed `v1.16.0` release was published on 2026-08-26. The package declares version `1.16.0` in `pyproject.toml`, requires Python `>=3.10`, and classifies support for Python 3.10, 3.11, and 3.12. The README's installation instructions are narrower than that metadata because dependencies constrain Python 3.13 users to the `uv` command that selects Python 3.12.

The base package is designed to make `openadapt quickstart` work without another package install. Capture, machine learning, and evaluation capabilities remain opt-in extras. Runtime prerequisites can therefore differ by feature and host. Linux system libraries, Playwright's Chromium download, and version compatibility are concrete upgrade concerns even when the Python dependency is installed successfully.

OpenAdapt is distributed under the MIT license. That permits use, modification, distribution, and sublicensing subject to the license terms, but this review does not interpret obligations for a particular deployment. Organizations still need to account for target-system access policies, evidence retention, production admission, and the cost of approving compiled workflow changes. The README also says service work is scoped per workflow, so hosted operation introduces a separate commercial arrangement rather than being part of installing the open-source engine.

Editorial conclusion

OpenAdapt fits teams with repetitive GUI entry tasks, an independent way to inspect saved records, and people available to review halted runs. It is a poor fit for tasks without a declared, verifiable effect, applications whose interfaces change frequently, or operators who require the application itself to be its own verifier. Evaluate it first with a synthetic workflow, then confirm that your target system exposes a report, API, or read-only login that can verify the result without changing it. For production use, also verify the workflow-specific approval process and record-review responsibility before admitting a compiled program.

Frequently asked questions

Official sources

1. License: MIT
2. OpenAdaptAI/OpenAdapt on GitHub
3. Project website
4. README
5. Releases