UiPath Orchestrator can provision, deploy, trigger, monitor, measure, and track attended and unattended robots. It connects to enterprise credential stores, retains an audit trail, and supports cloud or customer-managed deployment. That is the scope UiPath describes on its Orchestrator product page. OpenAdapt has no credible answer to “replace our entire UiPath program.” I wouldn’t offer one. A fleet needs a platform At a large organization, the robot is one component. Studio produces packages. Orchestrator assigns machines, schedules jobs, tracks queues, records audit events, and gives an operations team a central control surface. Attended robots help employees; unattended robots handle back-office work. ...

I use a blunt rule for OpenAdapt vs. an API: call the supported API first. If it exposes the complete operation, the decision is over. A direct call avoids screen rendering, focus, pointer movement, OCR, and visual target resolution. Requests are easier to test than clicks. Authentication is explicit. The service owner can preserve the machine contract while changing the interface people see. OpenAdapt handles the part that rule leaves behind. ...

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