The rule that a run may report done only after a separate read matches the expected state is the right standard, and the refund example shows why: a refund record, a ledger entry and a customer visible status are three facts, and a 200 proves at most one of them.
What I like about the expected state contract is that it is written before the tool is called. Most of the false success cases I have seen were not model problems. Nobody had written down what finished meant, so the agent repeated the success message it was given. Listing the fields allowed to change and a deadline for downstream effects also gives the verifier a clear point where it must say unknown rather than done.
The same habit helps outside agents. When we scope client work, each problem gets a short written end state and a way to check it, and that removes most arguments at handover. How do you handle effects that arrive after the deadline, such as a late provider callback?
Kartik N V J K
AI Developer | Making AI reliable, trustworthy & accessible to everyone | Active community contributor
I once watched a trace go green end to end on an agent that had done nothing, so the 200 OK table landed. Every retry wrapper I've written should have treated a timeout as unknown instead of failed. Who writes the expected-state contract in your setup? If the agent drafts it before the call, it can write a finish line it already knows it will cross.