How do you know an automation actually 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, or the automation's own report, can be wrong.
Updated 2026-10-14
Which checks count?
| Check | What it catches | What it misses |
|---|---|---|
| The success message on screen | A save that obviously failed | A wrong or partial save that still shows "Saved" |
| 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, and a screen that's wrong |
| 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 check that trusted the success banner passed 54 of those 72. One separate read of the record passed 9 of the 72, all of one kind: a write to a table the read didn't cover. These were faults we injected on a test system.
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: the tutorial includes a run where the screen says saved and the record didn't change.
openadapt quickstart --break-itRelated: How it works: the record check · OpenAdapt vs AI agents
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 that trusted the success banner passed 54 of those 72; one separate read of the record passed 9 of the 72. These were faults we injected on a test system.
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.