Admitted capabilities, then a process
You get two independently admitted programs and a parent receipt that names both admission ids. The one fact that crosses from the first program into the second is a patient_id that the first program’s Effect already CONFIRMed. flowchart LR intake["intake<br/>admission_id 7c2a9e14-4b11-4e08-9c3a-0f6d2a1b8e44"] posting["posting<br/>admission_id 3f81b0c6-91d0-4a77-b2e5-18c04d9f5a12"] intake -->|"patient_id<br/>Effect CONFIRMed"| posting Those admission_ids are examples. A live envelope uses a UUID and binds a bundle digest. It expires in 30 days. Inspect the receipt. It has to name both. ...
Record each surface, then compose
You record intake on the EMR. You record posting on billing. OpenAdapt copies patient_id from the first program into the second only after intake ends VERIFIED. openadapt-flow compose \ --child intake=./intake-bundle \ --child posting=./posting-bundle \ --handoff intake.patient_id=posting.patient_id \ --out composed That’s a two-app workflow with one named fact. Child B doesn’t start on a guess. If the fact is missing, the parent HALTs. Computer-use agents do something else. They treat the whole desktop as one environment, screenshot in and click out, and they stall when the work crosses a window. ...
The user of OpenAdapt is an agent. The human is the authority.
We did not turn OpenAdapt into an agent. We admitted who already drives the loop. If you have been watching platform engineering this year, the shift is not subtle. Salesforce spent two and a half years exposing Headless 360 so an agent can call the product without a browser. Stripe and others built payment rails the same way. Arthur Frayman’s line at SCaLE is the one I keep: the human you used to build for is becoming an agent operated by a human. Agents do not need a pretty cockpit. They need constraints, typed actions, and an escalation path that is designed rather than an error dialog. ...
What does openadapt quickstart --break-it do?
OpenAdapt compiles a demonstration into a program. The program reports VERIFIED only if an independent check agrees. That check is a second interface reading the system of record. The GUI can paint a success banner after the server has already dropped the write. --break-it is the command that makes that lie happen on purpose, on a machine you already have. pip install openadapt openadapt quickstart openadapt quickstart --break-it pip install openadapt puts the launcher on your PATH. openadapt quickstart records the bundled MockMed clinic task and compiles it. Then it certifies the bundle and runs it. The write travels through the GUI. The confirmation doesn’t. A read-only path asks whether the intended record exists with the intended values. It uses a different HTTP verb than the write, over a different connection. Agreement is VERIFIED. Disagreement is a halt. ...
The One Number That Drifted Was the One That Changed: Why We Started Checksumming Our Own Benchmark Claims
Our MockMed comparison page said the baseline agent made 24 model calls per run. It made 13. All 20 baseline rows in the retained results record api_calls: 13. The 24 belonged to a single separate theme-drift run, folded into the headline number as if it were typical instead of an outlier from a different experiment entirely (openadapt-web#387). That correction landed August 26. It was not the last one that week. ...
OpenAdapt vs. AutoHotkey: when a macro becomes shared infrastructure
AutoHotkey’s Send functions send simulated keys and mouse clicks to the active window. That sentence explains both the appeal and the risk. A personal macro can remove many tiny interruptions from a week. The author usually runs it, watches it, and understands the whole script. If the wrong window has focus, the failure is visible to the person who can fix it. I wouldn’t replace that with a workflow platform. AutoHotkey gives careful authors better options Coordinates and the active window aren’t the whole language. ControlClick and ControlSend can address a Windows control directly. Window waits can block until the expected application appears. Control functions throw errors when a target can’t be found or an operation fails. ...
OpenAdapt vs. computer-use agents: should every run think again?
I like computer-use agents for a practical reason: I can give one a goal instead of a script. It can inspect an unfamiliar screen, decide what to do next, and recover from situations I didn’t predict. That flexibility has a cost. The model has to inspect and decide again on every run, even when the task has become routine. The useful OpenAdapt vs. computer-use-agent question is about the shape of the work: should each run interpret the task again, or should it replay a reviewed program and stop when reality differs? ...
OpenAdapt vs. Playwright: why Playwright stays in the browser path
I like Playwright enough that OpenAdapt uses it. Its locators favor roles, labels, visible text, and explicit test IDs. Its actionability checks wait for a target to be visible, stable, enabled, and able to receive an event. The trace viewer records the action, source line, DOM snapshots, network activity, and screenshots that make a failed run debuggable. Throwing that evidence away to make every execution surface look the same would be a mistake. ...
OpenAdapt vs. Power Automate: where Microsoft's advantage ends
On 2026-08-26, Microsoft lists Power Automate Premium at $15 per user per month, Process at $150 per bot, and Hosted Process at $215 per bot, all paid yearly. Those plans cover cloud flows, attended or unattended desktop automation, and a Microsoft-hosted VM at the top tier. The published pricing is unusually clear for enterprise automation. That price buys access to an ecosystem along with the recorder. The Microsoft path is hard to beat Work that starts in Outlook, passes through Excel or Dataverse, needs an approval in Teams, and ends in SharePoint already has machine interfaces inside Power Automate. A connector can move the data without opening a page or finding a button. ...
OpenAdapt vs. Selenium: the transaction layer around WebDriver
Selenium WebDriver is a W3C Recommendation. It drives browsers locally or through a remote Selenium server, with language bindings around the browser-control implementations. Selenium Grid routes those commands to remote browser instances and runs tests across machines, browser versions, and operating systems. I wouldn’t replace a working Selenium fleet because a newer tool has a cleaner demo. WebDriver owns browser commands A Selenium program can navigate, find elements, click, type, wait, inspect state, and assert what the page shows. The program can also call the rest of the team’s code. A database read-back or API check can decide success. A queue, audit log, approval step, or retry rule can sit around the browser session. ...