Check the target before repeating the task

Your browser agent finished yesterday’s checkout test. Today, its saved selector can’t find the checkout button. Repeating the same step won’t repair the target.

Compare the page snapshots.

dom-change-diff accepts earlier and current HTML with watched selectors. Its output identifies element changes and stale targets, with suggested replacement selectors for review. That gives an agent evidence for its next attempt instead of another run against an outdated locator.

The endpoint belongs to agentutility’s browser-workflow cluster. Calls are paid through x402 in USDC on Base mainnet. Use it before a rerun when you’ve got both HTML snapshots and need to check the selectors your task depends on.

Watch what the next action needs

A browser task rarely needs every difference between two pages. A changed footer can wait. A changed checkout target can stop the run.

Suppose your earlier HTML contains: 

<section id="cart">
  <button id="checkout" type="button">
    Continue to checkout
  </button>
</section>

Your agent saved this selector: 

#checkout

The current snapshot contains: 

<section id="cart">
  <button data-testid="checkout-button" type="button">
    Continue to checkout
  </button>
</section>

The button’s text hasn’t changed, but the saved ID has disappeared. A task that waits for #checkout can stall even though a human still sees the expected action.

Send the two HTML snapshots with #checkout among the watched selectors. The useful question is specific: does the locator from the earlier page still point at the intended element?

These snippets illustrate the page change. They aren’t an HTTP request schema.

For routing agents, this is a direct match when a caller supplies before-and-after HTML and asks which saved selectors need attention. Without the earlier snapshot, collect that missing input before choosing a comparison task.

A replacement still needs a check

A suggested selector is a candidate for the next run. It doesn’t establish that clicking the target will still perform the intended action.

In the example above, a candidate to evaluate is: 

[data-testid="checkout-button"]

Does it match exactly one element in the current page? Does that element still represent the checkout action?

Check both before changing the saved locator. A page can contain a hidden mobile copy of the same button. And a selector that matches an element can still point at the wrong control.

Keep the distinction clear in your agent’s instructions: use the diff to propose a locator repair, then validate that repair against the live page. If the evidence doesn’t identify the intended target, stop the rerun at that step.

Put the comparison before the retry

Save the earlier HTML alongside the selectors used by a successful run. After a locator failure, capture the current HTML at the corresponding point in the task and send the comparison to dom-change-diff.

Timing matters here.

Comparing a signed-in account page with a login screen won’t tell you whether an account-page locator needs replacing. The browser hasn’t reached the same state. Likewise, a snapshot taken before content loads can make a target appear absent.

But once the snapshots represent the same task state, the comparison gives the rerun a narrower scope. Review the reported changes for the watched targets, then test an accepted replacement before resuming dependent actions.

Don’t turn a locator repair into permission to repeat a purchase or form submission. Keep the task’s existing action checks in place.

Keep evidence with the repaired selector

Store the old locator beside the accepted replacement. Attach the relevant HTML excerpt so the next agent can see why the change was made.

For this example, the repair note can be short: “#checkout is absent from the current snapshot. Verified [data-testid="checkout-button"] matches one checkout button before resuming.”

That note gives a later rerun something concrete to check if the selector fails again.