The Contract a Reliable Browser Agent Must Keep
Reliable browser agents are the subject of this final synthesis. The question is what must remain aligned when an agent searches, sees, remembers, acts, and evaluates progress on a changing web page. The answer supported by BrowseComp-V3 and RunAgent Super Browser is a practical contract: every action needs a sufficiently fresh and scoped percept, a checked page state, an appropriate memory record, and an outcome that can be traced through the task's evidence chain. That contract is useful for judging systems, even though the two preprints do not prove one universal architecture.
The title's apparent paradox now has a precise explanation. A browser agent can be right about a visible label and wrong about the control; right about a fact and wrong about the entity; right about a dispatched event and wrong about the resulting state; or right at every local step and still fail to connect the final relation. Reliability is not a property of perception, memory, or action in isolation. It is the property of their references continuing to agree.
One reliability problem, five interfaces
The first interface is between the goal and the percept. A screenshot is useful only relative to an active purpose. A page may contain dozens of controls, but the relevant one is the control that advances the current subgoal. RunAgent Super Browser makes that scope explicit by passing the active subgoal into candidate generation and ranking. BrowseComp-V3 shows why the distinction matters: its deep tasks distribute evidence across text, images, and multiple hops, so what counts as relevant changes as the evidence chain develops.
The second interface is between the percept and the page state. A visual box describes an appearance at a moment; the DOM, embedded documents, active controls, and URL describe what the browser can act on now. Super Browser therefore enriches visual candidates with interaction metadata and compares page-state fingerprints before allowing procedural reuse. A cached selector is not a fact about the web. It is a temporary hypothesis whose authority ends when the relevant state drifts.
The third interface is between page state and memory. A long task cannot keep every screenshot equally alive without allowing obsolete state to compete with current state. The Ledger preserves the goal, active subgoal, recent outcomes, qualified facts, checkpoints, and negative landmarks while eviction removes or compresses raw material. This is not simply a choice between a short and a long prompt. It is a choice about what should remain authoritative after a page transition and what should be demoted to an archival trace.
The fourth interface is between memory and action. A remembered intention must become a target with an interactive owner. The compound “United States” row demonstrates why semantic resolution matters: the large label and the small expansion control may occupy one visual region but represent different state transitions. A Ledger entry saying “open the region filter” cannot itself decide which sub-element receives the event. The action layer must combine visual location, DOM semantics, and current subgoal before dispatch.
The fifth interface is between action and outcome. An event can be sent without changing the intended state. A page can change without advancing the intended subgoal. A URL can return a valid page that is scoped to the wrong location or filter. Super Browser's no-effect guards, mutation and URL checks, and post-navigation re-grounding all express the same principle: completion is a verified transition, not a tool call that returned successfully.
These interfaces form a chain rather than a stack of independent features. A stale percept can cause a wrong action; the wrong action can create a misleading page state; the misleading state can be summarized into memory; and that memory can bias the next plan.