Automation

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. ...

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. ...

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. ...

A team I would recognize anywhere runs four hundred UI automations against a system somebody else owns. The dashboard is green. The success rate has been 98-point-something for a year. Then a reconciliation turns up eleven records that were updated with values belonging to a different account, all in the same month, all in runs the dashboard counted as successes. Nothing crashed. No exception was thrown. Every one of those runs saw a confirmation banner and believed it. ...

Every team running GUI automation lives with the same quiet worry: that a bot clicked the wrong row, wrote to the wrong record, or did nothing at all, and reported success anyway. We measure that as the silent-wrong-effect rate, and by red-teaming our own engine hard against failure after failure we cut the share of wrong writes that go undetected from 75% to 12.5% with a single out-of-band check on the system of record. There is an honest limit to that work, and it is worth saying plainly: an engine can only refuse the failures it has already met. The residual misses are all one class — a collateral write to a surface the check does not read — and closing that kind of gap is exactly what a wider corpus of real failures buys. ...

Most software robots re-read the manual every single time they run. A person who has done a task a hundred times does not re-derive it on attempt 101. The robot does. A general computer-use agent looks at the screen, thinks, picks an action, looks again, thinks again, all the way to the end, every run. For a task nobody has seen before, that is exactly right. For the tenth-thousandth triage note in the same clinic, it is a strange thing to pay for: latency, model cost, and a plan that comes out slightly different each time. ...

A crashed bot is a support ticket. A bot that writes to the wrong record (or writes the wrong thing, or writes nothing at all) and then reports success is a different kind of problem, and almost nobody publishes a number for it. Nothing pages anyone. The dashboard is green. The error surfaces later, owned by whoever owns the record it landed in: a note in the wrong patient’s chart, a payment posted to the wrong loan. And the defining property is that the tool’s own verification passed. It confirmed that something was saved. It never checked whose record it was, or whether the database agrees with the banner. ...

Computer-use agents can take a screenshot and a goal, then choose the next click without selectors or an application API. That still feels a little like magic to me. Watch one do the same short task for the fiftieth time, though. It calls the model again on every run. You pay for those calls in seconds and tokens even when the screen and goal haven’t changed. That’s the right shape for a task nobody has automated before. It’s the wrong shape for the 500th referral this month. ...

The obvious objection to the 500th run was “sure, it’s your demo app.” Fair. So on 2026-07-08 we ran the same head-to-head against the official OpenEMR public demo: a dense, frame-heavy, LAMP-era EMR that anyone can point software at, fake patients only. Quick recap of what’s being compared. openadapt-flow compiles a recorded demonstration (browser, desktop, Citrix) into a deterministic workflow. Every step carries redundant visual evidence (a template crop, an OCR label, geometry landmarks) plus postconditions derived from what your demonstration actually changed on screen. A healthy run makes zero model calls. When the UI drifts, a resolution ladder heals the step and writes the fix back as a reviewable diff. When verification fails, it halts. It doesn’t improvise against a patient chart. ...