OpenAdapt
Compile demonstrated GUI work into deterministic local programs with evidence-backed outcomes.
The README describes capability-minimized installation, customer-controlled execution boundaries, local-by-default raw recordings, explicit sanitization and exact-byte approval before artifacts cross a boundary, and identity/state/target checks before consequential actions with fail-closed behavior. CI permissions are narrow, while dependency-review and CodeQL actions are commit-pinned. Deductions apply because the decisive runtime mechanisms live in the absent openadapt-flow repository, privacy scrubbing is optional, human confirmation is not shown as a mandatory default for every write, and rollback is demonstrated for repair versions rather than for completed business effects. Maintainer, author, license, and image provenance are identified, although enterprise publisher identity remains unverified.
The README, pyproject, and security policy consistently describe the Beta lifecycle, Python 3.10–3.12 support, launcher role, and maintenance route. Dependencies have compatibility bounds and platform-specific separation, but the core engine is an external openadapt-flow dependency, Chromium is downloaded on first browser use, and FFmpeg must be provisioned separately, limiting self-contained and offline availability. Reports and precise non-success outcomes are described, but no current launcher or engine error-handling implementation is supplied to establish comprehensive failure messaging.
The material clearly distinguishes browser, native desktop, RDP, and Citrix/VDI surfaces, plus local, customer-controlled, and managed operating models, with scenarios for developers, sensitive deployments, and partner transactions. Capability limits, maturity, API-first guidance, exact-environment qualification, and optional dependencies are specific. Full marks reflect thorough static documentation of scenarios, triggers, boundaries, and environment fit; they do not imply executed validation.
The README has strong organization across quickstart, recording, differentiators, deployment, project map, research and legacy boundaries, and support. It documents installation commands, Windows quoting, extras, and the first-use browser download. The unified CLI, compatibility extra, repository ownership split, and frozen legacy release support naming stability. The MIT text is complete, version and semantic-release configuration are explicit, and maintenance and private vulnerability-reporting responsibilities are clear. Deductions apply because there is no dedicated FAQ and the referenced and packaged CHANGELOG.md was not supplied, so changelog quality cannot be assessed.
The proposed outputs—an inspectable bundle, visualization, lint findings, REPORT.md, receipt.json, and explicit VERIFIED or halted outcomes—are directly usable for UI-only workflows and include independent effect verification. This is a concrete marginal improvement over click-success automation. The cost-benefit score is reduced because benchmark and customer-value evidence appears only as README summaries; the supplied material lacks methodology, full results, resource consumption, and deployment-cost evidence.
Many claims are tied to named artifacts, configurations, qualification boundaries, or identified cases, and the source carefully separates the synthetic tutorial, production qualification, research packages, legacy code, and the current product. README, pyproject, workflows, and license corroborate packaging, version, platform, and governance facts. Deductions apply because the core compiler/runtime, conformance tests, lockfile, changelog, benchmark method, and case-study evidence are absent, leaving central safety and zero-model-call claims primarily asserted by the README.
- This repository is primarily a launcher and compatibility surface; the core compiler, governed runtime, repair logic, and conformance tests reside in the unsupplied openadapt-flow project, so the central safety guarantees cannot be independently audited here.
- Zero model calls on healthy runs, identity gating, effect verification, and fail-closed behavior were not verified in supplied implementation code; static claims should not be treated as runtime proof.
- Before production use, qualify the exact application version, identity contract, effect verifier, and fault cases, and inspect the actual metadata or artifacts that may cross into managed services.
- Privacy scrubbing is optional and business-effect rollback is not established; sensitive or irreversible workflows need additional data-governance and recovery controls.
- Legacy tests invoke Anthropic and Google models, although the README marks legacy as frozen and outside the supported product path; packaging and test discovery should be checked to prevent accidental inclusion.
What does this agent do, and when should you use it?
OpenAdapt targets consequential work that is reachable only through human interfaces, spanning browsers, Windows, macOS, Linux, RDP, and Citrix/VDI. This flagship repository supplies the `pip install openadapt` package, unified `openadapt` CLI, and compatibility surface, while `openadapt-flow` contains the canonical compiler, governed runtime, and conformance tests. A demonstration becomes an inspectable workflow bundle that runs without generative-model calls on the healthy path and verifies business effects through an independent interface, read-only session, or reacquired persisted state. Runs produce ordered evidence, outcomes, halt reasons, and a privacy-safe local receipt; execution stops for review when authorization, identity, targeting, or effects cannot be established. Deployment can be local, self-hosted, customer-controlled, or managed, with raw recordings and observations staying local by default. The project is Beta, and production adoption requires qualification against the exact application, version, environment, identity contract, and effect verifier.
The operational path is openadapt flow record, openadapt flow compile, and openadapt flow replay: capture a human interaction and target evidence from a web, native, RDP, or Citrix surface; compile it into a bundle that separates portable intent from environment bindings; then replay it deterministically. The compiler retains structural, accessibility, visual, OCR, spatial, and transition evidence, and the runtime selects the strongest signals available on each surface. Before a consequential write, it can check authorization, workflow state, record identity, target uniqueness, and the fresh application view; afterward, it waits for settled state and evaluates the declared effect. openadapt flow visualize produces a workflow graph, while openadapt flow lint exposes deployment gaps. The quickstart creates recording/, bundle/, run/REPORT.md, and run/receipt.json, with a successful healthy run returning VERIFIED without model or Cloud calls. When explicitly permitted, a generative model may propose a repair, but the candidate is versioned and subject to review, qualification testing, promotion, and rollback.
- A healthcare or other sensitive-operations team must write into a legacy application with no suitable API and confirm the saved record through an independent read-only interface.
- An enterprise automation group needs to operate RDP, Citrix, or VDI applications from a customer-controlled runner without installing OpenAdapt inside the remote session.
- A compliance-focused team wants automation to halt on uncertain identity, targeting, authorization, or outcome instead of allowing a general computer-use model to improvise.
- A Windows, macOS, or Linux application operator wants to turn a demonstrated desktop procedure into an inspectable and replayable native workflow.
- A browser-operations team needs to execute Chromium transactions using DOM, accessibility, visual, and OCR evidence and verify the resulting business effect.
- A software or service provider needs OpenAdapt Execute to complete one authorized transaction in a qualified customer environment and return an asynchronous
VERIFIEDor precise non-success receipt.
What are this agent's strengths and limitations?
- Healthy execution is deterministic and makes zero generative-model calls, reducing model variability in consequential UI operations.
- It separates action delivery from business-effect verification and can require an independent interface, read-only session, or persisted-state check before reporting
VERIFIED. - Its fail-closed runtime retains evidence and halts when authorization, identity, target uniqueness, state, or effects cannot be established.
- One workflow model covers browser, native desktop, RDP, and Citrix/VDI surfaces while allowing raw recordings and observations to remain local.
- Bundles, graphs, lint findings, run reports, and privacy-safe receipts are inspectable, while repairs are versioned, reviewable, testable, and reversible.
- The project is Beta, and every production workflow needs qualification for its exact application, version, environment, identity contract, and effect verifier.
- This repository is the installer and unified CLI rather than the engine; core compiler and runtime work lives in the separate
openadapt-flowrepository. - Browser use downloads a matching Chromium build, while native automation requires platform-specific Windows UI Automation, macOS Accessibility, or Linux AT-SPI capabilities.
- Native, RDP, and Citrix/VDI evidence is task- and environment-specific; real-environment ICA/HDX qualification for Citrix is explicitly deployment-specific.
- The quickstart uses synthetic MockMed data, and the published 20/20 reference result and customer savings apply only to their named tasks and environments.
How do you install or deploy this agent?
Python 3.10–3.12 is required. For the browser tutorial, run python -m pip install --upgrade 'openadapt[browser]'; in Windows cmd.exe, use python -m pip install --upgrade "openadapt[browser]". Install only the capabilities needed for other surfaces: python -m pip install "openadapt[capture]", optionally combined with windows, macos, linux, or rdp; use python -m pip install "openadapt[privacy]" for PII/PHI scrubbing. The first browser action downloads its matching Chromium build. The local quickstart needs no account, API key, target application, or operating-system automation permission; real native and remote deployments require the permissions and environment qualification appropriate to their selected surface.
How do you use this agent?
After installing the browser capability, run openadapt quickstart. It records, compiles, certifies, and executes a tutorial workflow against the synthetic MockMed fixture under the Standard profile, returning VERIFIED on success. Inspect it with openadapt flow visualize openadapt-quickstart/bundle --out graph.html and openadapt flow lint openadapt-quickstart/bundle. For a real web workflow, run openadapt flow record --backend web --url https://your-app.example --out rec, then openadapt flow compile rec --out bundle --name my-workflow, followed by openadapt flow replay bundle --url https://your-app.example --run-dir run. Before production use, define the application boundary, action risks, identities, effect verifiers, fault cases, and deployment policy; the bundled tutorial is not a production certification.
How does this agent compare with similar options?
Use a supported API when the target system offers one; OpenAdapt is intended for unavoidable UI boundaries where the outcome also needs proof. Compared with a general computer-use model making step-by-step decisions, OpenAdapt compiles a demonstration into a deterministic program and keeps generative models off the healthy execution path. A model may only propose a governed repair when allowed, but this stronger control comes with the cost of qualifying each application environment and business-effect contract.
FAQ
Does local execution require OpenAdapt Cloud or a model API key?
openadapt quickstart requires neither an account nor an API key, and a healthy run makes no model or Cloud call. Cloud is the commercial control plane for managed operation, fleet governance, billing, and enterprise integrations.