We present WebFovea, a vision-based web agent that placed 2nd in the WebRetriever Challenge 2026 [1, 2] with a final score of 57.0 out of 100. The challenge evaluates agents end to end on Protocol III of the WebRetriever benchmark [1]: starting from an entry URL on a live website, the agent must operate the site’s own interface and return a verifiable answer. A capable multimodal large language model (LLM) is necessary for this, but not sufficient. The model’s decisions reach the browser through the harness, the code between the model and the page. At every step, four things must go right: the model’s reply must be parsed into the intended action, the action must take effect on the page, the result must be reported back accurately, and the model must be shown the information it needs. On real websites, many of the failures we observed occurred at one of these four stages rather than in the model’s reasoning. A coordinate-space mismatch placed every click at 3/4 of its intended coordinates; actions on native dropdowns, inside iframes, and in text boxes failed silently; and self-generated chat-template tokens contaminated 4.9% of task episodes. WebFovea hardens each stage and surrounds the loop with guardrails that keep the agent within the rules and its budget. The four-stage view does not depend on the model, although some individual fixes do. Because we used the same model in all four submissions, the rise of our official hidden-set score from 31.0 to 57.0 reflects changes to the harness, up to run-to-run variance on live sites. We describe the design, the evidence for each component (including negative results), a failure analysis, the limitations, and a roadmap that includes routing different steps to different models. Code: https://github.com/jianganghan/WebFovea Much of the information people and organizations need lives on public websites: statistical portals, regulatory filings, rankings, and dashboards. Retrieving it usually means navigating menus, setting filters, reading tables and charts, and only then reading off a value. Web agents that automate this are useful only if their answers can be trusted. The WebRetriever benchmark [1] evaluates such agents on 1,550 tasks on 800 real, live websites. Its Protocol III, the challenge track, asks for end-to-end retrieval: navigate from an entry URL, operate the page, and return a single answer that can be checked exactly. Success requires both a correct answer and a trajectory that actually reaches the evidence. The benchmark’s own results show why both are needed: navigation success alone is an insufficient predictor of task completion [1]. • Answer-level grounding. The answer must come from the authoritative page, reached through its interface during this session, not from parametric memory, a search engine, or a hand-crafted API call. Our logs show why this matters. After hitting a CAPTCHA, an early version of our agent answered from memory; in another task, the model wrote an entire fictitious multi-step trajectory in a single reply and submitted an answer at step 1 (§4.2). Web data also drifts: by the time we evaluated, some of the 100 public reference answers no longer matched the live sites (§5.5). In such cases, only the trajectory and the final on-screen evidence can show whether the agent’s answer was right. • Action-level grounding. Every action must land on the intended pixel or element, and its effect must be perceived correctly. For a vision-based agent, this is where many of our failures turned out to lie. Both levels depend on the harness: everything between the model and the browser. We find it useful to view each step as a round trip that passes through four stages (Figure 1, §4.1). The model’s reply is turned into an action (parsing), the action is carried out on the page (execution), the page’s reaction is reported back (feedback), and the next view shows the model what it needs (observ