Verification

In one line: after a click, the agent has a belief about what happened and no evidence for it, and the whole trajectory is built on that belief.

Why this is the load-bearing stage

An agent that acts and proceeds is compounding an unverified assumption. If the click did nothing — hit an overlay, hit a disabled control, hit an element that had moved — the next observation is of a page the agent did not expect, and it will interpret that page through a belief that is already wrong.

The result is the characteristic browsing failure: not an error, but a trajectory that quietly diverges from reality and then produces a confident wrong answer or a stuck loop.

State the expectation first

The mechanism that makes verification possible, and it is a small change with a large effect.

Before acting, the agent states what should change. Not a justification — a checkable prediction. "Clicking this should navigate to a product page whose title contains the item name." "Typing here should populate the field with this text." "Submitting should show a confirmation or an error."

Then after acting, compare. An expectation that is not met is a signal, immediately, rather than a divergence discovered eight steps later.

This is exactly the precondition idea from the planning lesson of the previous chapter, applied one level down: a step that predicts nothing cannot be checked.

What to compare

Cheap signals first, because verification runs on every step.

The URL. Changed or not, and to what. Nearly free, and it settles most navigation questions immediately.

The page title. Also nearly free, and often decisive.

Presence or absence of a specific element. The confirmation message appeared; the form is gone; the item count incremented. Precise, and it requires the expectation to have named something.

A visual diff. Did the page change at all? Coarse, and it distinguishes "nothing happened" from "something happened" without any semantics — which is exactly the distinction that matters for a no-op click.

A full re-observation. Expensive, and the fallback when the cheap checks are ambiguous.

The design point is that these form a ladder, and most steps are settled by the first two. Running a full re-observation after every action is affordable in a demo and not in a system that does ten steps per task.

The three outcomes

Verification does not return true or false. It returns one of three, and they need different responses.

As expected. Continue.

Nothing happened. The most common failure. The click missed, hit a disabled element, or was intercepted. The response is to re-observe and try a different approach — not to repeat the same click, which is the repetition the previous chapter's fingerprint detector exists to catch.

Something unexpected happened. A modal appeared, a redirect fired, an error is displayed, the session expired. This is not a failure to retry — it is new information, and the correct response is to re-plan from the new state.

Conflating the second and third is a common bug. An agent that treats "unexpected page" as "the click failed" will retry into a modal forever.

Verifying the task, not just the step

The larger version, and it is what stops an agent declaring success on a plausible-looking page.

A step-level check confirms the click worked. A task-level check confirms the goal was achieved — and for browsing that usually means finding evidence on the page rather than trusting the trajectory.

Booking something means a confirmation page or a reference number, not merely that the submit button was clicked. Finding a price means the number was read off a page that was actually about the right product. Filling a form means the review screen shows what was intended.

That last one is worth designing in for transactional flows: stop at the review step and re-read what is about to be submitted, comparing against the original intent. It is the cheapest possible protection against a trajectory that drifted, and it lands exactly where the human confirmation belongs anyway.

The evidence problem

One honest limitation.

For a read-only research task, the agent's answer is a claim about what a page said. Verifying that means keeping the evidence — which URL, which element, what the text was — so the answer can be checked rather than trusted.

So a browsing agent should return citations in the same sense as a retrieval system: the answer, and the page and passage it came from. That makes the output checkable by the user, gives you something to evaluate against, and it is nearly free because the agent had the page open.

An agent that returns a fluent summary with no sources has produced something indistinguishable from a guess, which for a system whose entire purpose is reading the live web is a strange thing to ship.

Next: the page as an adversary.