OpenAdaptHow do you know an automation saved the record?
Read the record back another way after the save: through a read-only API, a report export or a database read, not the screen the automation typed on. Compare every field you meant to change, and check nothing extra was created. A "Saved" message shows a save happened, not that it went to the right record.
Updated 2026-10-18
Which checks count?
| Check | What it catches | What it misses |
|---|---|---|
| The success message on screen | A save that obviously failed | A save into the wrong record, a wrong value, or a missing field |
| The automation's own report | Steps that errored | Anything it didn't notice |
| A screenshot read by a model or OCR | Text on the screen | Data that isn't on that screen |
| A second read of the record (API, report, database) | Wrong values, missing saves | Fields and tables the read doesn't cover |
| A read plus a count of what changed | Extra or duplicate records too | Changes outside the systems it can read |
How often does a screen-only check miss?
In our fault test, 72 of 90 runs left the record wrong. A screen-only check passed 54 of those 72. Reading the record back over the app's API passed 9 of them, all of one kind: a write to a table that read didn't cover. The full database read caught all 72. These were faults we injected into our own engine on a test system: a coverage test over a fixed list, not a real-world error rate.
Our research on task checkers found published checkers that confirm the requested change but accept runs that also made a change nobody asked for, such as a duplicate record.
What to ask any vendor
- What reads the saved record, and is it a different path from the one that typed it?
- Which fields and tables does that read cover, and what would it miss?
- What happens when the read disagrees, or can't run?
- Will it ever retry a save it couldn't confirm?
- How many runs ended unconfirmed last month, not only how many succeeded?
Where OpenAdapt fits, and where it doesn't
OpenAdapt reads the saved record back another way, where your system allows a second read, and calls the entry "Done and checked" only when every field matches. When it can't read the record back, it says "Finished, not checked", and we don't run saves that way.
If an API covers the task, use it, and let a read through that API be the check. You can try the check on a laptop. This command runs a test entry where the save doesn't land, and OpenAdapt stops:
uvx --python 3.12 openadapt quickstart --break-itRelated: How it works: the record check · Your agent alone, or with OpenAdapt
Sources
- OpenAdapt fault test, openadapt-flow benchmark/effect_e2e, 2026: faults injected into our own engine on a test record system, 90 runs; 72 left the record wrong. A check of the screen alone passed 54 of those 72; a read-back over the app's REST API passed 9 of them; the full database read caught all 72. A coverage test over a fixed fault list, not a real-world error rate.
See it on your process
Bring one task your team types every day. We'll tell you whether it fits, and what a test on your own system would cover.