False success is worse than visible incompleteness
Users can respond to a known limitation. They cannot easily respond to a system that confidently reports work as finished when it is not.
Preserve uncertainty
Missing evidence, conflicting observations and exhausted recovery attempts should remain visible in the final result.
Bound recovery
Allow sensible retries or alternate routes, but cap them. A safe system knows when to stop and ask for human input.
Verify consequential changes
For important state changes, check the resulting state independently rather than relying on the action acknowledgement alone.
Example: a file that might have been saved
An agent asks a writing tool to save a report. The tool times out. A weak agent reports “saved” because it issued the command; another blindly retries and may overwrite newer work. A safer agent checks whether the intended file exists and contains the expected material. If the read-back is not possible, it reports the save as unverified, not finished.
Give users useful status labels: completed and verified when the outcome matches the request, incomplete when evidence is missing, and failed when a requirement demonstrably was not met. The text should also say what remains to be done. See independent read-back verification for the check itself.
Public product claim
A vendor can credibly state that its agent fails safe and verifies outcomes without disclosing the private decision states, retry policy or completion algorithm.