PaperlayerView exact revision on arXiv

Source-linked AI summary

Web$hell: A Unified Interface for Agentic Web Access

Sunghwan Kim, Deogyong Kim, Sangam Lee, Donguk Kwon, Dongha Lee

arXiv:2610.13416v1cs.AIcs.IR

TL;DR

Long-horizon web tasks call for information gathering, browser interaction, and revisiting evidence, but existing access models separate these capabilities and combinations can carry costs or trade-offs. WEB$HELL unifies web access through addressable compiled objects and persistent access, achieving the highest task performance on six benchmarks at comparable or lower cost.

  • Problem

    Long-horizon web tasks require information gathering, browser interaction, and revisiting evidence, while existing access models largely develop these capabilities separately and combinations can involve costs or trade-offs.

    Source: §1 · p. 1

  • Method

    WEB$HELL standardizes webpages as addressable information and action objects, compiles live pages, and retains them for selective access through a shared interface.

    Source: §1 · p. 2, §4.1 · p. 5

  • Results

    WEB$HELL achieves the highest task performance on all six benchmarks at comparable or lower cost; in Deep Research, CLI-Anything Browser uses 52.4 vs. 17.6 turns.

    Source: §1 · p. 2, §5.1 · p. 8

  • Takeaways & Limitations

    Analyses indicate that connecting webpage elements helps agents gather more evidence, makes browser actions more intuitive, and may guide exploration beyond inspected content.

    Source: §1 · p. 2

Abstract

from arXiv · show

Large language model (LLM) agents are becoming direct users of the open web. As they take on increasingly complex and information-intensive tasks, effective web access is becoming a core capability for agentic problem solving. Existing approaches have advanced agentic web access through different access models, including search-augmented agents, browser-based agents, and, more recently, filesystem-based agents. Nevertheless, as users expect agents to complete long-horizon, end-to-end tasks, they increasingly need to conduct broad information gathering, perform browser actions, and revisit acquired evidence within a single trajectory. Yet our preliminary analyses reveal that existing access models struggle to meet these demands. They primarily support either information gathering or browser interaction, while combining their capabilities can involve substantial costs or performance trade-offs. To this end, we present Web\$hell, an interface that unifies web access under a single access model. Using a common schema defined by WebContract, WebCompiler compiles live webpages into addressable information and action objects. These objects are maintained in WebCache and handled through a shared set of operations, providing agents with consistent, operable, and persistent web access. Through extensive experiments across web search, web navigation, and deep research benchmarks, we show that Web\$hell achieves strong task performance at lower cost. Our results further indicate the importance of interface design for effective web access, with Web\$hell opening new possibilities for more capable and efficient LLM agents on the web.

1 INTRODUCTION

As web tasks grow longer and more information-intensive, agents need to gather information, interact with webpages, and revisit evidence in one trajectory. The paper identifies limitations in existing access models, proposes a unified interface, and reports strong performance across diverse web tasks.

Motivation

  • Existing search-, browser-, and filesystem-based approaches largely develop web access separately, although long-horizon tasks require multiple forms of access within one trajectory.A shopping task, for example, can require product discovery, pagination to find reviews, and retaining information for comparison.Source: §1 · p. 1
  • Search and filesystem agents can lack page controls, browser agents face lengthy, noisy observations, and combining access models can add cost or trade off navigation performance.Selective inspection can reveal relevant text while omitting context needed to use page controls.Source: §1 · pp. 1–2
  • The paper identifies three requirements for unified access: operability for gathering information and interacting, consistency to reduce repeated interpretation, and persistence for selective access to retrieved documents.Persistence is intended to lower costs while preserving operability.Source: §1 · p. 2

Proposed interface

  • WEB$HELL uses WebContract to define addressable information and action objects, WebCompiler to compile live pages, and WebCache to retain them for selective reuse.Agents use object addresses to request information or execute actions through a shared request–response loop.Source: §1 · p. 2

Results

  • Across six benchmarks spanning web search, navigation, and deep research, WEB$HELL achieves the highest task performance at comparable or lower cost.The analyses also report robustness to irrelevant content and maintained efficiency as retrieved documents accumulate.Source: §1 · p. 2

2 RELATED WORK

Prior work develops search, navigation, and filesystem-based web access through distinct approaches. WEB$HELL instead unifies their capabilities at the interface level, while related interface-design methods have varied in scope and practical demands.

Agents for Web

  • Search agents use search APIs and cleaned text, browser agents use page observations and actions, and filesystem methods store webpages for selective inspection.The paper characterizes these lines of work as largely developing web search and navigation within separate access models.Source: §2 · p. 2

Interface for Agents

  • Webpage simplification and enhancement methods modify page representations, while WebMCP and NLWeb rely on website providers to package site-specific functions and content.The cited representation approaches may require additional model inference or extensive offline traversal; provider-based approaches apply within a limited scope.Source: §2 · pp. 2–3
  • WEB$HELL standardizes web access through common representations and operations, extending interface design toward general web access.The paper describes its interface as operable, consistent, and persistent.Source: §2 · pp. 2–3

3 PRELIMINARY ANALYSIS: CAN AGENTS EFFECTIVELY ACCESS THE WEB THROUGH EXISTING ACCESS MODELS?

The preliminary analysis examines whether existing access models generalize across web search and navigation, and what happens when they are combined. It finds that hybrid access can broaden task coverage but introduces cost or performance trade-offs.

3 PRELIMINARY ANALYSIS: CAN AGENTS EFFECTIVELY ACCESS THE WEB THROUGH EXISTING ACCESS MODELS?

  • The analysis frames its questions around whether existing access models generalize across web search and navigation and what limitations remain when models are combined.The setup describes WideSearch as broad information gathering and WebArena-Verified as deeper, multi-step website interaction.Source: §3 · p. 3

3.1 ANALYSIS I: CAN EXISTING ACCESS MODELS GENERALIZE ACROSS WEB TASKS?

  • Cross-task comparisons show that access models struggle beyond their primary tasks: navigation-oriented agents are evaluated on WideSearch and search-oriented agents on WebArena-Verified.Figure 1 presents these cross-task results against the other group’s average performance on each benchmark.Source: §3.1 · p. 3, Figure 1 · p. 4

3.2 ANALYSIS II: WHAT LIMITATIONS REMAIN WHEN ACCESS MODELS ARE COMBINED?

  • 66.0% vs. 65.8% on WideSearch and 74.0% vs. 54.7% on WebArena-Verified: HybridSB matched the search-oriented average and exceeded the navigation-oriented average, but incurred substantially higher input-token usage and LLM cost.The comparison is against the respective search-oriented and navigation-oriented averages.Source: §3.2 · p. 4, Table 2 · p. 4
  • Adding filesystem access improves HybridSBF’s performance at lower cost on WideSearch, but performance declines on WebArena-Verified, where tasks require identifying and using page controls.Selective inspection can reveal relevant text without showing how to interact with the page, leaving agents to spend turns searching for controls.Source: §3.2 · p. 4, Figure 2 · p. 4

3.3 INSIGHTS FROM PRELIMINARY ANALYSIS

  • Figure 3 illustrates an interface in which agents retrieve webpages, selectively inspect cached objects, and execute associated actions through a unified request–response interface.The figure’s caption describes the high-level interaction rather than reporting an analysis outcome.Source: Figure 3 · p. 5

4 WEB$HELL

WEB$HELL unifies web access through a common schema, a compiler that turns webpages into operable representations, and a cache that supports selective, continued access. Its request–response interface handles information retrieval and browser actions while retaining prior page states.

4 WEB$HELL

  • WEB$HELL combines WebContract’s common rules, WebCompiler’s operable page compilation, and WebCache’s retention of compiled pages for selective access.Together, the components provide one access model for agents.Source: §4 · p. 5

4.1 INTERACTION LOOP

  • In the request–response loop, agents select operations such as retrieve, grep, or execute, and the interface performs them on the agents’ behalf.Retrieved pages are compiled into information and action objects, stored under page addresses, and returned in a consistent structure.Source: §4.1 · p. 5

4.2 WEBCONTRACT: STANDARDIZING WEB ACCESS

  • WebContract defines objects by address, value, and association, and organizes them into page structures with groups, local identifiers, and a table of contents.Associations provide context needed to interpret an object’s value, including references to other objects.Source: §4.2 · pp. 5–6

4.3 WEBCOMPILER: COMPILING AN OPERABLE OBSERVATION SPACE

  • WebCompiler applies deterministic HTML-derived rules to compile element content and properties, using nesting and references to preserve relations between objects.For example, a select menu becomes an action object whose options are associated with label context; compiled objects are organized into a page tree and registered in WebCache.Source: §4.3 · p. 6

4.4 WEBCACHE: PROVIDING PERSISTENT AND STATEFUL WEB ACCESS

  • WebCache prepares fetched pages for overview and selective revisiting, and retains earlier read-only states when actions change a live webpage.The action and updated page state are recorded, allowing agents to inspect earlier states as a task progresses.Source: §4.4 · p. 6

5 EXPERIMENTS

The experiments compare WEB$HELL with filesystem-based and browser-oriented baselines across web search, navigation, and deep research. The reported results show stronger task performance at lower cost, with advantages described for each task category.

5 EXPERIMENTS

  • The evaluation covers six benchmarks across web search, navigation, and deep research, comparing mainly with Fetch-then-Explore, CLI-Anything Browser, and HybridSBF.Experiments use gpt-5.6-luna with high reasoning effort; turn budgets are 100 for Web Search, 50 for Web Navigation, and 200 for Deep Research.Source: §5 · pp. 6–7

5.1 MAIN RESULTS

  • WEB$HELL achieves higher performance at lower cost; in Deep Research, CLI-Anything Browser uses 52.4 turns and HybridSBF 30.9, versus WEB$HELL's 17.6.Table 3 reports performance in its upper part and efficiency, including average turns, tokens, and cost per task, in its lower part.Source: Table 3 · p. 7, §5.1 · p. 8
  • On Web Search, WEB$HELL outperforms Fetch-then-Explore, the strongest baseline on both WideSearch and SealQA.The paper suggests that common object types and consistent access operations may help agents locate and revisit evidence across sources.Source: §5.1 · p. 7
  • On Web Navigation, WEB$HELL achieves the best performance on WebArena-Verified, while HybridSBF performs similarly to CLI-Anything Browser.The interface lists page controls and reports changes between page states after each action.Source: §5.1 · pp. 7–8
  • WEB$HELL’s clearest Deep Research improvement is on DeepWeb-Bench, which requires multi-source numerical evidence gathering and multi-step reasoning.The paper suggests object associations may guide further inspection when an evidence search does not find the needed information.Source: §5.1 · p. 8

6 ANALYSIS

The analyses examine how WEB$HELL gathers evidence, supports browser interaction, connects information to actions, and handles irrelevant pages. They report benefits from associated references and addressable access, alongside degradation when information and actions are separated.

6 ANALYSIS

  • WEB$HELL achieves the highest evidence coverage on both WideSearch and SealQA; Figure 5 compares evidence coverage and accuracy on those benchmarks.In a WideSearch case, WEB$HELL’s association field points from a league object to related season data omitted from Fetch-then-Explore’s clean text.Source: §6 · p. 8, Figure 5 · p. 8
  • In a news-archive task, WEB$HELL preserves a search control’s label and query parameter, while HybridSBF repeatedly selects “load more” and exhausts its turn budget.The self-contained action object lets WEB$HELL use the site search to reach the article.Source: §6 · pp. 8–9
  • Separating information from its associated actions consistently degrades performance and increases cost across the two web navigation benchmarks.The removed references otherwise let agents move from a result such as “Set status” directly to the relevant action.Source: §6 · p. 9, Figure 6 · p. 9
  • With 50 to 400 distractor pages, WEB$HELL maintains largely stable accuracy and inference costs, while Fetch-then-Explore’s cost more than doubles and HybridSBF’s rises steadily.WEB$HELL’s short reusable page addresses support selective access as irrelevant content accumulates.Source: §6 · p. 9, Figure 7 · p. 9

7 CONCLUSION

The conclusion presents WEB$HELL as a unified interface that standardizes webpage information and actions as addressable objects and preserves them for selective, stateful access. It reports strong performance and efficiency across web tasks, with analyses highlighting connected actions and persistent access.

7 CONCLUSION

  • Figure 8 examines the effect of the number of pages prefetched per search.Source: Figure 8 · p. 9
  • WEB$HELL standardizes webpage information and actions as addressable objects, compiles live pages into operable representations, and preserves them for selective, stateful access.The conclusion frames these properties as unified web access.Source: §7 · p. 9
  • Experiments demonstrate strong performance and efficiency across web search, web navigation, and deep research.Further analyses report benefits from connecting information with associated actions and maintaining persistent, addressable access as retrieved content accumulates.Source: §7 · p. 9
  • The authors report that AI-assisted manuscript text was reviewed and AI-generated experimental code was manually inspected and verified.Source: AI USE STATEMENT · p. 10

A.1 BENCHMARKS AND METRICS

The appendix describes six benchmarks spanning information gathering, web interaction, and evidence synthesis, then outlines baselines representing search, filesystem, browser, and hybrid access. It specifies the benchmark metrics and the defining capabilities of those baselines.

A.1 BENCHMARKS AND METRICS

  • Six benchmarks test information gathering across sources, website interaction, and evidence synthesis into reports and quantitative answers.Source: §A.1 · p. 14
  • WideSearch uses 100 English and 100 Chinese queries and reports item-level F1; SealQA evaluates 254 Seal-Hard questions using answer accuracy.Source: §A.1 · p. 14
  • WebArena-Verified evaluation covers 789 reproducible tasks and reports task success rate; WebWalkerQA reports answer accuracy on 420 remaining questions.The authors exclude 23 WebArena-Verified tasks that could not be reproduced and WebWalkerQA questions with inaccessible or updated reference pages lacking the gold evidence.Source: §A.1 · p. 14
  • DeepResearchBench has 100 report-writing tasks and uses RACE Overall; DeepWeb-Bench has 100 quantitative multi-source tasks and reports an overall rubric score.RACE Overall ranges from 0 to 1; the DeepWeb-Bench score ranges from 0 to 100.Source: §A.1 · p. 14

A.2 BASELINES

  • Search-augmented baselines range from direct fetched-text reading to passage reasoning in Search-o1 (Li et al., 2025a) and delegated exploration in WebThinker (Li et al., 2025b).Source: §A.2 · pp. 14–15
  • Filesystem and browser baselines include persistent cleaned-text workspaces, shell-based browsing over accessibility trees, and iterative structured observations with browser actions.Source: §A.2 · p. 15
  • HybridSB combines cleaned webpage text for information gathering with accessibility-tree observations for interaction; HybridSBF adds persistent files for selective shell inspection.Source: §A.2 · p. 15

A.3 EVALUATION SETTINGS

The evaluation uses consistent agent settings and benchmark-specific turn budgets. The preliminary analysis samples search and navigation tasks and defines metrics for per-call burden and evidence actually exposed to agents.

A.3 EVALUATION SETTINGS

  • All methods use the same main-agent model, reasoning effort, and category-specific turn budgets, with shared timeouts and safeguards against answer leakage.The budgets are 100 turns for Web Search, 50 for Web Navigation, and 200 for Deep Research.Source: §A.3 · p. 15

B.1 PRELIMINARY ANALYSIS

  • The preliminary analysis samples 100 WideSearch and 100 WebArena-Verified tasks, preserving search-oriented agents’ clean-text observations while adding browser actions.Accessibility-tree observations are treated as a separate extension examined through HybridSB in Analysis II.Source: §B.1 · p. 16
  • Per-call input tokens and inference cost include auxiliary model calls and are averaged across all calls to capture each method’s average inference burden.Cost is reported per 100 calls, scaled for readability.Source: §B.1 · p. 16

B.2 MAIN ANALYSIS

The analysis measures whether agents receive needed evidence and tests interface choices related to object-action references and selective access in noisy workspaces.

B.2 MAIN ANALYSIS

  • Evidence coverage measures how much gold information appears in tool responses exposed to the agent, counting retrieved content but not information merely stored in a workspace.WideSearch uses required reference-table cells and SealQA uses reference answers as its gold information.Source: §B.2 · p. 16
  • The action-reference ablation removes links between information and action objects while retaining both object types and WebCache, requiring a separate control listing for executable identifiers.The identifiers remain valid until the page changes or another listing is requested; the comparison uses 100 WebArena-Verified tasks and 100 WebWalkerQA questions.Source: §B.2 · p. 16
  • The noise analysis places 50, 100, 200, or 400 distractor pages in WebCache or filesystem workspaces and measures answer accuracy and inference cost on SealQA.The pages are available for inspection but are not inserted directly into context; CLI-Anything Browser is excluded because distractors would require additional browser tabs.Source: §B.2 · p. 16

C IMPLEMENTATION DETAILS

WebContract defines addressable information and action objects and shared request-response operations. WebCompiler preserves page structure and relationships as it compiles content, while WebCache retains pages and interaction states for later access.

C.1 WEBCONTRACT

  • Each WebContract object has an address, a value, and associations that preserve context or link related objects, with records tailored to text, tables, or actions.For example, a table cell retains row and column labels, while a selection action retains its purpose and inputs.Source: §C.1 · p. 17
  • Compiled pages include an address-bearing table of contents whose text sections reference related tables and actions, letting agents follow links from an overview or search match.The table of contents is stored in map.md.Source: §C.1 · p. 17
  • A WebContract request specifies an operation, arguments, and any needed page or object address; its response returns the outcome or requested content with addresses for subsequent requests.Operations include looking up a table cell and executing a selection action.Source: §C.1 · pp. 17–18, Table 6 · p. 18

C.2 WEBCOMPILER

  • WebCompiler traverses captured HTML in order, recursively constructs supported elements, preserves their relationships as associations, and writes indexed files without model inference.Elements without dedicated constructors contribute text and nested content to their containing section.Source: §C.2 · p. 18
  • For tables, WebCompiler associates cell values with row and column labels, including cells that span multiple rows or columns.Headings divide text into sections, while navigation, headers, and footers are stored separately when identified by the page.Source: §C.2 · p. 18
  • WebCompiler combines control declarations and ARIA annotations with inputs, current values, and constraints, and groups related form fields with their submission control as one action.A label linked to a selection menu connects its purpose to the action, while options supply displayed names and input values.Source: §C.2 · p. 18
  • WebCompiler also extracts embedded structured data and same-origin text responses, organizing them into facts or tables with source and related-record references.Values longer than 2,000 characters are stored separately with addresses and lengths so agents can retrieve ranges incrementally.Source: §C.2 · p. 18

C.3 WEBCACHE

  • WebCache retains pages obtained through search or direct opening, allowing agents to inspect compiled content without fetching again and to return to open tabs for interaction.Tabs share cookies and local storage, while each stored page state has its own address.Source: §C.3 · p. 19

D ADDITIONAL RESULTS AND ANALYSES

Additional analyses find that Web$hell performs consistently across domains, manages growing workspaces through short references and selective access, and retains evidence that has not yet reached the agent. It also reports compilation overhead and a cost comparison with Fetch-then-Explore.

Noise and selective access

  • Short addresses for pages and objects help Web$hell agents specify searches and reads as workspaces grow, while competing filesystem methods can incur path-tracking difficulty and full workspace listings.Fetch-then-Explore typically starts with a full listing, whereas HybridSBF often passes a fetched path directly to grep.Source: D ADDITIONAL RESULTS AND ANALYSES · pp. 19–20

Performance across domains

  • 63.5%–69.7% accuracy across four WebWalkerQA categories contrasts with Fetch-then-Explore’s 52.3% on Game, while Web$hell matches or exceeds HybridSBF across SealQA and WebWalkerQA categories.Web$hell also outperforms CLI-Anything Browser in each category.Source: Figure 9 · p. 19, D ADDITIONAL RESULTS AND ANALYSES · p. 19

Scaling and evidence retention

  • At k = 10, 9.5% of gold information in WebCache has not reached agent observations, while the fraction of cached pages inspected falls from 14.7% at k = 5 to 10.4% at k = 10.Retaining unaccessed content preserves the opportunity to retrieve it through later requests.Source: D ADDITIONAL RESULTS AND ANALYSES · p. 20

Compilation overhead

  • Compilation takes 0.46–2.79 seconds per page on average across benchmarks, measured directly because page-loading time depends on websites and rendering behavior.The reported measure is time to compile acquired content and store the resulting objects.Source: D ADDITIONAL RESULTS AND ANALYSES · p. 20, Table 7 · p. 20

Cost comparison with Fetch-then-Explore

  • WEB$HELL achieves higher performance than Fetch-then-Explore across Web Search and Deep Research with fewer model calls and comparable inference cost per task.On Web Search, cached input costs 10% of regular input under the evaluated pricing, keeping total inference cost comparable despite higher total token count.Source: D ADDITIONAL RESULTS AND ANALYSES · p. 20, Table 8 · p. 20

Related papers

Loading 2610.13416v1…