The browser agent clicked Approve after the page changed. What did it approve?

A successful click says a pointer event was delivered. It does not say the intended business action was approved. The screenshot was an observation at one time. A coordinate selected from it is not a durable identity for the row or the credit. Even a fresh DOM locator can find a new element with the same button label after the page re-renders. Playwright's actionability checks can establish that a clicked element is visible, stable, enabled, and receiving events. Those checks help with UI mechanics. They do not prove that customer A and $100 are still the effect behind that button.

I would make the agent propose a canonical action from the observation: credit ID, account ID, amount, currency, and intended verb, plus the page or record version if available. The runtime, not the model, decides whether this action is allowed. If the product owns the application, the right fix is a backend endpoint that accepts that exact action and a resource version, performs authorization and a conditional commit, and returns an operation ID. The UI click can open a preview, but the effect should be bound to data the server verifies. This is the same business precondition problem as a stale human approval, with an extra perception problem: the agent may not even have clicked the same record it saw.

For a site we do not control, narrow the promise. Re-read the page immediately before interaction, locate by semantic role and nearby account or credit identity rather than coordinates, and inspect the target's accessible name and surrounding values. If the site offers a confirmation screen, verify its exact effect and require a human confirmation for high-impact writes. Do not assume a confirmation screen is a transaction lock. A re-render can occur between this check and the click, so the browser client cannot guarantee an atomic compare-and-set over the site's business state. With no conditional API, a high-impact autonomous approval may simply be outside the supported product boundary. The agent can prepare the case and hand it to a human using that site's official workflow.

The click itself can time out after the server committed. Treat that as unknown, not as permission to click again. Look for the provider's operation ID or query the record's current state, while accounting for other operators who may have acted. If a success toast says “Approved” but omits the customer and amount, it is weak evidence for this particular action. A stronger receipt names the approved record and effect. Do not use a screenshot hash as an idempotency key. The same pixels can hide different backend state, and the same action can render differently.

Suppose the page updates so quickly that stable locators keep failing, but support leadership wants a throughput target. That is evidence the browser is the wrong write interface. Ask the third party for an API, export-and-import workflow, or human review lane with a clear cost and latency. Raising click retries until one lands trades throughput for wrong-account risk. If only read-only research is required, the browser agent can still be useful. The autonomy boundary can differ between observation and effect.

For a real rollout I would test row reorder, virtualized lists, same-label buttons, overlays, stale tabs, concurrent operators, lost click responses, and a confirmation page that changes after preview. Record the observed row identity, proposed action, pre-click verification, actual submitted target when observable, and final receipt. The metric is correct approved effects with no wrong-account writes, not the percentage of clicks that returned success.