OpenAdapt

OpenAdapt enters approved information into the systems your team already uses, and then it checks that the entry saved.

It handles this last manual step in EMRs, payer portals, and desktop apps, including apps your staff reach through Citrix or remote desktop. When something doesn't match, it stops and asks a person instead of guessing.

To watch it work first, open the live demo. It shows recorded runs that use synthetic data.

What changes for your team

Here's one example: a faxed referral that staff enter into the EMR.

	Today	With OpenAdapt
Entering it	A staff member keys each referral by hand. Two hospital time studies put one faxed referral at about 10 to 12 minutes of staff time.	OpenAdapt enters the approved fields in the same EMR screens your staff use.
Knowing it saved	Someone sees "Saved" and moves on.	OpenAdapt reads the saved record back and compares it with what it entered.
When something's off	It turns up later, at booking or billing.	The run stops before it guesses, and a person decides what happens next.
Your staff's part	Type every referral.	Review the runs that OpenAdapt stops on.
What you set up	Nothing new.	No EMR integration. The record check needs a second way to read the record, such as a report, an API, or a read-only login.

Sources for the "Today" times: UCSF Pediatric Access Center, JAMIA Open 2020 (mean 719 seconds per faxed referral, including a call to the patient), and Calderdale and Huddersfield NHS Foundation Trust, HFMA case study 2024 (10 minutes per referral). Nobody has measured an "after" time with OpenAdapt yet, so the table doesn't claim a time saving.

What you see and control

Every run ends with one of these results:

Result	What it means
Done and checked	It saved the entry and read the record back to confirm it.
Stopped before saving	Something didn't match, so it stopped before it changed anything and asked a person. Nothing was written.
Blocked before saving	A rule, an approval, or the right-record check blocked the run before it saved anything. Nothing was written.
Check the record	A save may have gone through. A person checks the record before anything is retried.
Finished, not checked	It did the steps but didn't confirm the saved result, as in a practice run.
Didn't finish	It couldn't complete the task. Its run report says what's known about whether anything was written.

• You get a run report for every run. A run that's done and checked also gets a receipt that shows what was checked and the result. The receipt leaves out typed values and screenshots.
• Before it types, it can confirm that it's in the right patient's chart.
• When a screen changes, it finds the same field again or stops. A change to the automation goes live only after a person approves it.
• It runs on a computer you control, or on one we host. Recordings and screens stay on that computer unless you approve sharing them.
• A routine run makes no AI model calls.

Two ways to start

Have a workflow to hand off

To hand off a task your team repeats, tell us about it at openadapt.ai/contact.

1. You show us the task once, on your own system.
2. We build the automation and test it with your own cases before it goes live.
3. We keep it working. When a screen changes, we propose a fix and a person on your team approves it.

We scope services per workflow. Hosted plans are on the pricing page. If your own AI product decides what to enter, OpenAdapt can make that final entry for it and return the result. See OpenAdapt Execute.

Run it yourself

The engine is free and open source under the MIT license. With Python 3.10, 3.11, or 3.12, run:

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

This runs a synthetic clinic task twice on your computer. The first run is done and checked. In the second run, the test server rejects the save after the app shows that it saved. The record check finds no saved record, so the run stops and leaves the record for a person to check. On Python 3.13 or newer, install with uv tool install --python 3.12 openadapt instead.

The developer guide below covers authoring your own workflow, and Evidence lists what we've measured so far.

---

Developer guide

Documentation · Start locally · Walkthrough · Desktop downloads · Live demo · Website · Discord

A person, or a local agent that person watches, records a demonstration. OpenAdapt compiles it into a program that runs again without a generative-model API in the control loop. A named person admits that program before production use. Before a governed run reports VERIFIED, it checks every declared effect at the required evidence tier. A caller must report a halt as a halt, never as success.

Computer-use agents can call OpenAdapt programs. They aren't the executor inside OpenAdapt. When an agent clicks during a demonstration, the person who admits the program watches.

This repository is the installer and the openadapt command. The compiler and the runtime live in openadapt-flow, and this repository doesn't reimplement them. openadapt-agent exposes compiled programs to an agent over MCP.

Run the tutorial

A solutions engineer gets VERIFIED on synthetic MockMed:

python -m pip install --upgrade openadapt
openadapt doctor --backend web
openadapt flow tutorial

OpenAdapt supports Python 3.10 through 3.12. The engine doesn't install on Python 3.13 or newer yet. There, use uv tool install --python 3.12 openadapt, which fetches Python 3.12 for you. The local tutorial needs no account or API key. The base install includes Playwright. On the first browser action, OpenAdapt asks Playwright to download its matching Chromium build. That download needs network access.

Minimal Linux hosts can lack Chromium's shared libraries. openadapt doctor lists the missing libraries before any browser download. If it finds any, run:

python -m playwright install-deps chromium
openadapt doctor --backend web

Playwright asks for administrator access when the package manager needs it. Use the interpreter-specific command from doctor if you installed OpenAdapt with an isolated tool runner.

openadapt flow tutorial is the launcher spelling of openadapt-flow tutorial. Every openadapt-flow <verb> command works as openadapt flow <verb>, and that form also works after uv tool install, which puts only openadapt on your PATH. The tutorial records and compiles a task in MockMed, a synthetic practice-management fixture, certifies it against the shipped clinical-write policy, runs it under the Standard profile, then confirms the saved record through a read-only API that the screen doing the writing never touches:

[1/5] Record the demonstration against a real persistence boundary
[2/5] Compile and propose a fixture-specific effect contract
      2 system-of-record effect proposal(s) derived from the fixture's record delta on step_005; review is required for a real deployment
[3/5] Certify against the clinical-write policy
[4/5] Admit and execute under the standard profile
      VERIFIED in 9.1s; 0 model calls; the system of record holds 1 record(s)
[5/5] Emit the local run receipt

VERIFIED: <out>/run/REPORT.md
  transaction     VERIFIED
  metering class  billable (this local tutorial was not reported or charged)
  profile         standard
  model calls     0
  effects         2/2 confirmed by an independent system-of-record read (Seal Oracle tier 2)

That's real output from Flow 1.35.1 on macOS, 2026-10-08, with the run directory shortened and the bundle digest left out. The tutorial writes the recording, the compiled bundle, and the run receipt under its output directory (default tutorials/tutorial-<UTC timestamp>). openadapt quickstart is a wrapper around the same engine path.

Then watch it refuse to trust the screen:

openadapt quickstart --break-it

Same certified bundle. This time the backend rejects the write after the app has already painted its success banner, so every on-screen check passes:

  The screen claimed:  every on-screen check passed -- the app painted its success banner
  The verifier found:  1/2 declared effect(s) REFUTED by an independent
                       read of the system of record, which holds 0 record(s)
  The engine did:      HALTED at the consequential step instead of claiming
                       success (transaction: RECONCILIATION_REQUIRED, billable: no)

The independent read finds no saved record, so the run halts. Its transaction outcome is RECONCILIATION_REQUIRED, so nothing is retried until a person checks the record.

The bundled workflow is a tutorial. Qualifying a real one means declaring its application boundary, its action risks, its identities, its effect verifiers, its fault cases, and its deployment policy. Start with the five-minute walkthrough.

Tutorial VERIFIED is a local receipt on synthetic MockMed. It isn't a production Seal. When you qualify a real job, the same independent check is what a Seal attests. Public synthetic verify: openadapt.ai/seals. The Seal contract: docs/commercial/seal.md.

Inspect what compiled, and what it failed to cover:

openadapt flow visualize <out>/bundle --out graph.html
openadapt flow lint <out>/bundle

Give an agent the run tool

openadapt-agent serves compiled programs to an MCP client. Launcher releases after 1.16.0 install it with openadapt. With 1.16.0, install it by name:

python -m pip install --upgrade openadapt-agent
openadapt-agent serve --bundles <bundle or directory of bundles> --allow-run

uv tool install and pipx put only openadapt on your PATH. With a launcher release after 1.16.0, run openadapt agent serve ... there instead. It passes every argument to openadapt-agent.

Leave out --allow-run when the client should inspect workflows but not start them. A halted or refused run comes back as a halt or a refusal, never as a success. Local unsigned success isn't a Seal; treat unsigned production success as failure. The openadapt-agent README has the client setup.

Author a workflow

Do not pass --backend. With no --url, record captures this OS. Pass --url when the surface is a browser.

openadapt flow record --out rec
openadapt flow record --url https://staging.your-app.example --out rec
openadapt flow compile rec --out bundle --name my-workflow
openadapt flow replay bundle --url https://staging.your-app.example --run-dir run

replay drives the real app at --url and performs every recorded action, including saves you can't undo. It doesn't ask first, it isn't a dry run, and it doesn't certify the bundle. Point --url at a test or staging copy of the app, never at production data.

One bundle uses one execution surface and does not switch between browser, native, RDP, or Citrix backends.

If the task crosses a browser and a native app, or otherwise changes backend, record one bundle per surface. openadapt flow compose sequences the compiled bundles:

openadapt flow compose \
  --child intake=./intake-bundle \
  --child posting=./posting-bundle \
  --handoff intake.patient_id=posting.patient_id \
  --out composed
openadapt flow certify composed --policy clinical-write
openadapt flow run composed --config deploy.yaml

Child A has to end VERIFIED (or a halt class you named with --allow-halt) before child B starts. Handoffs copy parameter values that A's confirmed effect contract already bound. Missing evidence stops the run. Compose will not retarget one recording onto a second backend. The openadapt-flow README has the full boundary.

Native and remote workflows never start or download Chromium. Install only the capability you need:

python -m pip install "openadapt[capture]"          # local human demonstration
python -m pip install "openadapt[capture,windows]"  # Windows UI Automation
python -m pip install "openadapt[capture,macos]"    # macOS Accessibility
python -m pip install "openadapt[capture,linux]"    # Linux AT-SPI
python -m pip install "openadapt[capture,rdp]"      # RDP transport
python -m pip install "openadapt[privacy]"          # PII/PHI scrubbing

For visual authoring and review, there's OpenAdapt Desktop.

How a run ends

A click landing is not evidence that a transaction committed. Every terminal run says what the runtime actually knows about the business effect, and these outcomes are not interchangeable:

Outcome	Meaning
VERIFIED	Every declared effect and collateral-effect check passed at the required evidence tier. The only production success.
HALTED_BEFORE_EFFECT	The run stopped, with positive evidence that no consequential effect occurred.
RECONCILIATION_REQUIRED	Delivery or persistence is uncertain, conflicting, or temporarily unverifiable. Never blind-retried.
FAILED_PLATFORM	An OpenAdapt failure before any possible business effect.
CANCELED	Canceled before any business effect.
REJECTED_POLICY	Authorization, identity, qualification, or environment policy refused execution before any effect.
COMPLETED_UNVERIFIED	A Demo run finished without production-grade effect evidence.
ROLLED_BACK	A duplicate or collateral write was compensated and re-verified.

The plain results at the top of this page map to these outcomes:

Plain result	Transaction outcome
Done and checked	VERIFIED
Stopped before saving	HALTED_BEFORE_EFFECT, CANCELED
Blocked before saving	REJECTED_POLICY
Check the record	RECONCILIATION_REQUIRED, ROLLED_BACK, and a HALTED run with no transaction outcome
Finished, not checked	COMPLETED_UNVERIFIED
Didn't finish	FAILED_PLATFORM

A surface derives the plain result from the transaction outcome, never from a coarse HALTED label alone. A value a surface doesn't recognize reads as Check the record.

A resumed RECONCILIATION_REQUIRED run has to reacquire and reconcile the live state before it does anything else.

Before a consequential action the runtime can check authorization, workflow state, record identity, target uniqueness, and a fresh view of the application. Afterwards it waits for state to settle and evaluates the declared effect. When it can't establish the contract, it returns the evidence and stops.

When it stops, a halted run can send one signed question to the phone view: which record, which of these two targets, did you complete the manual step. The phone shows only what the sealed pause capability permits. It never clicks the application and it never declares success. After an answer, the customer-controlled runner reads the live application again and rechecks pause, session, workflow state, identity, target, and effect before continuing. Screenshots stay on the runner.

Repairs are versioned changes rather than permission to improvise. A candidate repair gets reviewed, tested against the workflow's qualification contract, promoted, and rolled back if it turns out wrong.

Surfaces

Workflow intent stays portable; the bindings are environment-specific. Each qualification pins the exact surface, application, version, environment, identity contract, and effect verifier, so nothing inherits a blanket platform claim.

Substrate	Evidence available to a qualified workflow
Browser (web)	DOM, accessibility, visual, OCR, field geometry, source-time secret exclusion
Native desktop (Windows, macOS, Linux)	Visual, OCR, local window scope, plus UI Automation, Accessibility, or AT-SPI where the adapter supplies it
Remote display (RDP)	External pixels, OCR, anchors, keyboard, mouse, fresh-frame verification
Citrix / VDI	External pixels, OCR, anchors, keyboard, mouse, deployment-bound verification

Remote execution drives the visible client from a customer-controlled runner. Nothing gets installed inside the remote session. See the substrate model, what works today, and the CLI reference.

Where your data lives

Operating model	Best for	Where data and execution live
Local / self-hosted	Community use and local automation	Your machine
Customer-controlled	Sensitive data, native apps, RDP, Citrix, private networks	Your declared boundary; Cloud coordinates approved metadata only
Managed execution	Approved browser and non-sensitive workflows	OpenAdapt-managed runners

Raw recordings and live observations stay local by default. An artifact crosses a boundary only through explicit sanitization and exact-byte approval. Read the trust center before you pick one.

The launcher, compiler, runtime, Desktop app, substrate adapters, verification interfaces, and basic qualification tools are MIT. OpenAdapt Cloud is the commercial multi-tenant control plane for managed operation, fleet governance, billing, and enterprise integrations. Local safety-critical verification is not paywalled.

Evidence

Evidence	Result
Public OpenEMR field test, measured 2026-07-08 on a Flow 0.1.0 development checkout	Compiled replay passed the saved-row OCR check on 19 of 20 runs at a 39.2 s median with 0 model API calls, and run 20 halted safely. A computer-use agent finished 10 of 10 at about $0.55 a run at July 2026 list prices. This was a shared public demo and a small sample.
Fault test on a local test record system, measured 2026-07-21	72 of 90 runs left the record wrong: missing, partial, duplicated, or on the wrong record. A check that trusted the success banner passed 54 of those 72. One separate read of the record passed 9 of the 72, all of one kind: a write to a billing table that the read didn't cover. Every check also stopped 9 of the 18 runs that had saved correctly, because the client never got the reply. We chose these faults and injected them on our own test server, so this is a coverage test over a fixed fault list, not a real-world error rate.

Each result belongs to its named task and environment. Qualifying a new workflow is what decides what can be claimed about it. Sources: OpenEMR results, fault test method and caveats, and the comparison. OpenAdapt isn't affiliated with the OpenEMR project.

OpenAdapt Execute

OpenAdapt Execute is a private partner service for providers who need an authorized transaction completed inside an application they cannot integrate with. The partner sends structured input and business authorization; OpenAdapt runs the qualified workflow in the customer-controlled environment, verifies the declared effect, and returns an asynchronous receipt with VERIFIED or a precise non-success outcome. It starts with one named transaction in one qualified environment, and it isn't a self-service API. Partner contract and qualification process: the Execute guide.

Release status for IT reviewers

The block below is generated from the signed public lifecycle record.

The signed ledger has seven active target admissions. Their evidence class is remote-safe-synthetic, not MockMed production_acceptance. They remain valid until revoked; there's no expiry date. pip install openadapt is the admitted runtime (launcher 1.16.0, Flow 1.35.1). Desktop's admitted artifact is the 0.16.0 wheel. Native Mac DMGs stay ad-hoc signed 0.15.0; don't treat those as admitted. A Production run still needs a workflow admission for the exact compiled bundle, application, and environment. Check the live signed Production record.

Where the code is

• Here: installer, the unified openadapt CLI, release compatibility, and the stable project URL.
• openadapt-flow: the compiler, the governed runtime, the CLI implementation, conformance tests.
• openadapt-agent: the MCP bridge that serves compiled programs to agents.
• openadapt-capture: native screen, mouse, keyboard, timing, and window-scope capture.
• openadapt-privacy: local sanitization and review for approved derivatives.
• Desktop: the native record, inspect, qualify, execute, and review application.

Research packages and the pre-1.0 monolith

None of this is required to record, compile, replay, or verify a workflow.

A separate research line asks whether human demonstrations can improve the accuracy of general computer-use models. That's a different question from compiling one demonstration into a deterministic script, and it lives in openadapt-ml (training and inference for multimodal GUI-action models), openadapt-evals (benchmark evaluation for GUI agents), openadapt-retrieval (multimodal demonstration retrieval), and openadapt-grounding (UI element localization). Install with pip install "openadapt[ml,evals]"; the research thesis has the methodology, results, and limits.

openadapt-wright, openadapt-herald, openadapt-crier, openadapt-consilium, openadapt-telemetry, and openadapt-viewer support development and operations. The runtime doesn't need any of them.

The pre-1.0 monolith (v0.46.0) is frozen under legacy/ and published on PyPI as openadapt==0.46.0 for Python 3.10 and 3.11. A plain pip install of it fails today. docs/LEGACY_FREEZE.md has install steps that work and the migration guide. Early demonstrations are on Twitter and Loom.

Contributing

Launcher, packaging, and CLI changes belong here. Compiler, runtime, verification, repair, and backend changes belong in openadapt-flow.

Contribution guide · Issues · Discussions · Discord · Report a vulnerability

Maintained by OpenAdaptAI under the MIT License.