The comparison you open with, an endpoint that returns 200 after writing the wrong value, is the clearest way I have seen to explain why an agent's done is not evidence. The success signal comes from the same process that made the mistake, so it cannot also be the check.

Reading the changed records back is the right fix, and I would pair it with one more step: write down before the run what those records should look like afterwards. Which rows, which fields, which values, and what must stay untouched. Then the read-back is a comparison against an expected state, rather than the agent inspecting its own work and deciding it looks fine.

We use the same idea when scoping client work: the finish line is written before anyone starts, so done means the same thing to everyone involved. How do you handle records the agent changed that were never in the plan at all?