The Browser Agent Timed Out After Clicking “Buy.” Do Not Click Again Yet.

The agent has filled in the order form and clicked Buy. Then the page freezes. No receipt appears, no confirmation arrives, and the task looks unfinished. Another click seems like the obvious recovery.

Except the order may already exist.

This hypothetical purchase exposes a difficult moment for an AI assistant operating a browser. It knows what it intended and what it can see, but those observations don't establish what the supplier actually did. Persistence, which helped it navigate the site, could now turn one uncertain order into two.

The missing receipt leaves a question open

We know the agent submitted an authorized order, but we do not yet know whether the supplier completed it. Until that result is confirmed, neither success nor failure is a safe assumption.

An order record or authoritative receipt can resolve that question. The original request and any stable transaction identifier help connect the evidence to the attempted purchase. The agent sounding confident that the click “probably worked” doesn't provide the same information.

I would pause further purchasing actions while checking that state. Reopening a page to inspect an order and pressing Buy again are different operations: one may gather evidence, while the other may create another obligation. Computer-use guidance is relevant to that distinction between navigating an interface and taking consequential action. [1]

Waiting longer doesn't answer whether you already bought it

Two technical ideas often appear in retry discussions: idempotency and backoff. They solve different problems.

An idempotent operation is designed so repeating the same logical request doesn't repeat its effect. A purchasing system that supports an appropriate request identifier can recognize a second attempt as the same order. The protection must exist where the purchase occurs; an identifier written only in the agent's notes cannot make a supplier honor it.

Backoff spaces attempts apart, giving an unavailable or overloaded service time to recover. That may improve the chances of a response. It doesn't reveal whether the earlier purchase already happened.

For the frozen page, a longer wait is therefore not enough to justify buying again. The decision depends on the order's state and the duplicate protection the target actually provides. Where neither can be established, human investigation may be necessary before another consequential action.

Three possible findings lead to different next moves

These are findings about the supplier's state, not three levels of model confidence. A more persuasive summary cannot move the purchase from the third row to the first.

The handoff should prevent a second accident

An operator receiving the case needs the attempted purchase, the missing confirmation and the checks already made. A useful handoff might say, in this fictional situation:

Buy was submitted once. No completion receipt was returned, and the order status has not been established. No second purchase has been attempted. Please verify the original request with the supplier before retrying or canceling anything.

The operator then knows why the task stopped and what must be resolved. Canceling an existing order, reversing a payment and making a new purchase can require different authority; the browser's Back button is not a reversal mechanism.

This is also a revealing rehearsal before allowing live buying. A demo that always returns a receipt won't show whether the service can handle an order created without a confirmation page or a late response arriving after escalation. The person who inherits those cases should be part of the test. [2]

If every uncertain purchase requires manual detective work in another system, that is a design opportunity. A supported status interface may remove much of the investigation. Until then, stopping at the frozen page is not abandoning the customer's task. It is recognizing that the next useful step depends on finding out whether the task has already been completed.