Browser postcondition coverage is becoming an AI agent reliability metric

Browser agents are being judged less by whether they can press the right control and more by whether they can verify the resulting state.

Traditional task benchmarks often reward a successful-looking interaction sequence: navigate, fill, click, and observe a confirmation. Production failures concentrate around the gap after the click. The session closes, navigation stalls, a provider responds slowly, or the screenshot is lost. The agent no longer knows whether the external system committed the action.

Postcondition coverage measures how much of the agent’s side-effecting browser surface has an explicit, independently testable success condition. A publish action might map to a live revision record. A booking action might map to a confirmed appointment ID. A checkout action might map to a correlated order and payment authorization.

The metric matters because safe replay depends on it. When a postcondition is present, the system can verify completion, prove absence, or preserve an honest unknown state. Without one, a generic retry policy can create duplicate orders, messages, bookings, and releases.

Buyers will increasingly ask not only how often agents finish cleanly, but what percentage of consequential actions can be reconciled after confirmation is lost. That question turns an invisible engineering discipline into a diligence signal.

The metric becomes theater when teams maximize the numerator without improving recovery.

The easiest distortion is declaring weak visual cues to be postconditions. A button becoming disabled may only mean the request started. A confirmation page may load before asynchronous processing completes. A list search miss may reflect lag or wrong filters rather than true absence.

A second distortion is shrinking the denominator. Teams may instrument low-risk, stable targets while excluding the consequential workflows where evidence is difficult. Buyers should ask for coverage by effect severity and the explicit list of uncovered actions.

A third is measuring definitions rather than tested behavior. A repository can contain postcondition functions that are never called after real failures. Failure injection should close the loop: interrupt after the action, open a fresh session, classify the effect, and verify the final state.

Finally, a high manual-review rate may be appropriate for dangerous targets. The goal is not automatic replay. It is correct classification and safe outcome. Honest unknown states can indicate stronger reliability than confident guesses.