Getting Stuck, and Getting Out

In one line: the agent will end up somewhere useless, and how it gets back is more important than avoiding it in the first place.

Why stuck looks different here

The previous chapter's detectors apply — fingerprint repetition, sequence cycling, no state change. Browsing adds shapes of its own, because the environment has geography.

The wrong page. A search returned results about something else, and the agent is diligently working through them. Every step succeeds; the whole trajectory is off.

The dead end. A page with no path forward — an error, a blocked region, a required login the agent cannot complete.

The trap. A page that consumes actions without progressing. An infinite feed, a carousel, a modal that reopens.

The loop between two pages. Click through, get redirected back, click through again. Each step is different; the pair repeats.

The first is the dangerous one, because no mechanical detector fires. Actions are varied and successful; the only signal is that the goal is not getting closer. Which is the plausible-drift problem again, and the same answer applies — a relevance check against the goal, run every few steps, asking whether the current page could plausibly lead to what was asked for.

The back button

The most valuable recovery action available, and it is under-used.

Browsing has something most agent environments lack: cheap, reliable state restoration. Going back returns to a known previous state at almost no cost — no re-planning, no undoing side effects, just a page the agent has already seen and understood.

Which makes a specific strategy available: treat the trajectory as a search over pages, with the ability to backtrack. Hit a dead end, go back to the last page that had unexplored options, try a different one. That is a far more robust shape than a linear plan that must be right first time.

Two things to record for it to work. Which pages had unexplored options, so backtracking has somewhere to go. And which options were already tried from each, so the agent does not re-explore.

The important caveat: back is only free for reads. Once the agent has submitted something, going back does not undo it — the page returns, the side effect does not. So backtracking is a research strategy, and transactional flows need the forward-only discipline of ordering writes last.

The recovery ladder

In order, cheapest first.

Re-observe. The cheapest possible move, and it resolves a surprising share — the page may simply have finished loading.

Dismiss the obstruction. A modal, a cookie banner, an overlay. Detect and close as an explicit step rather than clicking through it.

Go back. Return to the last known-good page and take a different option.

Restart from a known entry point. The site's home page or a search URL. Loses progress, keeps the session.

Try a different route entirely. A different site, or the site's own search rather than navigation.

Ask the user. Specific and answerable: "I can't get past this login — can you complete it?" This is often the right answer and gets skipped.

Stop and report. With what was tried and where it got to.

The ordering matters because each rung costs more than the last, and the early ones resolve most cases.

Handing over the browser

The recovery move specific to this environment, and it is genuinely powerful.

Some obstacles are things a human resolves in seconds and an agent cannot resolve at all: a login with a second factor, a human-verification challenge, an ambiguous choice only the user can make.

Rather than failing, surface the live session to the user, let them act in it, and resume. The task keeps its state, the user does the one thing they are needed for, and the agent continues.

That requires three things worth designing in: a way to display the session, durable state so the task survives the wait, and a timeout policy so a task nobody attends to is abandoned rather than held forever.

Budgets, in this environment

The previous chapter's three budgets apply, with browsing-specific character.

Steps are cheap to burn here — a page with a modal, a scroll, a mis-click and a retry is four steps that accomplished nothing. So the cap needs headroom, and the progress checks matter more than the cap.

Cost is dominated by observations rather than reasoning, because screenshots and trees are large. So an agent that observes more carefully spends more per step, which is a real trade against getting stuck less.

Wall clock is the one users feel, and browsing is slow — page loads and waits are seconds each, so a ten-step task is not fast under any circumstances. Which is the argument, again, for going asynchronous above a threshold rather than making someone watch.

Reporting a failure usefully

The output that makes a failed browsing task salvageable.

Where it got to — the final URL, and ideally a screenshot. A user can often finish from there in one click.

What it tried — the pages visited and why each was abandoned. This is what distinguishes "the information does not exist" from "I could not find it".

What it found on the way — partial results are frequently useful. Three of five prices is not nothing.

What it needs — a login, a decision, a piece of information the user has.

An agent that reports "I couldn't complete that" has discarded everything it learned. One that reports the four points above has often done most of the work.

Next: cost, latency and how to evaluate any of this.