Nested Browser-Use Learning for Agentic Information Seeking

🎯 Pitch

Current search agents barely scratch the web’s surface—they fetch static pages but can’t type into a calculator or click “load more.” NestBrowse solves this with just four browser actions and a clever nested loop that keeps the agent focused, letting a 30B model beat systems 10x its size on the toughest deep-search benchmarks.

1. Executive Summary

This paper introduces Nested Browser-Use Learning (NestBrowse), a framework that equips information-seeking agents with a minimal browser toolkit—four actions: search, visit, click, and fill—and a nested interaction paradigm that decouples agentic reasoning (outer loop) from goal-driven page exploration (inner loop), enabling controlled injection of only goal-relevant content into the agent's limited context window. Training two models via multi-task imitation learning on the SailorFog-QA-V2 dataset, NestBrowse-4B and NestBrowse-30B-A3B achieve strong results across four challenging deep information-seeking benchmarks—BrowseComp, BrowseComp-zh, GAIA, and XBench—with the 30B-A3B variant reaching 31.6% on BrowseComp and 75.7% on GAIA, outperforming many open-source agents with substantially larger parameter counts and remaining competitive with proprietary systems. The nested design keeps outer-loop context within manageable limits even as total processed page content exceeds the model's 128K token maximum—without NestBrowse, execution would terminate after roughly 20 turns, though about 85% of tasks remain unfinished—establishing that principled browser-use abstraction, rather than model scale alone, critically determines information-seeking performance only when page-level information flow is structured through goal-conditioned extraction and a decoupled interaction loop.

2. Context and Motivation

The Core Problem: Information-Seeking Agents Can't Actually Use the Web

The fundamental gap this paper addresses is deceptively concrete: most information-seeking (IS) agents don't actually browse the web. Despite the proliferation of ReAct-style function-calling agents that interleave reasoning with tool invocation to gather evidence, the vast majority operate with only two tools: search (query a search engine for URLs, titles, and text snippets) and visit (fetch the markdown content of a given URL). This is the tool paradigm used by virtually every system listed in Table 1—WebSailor, WebDancer, WebExplorer, DeepDive, ASearcher-Web, and others all share these same two primitives.

The paper argues this abstraction is fundamentally incomplete. The web is not a collection of static documents accessible via a single page load. It is a dynamic, interactive medium where substantial information and functionality are exposed only through browser-level interactions:

Client-side rendering: JavaScript-rendered content that does not exist in raw HTML or markdown fetched by a static visit call.
Dynamic content loading: Infinite scroll, "load more" buttons, and paginated interfaces that progressively reveal content through interaction.
Form-mediated workflows: Search forms, calculator inputs (as in Figure 5's case study), filter interfaces, and any interaction requiring text entry followed by submission.
Multi-step navigation: Sequences of clicks through menus, tabs, or hierarchical page structures to reach deeply nested information.
Online functionalities embedded in pages: Computational utilities, data transformation tools, lookup services—interactive resources that function as tools themselves once activated through browser actions.

As the paper states in Section 1:

"Such content is neither reliably surfaced by search engines nor recoverable via a single static URL fetch, rendering IS formulations based solely on search and visit inherently incomplete."

This is not a hypothetical limitation. The benchmarks that the paper evaluates on—BrowseComp, GAIA, BrowseComp-zh, and XBench—are explicitly designed to require deep information seeking: finding hard-to-access facts that cannot be trivially retrieved through surface-level search queries. The tasks often demand navigating through interactive interfaces, submitting forms, clicking through page hierarchies, or using web-based computational utilities. An agent equipped only with search and visit simply cannot complete many of these tasks, because the answers lie behind browser-level gates that those tools cannot open.

Why This Problem Matters

The significance of this gap operates on multiple levels—practical, conceptual, and methodological.

Practical significance: the richness of the web is locked behind interactive barriers. The web is the most comprehensive repository of publicly accessible knowledge, and it is evolving toward increasingly dynamic, interactive experiences. Single-page applications, client-rendered dashboards, interactive data explorers, and embedded computational tools are not edge cases—they represent a substantial and growing fraction of the web's functional surface. IS agents that cannot interact with these interfaces are effectively restricted to a shrinking subset of available information. As the paper notes in Section 4.6, browser-use can be understood as meta tool-use: "the effective toolkit available to an agent encompasses the broad collection of tools implicitly embedded within the web itself." By limiting agents to static page fetching, existing systems are cutting themselves off from this extensible toolkit ecosystem.

Conceptual significance: scaling model size is not the only path to better IS performance. The paper's results make a compelling case for this claim. NestBrowse-4B, a model with only 4 billion parameters, achieves 68.9% on GAIA, 28.4% on BrowseComp-zh, and 74.0% on XBench-2505—numbers that exceed many larger open-source agents (e.g., DeepSeek-V3-based systems at hundreds of billions of parameters, Kimi-K2-Instruct at 1 trillion parameters) and even some proprietary systems. The paper explicitly states this insight in Section 4.2:

"Performance is not solely determined by model scale, but is critically influenced by how agents are designed to access, organize, and interact with external information sources."

This reframes the research agenda. Rather than pursuing ever-larger models to compensate for information access limitations, significant gains can be achieved by designing better interaction abstractions—and importantly, these gains are accessible to small, trainable models. This has direct implications for deployment cost, latency, and accessibility.

Methodological significance: there is no standard for modeling browser actions for text-only ReAct agents. The paper identifies a crucial gap in the tool design literature. While recent proprietary systems (OpenAI's DeepResearch, o3/o4-mini, Kimi Researcher, UI-TARS-2) have begun incorporating browser interactions, each uses a different action schema, different page content handling strategies, and different interaction paradigms. There is no widely adopted standard. The paper argues (Section 1):

"There is no widely adopted standard for modeling browser actions, and the inherent complexity of browser-use makes it challenging to abstract diverse interaction patterns into a tool interface suitable for IS agents."

This lack of standards creates two problems: (1) it makes comparison across systems difficult, and (2) it means each new system must solve the same interface design problems from scratch, without the benefit of established best practices about what abstractions work, what complexity level is appropriate, and how to handle the imposing practical challenge of injecting massive page content into bounded model contexts.

Where Existing Approaches Fall Short

The paper identifies three categories of prior work and explains why each is insufficient.

1. The search-and-visit paradigm (most open-source IS agents). Systems like WebSailor, WebDancer, WebExplorer, DeepDive, and ASearcher-Web model web interaction through two API-level tools: search and visit. This approach has proven effective for shallow information-seeking where the required information lives on static, well-indexed pages. However, it fundamentally cannot access dynamic information ( $I_{\text{dynamic}}$ in the paper's notation from Section 3.1)—content that requires client-side rendering, form interaction, or multi-step navigation to surface. The paper partitions web content explicitly:

$I_{\text{static}}$ : information accessible through a single page load without in-page interaction
$I_{\text{dynamic}}$ : information exposed only via browser-level interactions

The search-and-visit paradigm covers $I_{\text{static}}$ well but provides zero access to $I_{\text{dynamic}}$ . For deep IS benchmarks where answers are deliberately hidden behind interactive barriers, this is a hard ceiling on performance. The paper's case study (Figure 5) makes this concrete: solving a GAIA numerical computation task required an agent to navigate to an online calculator (planetcalc.com), fill input fields with the function and initial values, and click a calculate button—a workflow entirely impossible with search and visit alone.

2. Proprietary systems with browser-use, but inconsistent and undisclosed approaches. Several proprietary systems have incorporated browser interactions, as shown in Table 1: OpenAI-o3 achieves 49.7% on BrowseComp, OpenAI DeepResearch reaches 51.5%, and UI-TARS-2 reaches 29.6%. While these results demonstrate that browser-use provides substantial gains over search-and-visit systems (compare to the best open-source search-and-visit agent, WebSailor-V2 at 24.4% on BrowseComp), the underlying methods are not publicly available. The paper cannot learn from, replicate, or build upon these approaches because their tool schemas, page handling strategies, and interaction paradigms are proprietary. Moreover, the diversity of approaches across these systems—some using text-only browser output, others incorporating visual information—underscores the lack of standardization the paper identifies.

A particularly relevant contrast is with UI-TARS-2, which uses vision-based browser interaction (capturing screenshots and performing GUI actions). While this approach captures visual information that text-only systems miss, it introduces substantial complexity: visual grounding, multimodal reasoning, and the computational overhead of processing images. The paper makes an explicit design choice to remain text-only (Section 6), arguing that this isolates the effects of tool abstraction and interaction paradigm from the confounding factor of multimodal perception. The results suggest that even without vision, text-only browser interaction provides large gains over static fetching.

3. Naive browser-use implementations that ignore context management. The paper does not simply argue for adding browser actions—it argues that how browser outputs are integrated into the agent's context is equally critical. Raw browser pages are enormous. The paper notes in Section 3.2:

"A single page can easily exceed 64K tokens and may even surpass 1M tokens, rendering it infeasible for IS agents operating under typical context limits of 128K or 256K."

The standard workaround—truncating overlong pages—is acknowledged but rejected because it "inevitably risks discarding information." The deeper problem is subtler: even when a page fits within the context window, injecting all of its content wastes the agent's token budget on extraneous information. For a visited page with content $P$ , only a small subset $P_g \subset P$ is goal-relevant, while most content $P \setminus P_g$ is noise. Injecting full page content burdens subsequent reasoning steps with irrelevant information, making it harder for the model to identify and synthesize the evidence that actually matters.

This is where existing browser toolkits for web agents (e.g., those designed for GUI automation tasks in the Mind2Web or WebArena tradition) fall short for IS tasks specifically. They typically include many fine-grained actions (scroll, hover, keyboard navigation, in-page search) and return raw page snapshots that the agent must process. The paper explicitly excludes scrolling and in-page search from its toolkit, arguing (Section 3.2) that these actions "merely limit content exposure per page read without improving goal-directed information acquisition, resulting in inefficient browser-use for IS tasks." The design challenge is not just enabling browser interaction—it is enabling efficient browser interaction where the agent receives compact, relevant signals rather than raw dumps of page content.

How This Paper Positions Itself

The paper positions NestBrowse as a principled middle ground between the two extremes of existing work:

Too simple: search-and-visit paradigms that cannot access dynamic web content
Too complex: full browser toolkits with dozens of actions and raw page injection that overwhelm the agent's context and reasoning capacity

The paper's solution operates on three architectural decisions that together define its position:

Decision 1: A minimal but complete four-tool browser surface. Rather than exposing low-level browser primitives (scroll, hover, navigate history, page search), the paper argues that search, visit, click, and fill together form a functionally complete set for web information access. The reasoning (Section 3.1) is that click and fill cover the full spectrum of interactive behaviors: clicking activates page transitions, submits forms, and navigates menus; filling inputs data into forms, search boxes, and computational interfaces. Together, these four tools complete the information access pathway while introducing only two additional actions beyond the standard search-and-visit baseline. The paper explicitly invokes established tool-integrated reasoning principles—minimal toolkits reduce decision burden, avoid confusion during reasoning, and maintain efficient information flow (citing Shen et al., 2023; Qin et al., 2024; Deng et al., 2023; Liu et al., 2023)—to justify this minimalism.

Decision 2: Decoupling browser interaction into nested loops. This is the paper's central architectural innovation and its primary conceptual contribution. The insight is that agentic reasoning (what information do I need next? what tool should I call to get it?) and page exploration (where on this page is the information relevant to my goal?) are different cognitive tasks that benefit from separation. The outer loop handles the ReAct-style interleaving of reasoning and tool invocation—it decides to call search, visit, or click based on the evolving state of knowledge. The inner loop is instantiated only when a tool transitions the agent into a new page, and its sole responsibility is extracting goal-relevant content from that page and accumulating it in a temporary workspace.

This design solves the context management problem in a way that raw truncation cannot: the inner loop processes the full page content in segments, extracts only what is relevant to the current goal, and returns a compact workspace to the outer loop. The outer loop never sees the full raw page—only the extracted evidence, summaries, and rationales produced by the inner loop. As demonstrated in Figure 3, this means the outer-loop context stays within manageable limits even when total processed page content (the sum of all segments across all pages) far exceeds the agent's 128K token maximum.

Decision 3: Joint training of outer-loop and inner-loop capabilities via multi-task imitation learning. The paper does not treat inner-loop page extraction as a separate system or a heuristic post-processing step—it trains the agent model to perform both functions. The multi-task objective (Equation 8) jointly optimizes the outer-loop trajectory likelihood (reasoning, tool calls, tool responses) and the inner-loop evidence extraction likelihood (generating goal-relevant content for each page segment). This means the same model weights are used for both functions, and the training signal encourages the model to develop complementary capabilities: generating useful tool calls that bring it to informative pages, and extracting precisely the content from those pages that will enable subsequent reasoning.

The training data filter—rejection sampling on the SailorFog-QA-V2 dataset—is crucial here. By retaining only trajectories that (1) adhere to the required output format, (2) contain valid tool calls, and (3) lead to correct final answers, the paper biases supervision toward effective agentic behaviors without imposing brittle manually specified rules on intermediate reasoning steps. The paper explicitly notes (Section 3.3) that it does not apply additional rejection criteria to intermediate steps, which "preserves diversity in the supervision signal and avoids over-constraining agent behavior."

Positioning relative to the training-inference tradeoff literature. While not explicitly framed as such, this paper connects to the same theme as the prior summary's discussion of inference-time compute versus pretraining: how should limited resources be allocated? But here the resource is not FLOPs or model parameters—it is context window budget and tool interface complexity. The paper argues that investing in better interaction abstractions and smarter information flow management (the NestBrowse design) can substitute for model scale. NestBrowse-4B outperforms many larger models not because it is a better reasoner in isolation, but because the nested browser-use framework enables it to access more relevant information per token of context budget. This is a different axis of the "small models with good infrastructure versus large models with naive infrastructure" tradeoff, and the paper provides compelling empirical evidence that the infrastructure side of this equation has been undervalued.

Positioning relative to web agent literature. The paper explicitly distinguishes itself from web agent systems designed for GUI automation tasks (Mind2Web, WebArena, BrowserAgent). Those systems focus on action prediction given page observations—what element should be clicked next to achieve a specified task?—and typically assume a visual or structured DOM representation as input. NestBrowse focuses on a different problem: how should a text-only reasoning agent structure its interaction with the browser so that it can efficiently gather evidence for complex, multi-step information-seeking tasks? The nested loop design, the focus on goal-conditioned extraction, and the joint training of outer-loop and inner-loop capabilities are all motivated by the specific demands of IS reasoning rather than GUI task completion.

3. Technical Approach

3.1 Reader Orientation

The paper builds a browser-integrated information-seeking agent—a language model that can search the web, visit pages, click interactive elements, and fill form fields to gather evidence, extract only goal-relevant content from enormous web pages, and synthesize answers to complex questions that cannot be solved through static page retrieval alone. The core problem is that existing IS agents either cannot access dynamic web content (because they only have search and visit tools) or drown in raw page content that exceeds context limits and buries relevant information in noise; the solution is to decouple browser interaction into two loops—an outer loop for tool-use reasoning and an inner loop for goal-conditioned page extraction—and train both capabilities jointly so the outer loop receives compact, relevant evidence rather than raw page dumps.

3.2 Big-Picture Architecture (Diagram in Words)

The system consists of four major components connected in a nested structure:

Minimally Complete Browser Toolkit — a set of four tools (search, visit, click, fill) implemented via a headless browser backend in Playwright. These tools provide functionally complete access to both static and dynamic web content while keeping tool complexity low (only two actions beyond the standard search-and-visit baseline). Each page-transition tool (visit, click) takes an explicit goal parameter that guides downstream extraction.
Outer Loop (Agentic Reasoning) — a ReAct-style function-calling loop where the language model interleaves reasoning (in thinking tags) with tool invocations (in <tool_call> tags). At each step, the model decides which tool to call based on the accumulated context, executes it, receives the tool response, and appends it to context for the next reasoning step. This loop terminates when the model produces a final answer in <answer> tags or hits resource limits (100 tool calls maximum, 128K token context cap).
Inner Loop (Goal-Driven Page Exploration) — instantiated whenever the outer loop calls a tool that transitions into a new page (visit or click). The inner loop partitions the raw page content into segments, processes each segment against the goal passed from the outer loop, and incrementally maintains a temporary workspace (W) that accumulates only goal-relevant evidence. The loop terminates once all page segments are processed, at which point the final workspace is returned to the outer loop as the tool response.
Multi-Task Imitation Learning Pipeline — the training procedure that jointly optimizes the model for both outer-loop reasoning and inner-loop extraction. Trajectories are constructed by rolling out the agent, filtered via rejection sampling (format validity, tool-call correctness, final answer accuracy), and used to supervise both the next-token prediction in the outer loop and the evidence extraction prediction in the inner loop through a weighted multi-task loss.

Information flows as follows: a user query enters the outer loop → the model reasons and calls search to find relevant URLs → the model calls visit with a URL and a goal → an inner loop instantiates, segments the page, extracts goal-relevant content into a workspace, and returns it → the outer loop appends this compact evidence to context → the model reasons further and may call click or fill to interact with dynamic page elements → each page-transition action spawns a new inner loop → the process repeats until the model has gathered sufficient evidence and produces a final answer.

3.3 Roadmap for the Deep Dive

First, the minimally complete browser toolkit — what the four tools are, why this specific set was chosen, what browser backend implements them, and what is deliberately excluded (scrolling, in-page search) and why. This establishes the action space the agent operates in.
Second, the nested browser-use framework — the formal definition of the outer loop, the inner loop, the workspace update mechanism, and the interface between them. This is the core architectural innovation and must be understood in detail before the training procedure makes sense.
Third, the multi-task imitation learning formulation — how training data is constructed (SailorFog-QA-V2, rejection sampling with three criteria), how the outer-loop and inner-loop losses are defined, and how they are combined in the joint objective. This explains how the model internalizes both capabilities.
Fourth, the implementation details and hyperparameter choices — model architectures, context limits, tool invocation caps, training compute, and the specific prompt formats used for outer-loop reasoning and inner-loop extraction. These ground the abstract framework in concrete engineering choices.

3.4 Detailed, Sentence-Based Technical Breakdown

This is primarily a systems and methods paper whose core idea is that information-seeking agents should interact with browsers through a minimal action surface and a nested loop structure that separates agentic reasoning from page content extraction, and that both capabilities should be trained jointly in a single model.

Minimally Complete Browser Toolkit

The paper begins with a fundamental design tension: the web contains information accessible only through browser-level interaction, but exposing all possible browser actions creates an unmanageably large action space that burdens the IS agent's decision-making. The solution is to identify a minimal yet functionally complete set of tools that covers the full spectrum of web information access while keeping tool complexity within a "highly usable range."

Browser backend. The toolkit is implemented via a headless browser backend in Playwright—a browser automation library that can load pages, execute JavaScript, and programmatically interact with page elements. Importantly, the paper's setup "considers only textual page content and does not incorporate any visual information" (Section 3.1, footnote). This is a deliberate scoping choice to isolate the effects of tool abstraction and interaction paradigm from the confounding factor of multimodal perception. For each page, the system parses raw HTML into a semantic DOM snapshot that "exposes interactive-element identifiers for subsequent actions while presenting structured, LLM-readable content." This snapshot translates the visual and interactive structure of the page into text that the model can reason about, including identifiers for clickable elements, input fields, and other interactive components.

Information partitioning. The paper formally partitions web information into two categories:

Static information $I_{\text{static}}$ : content "accessible through a single page load without in-page interaction"—what you get by fetching a URL and reading the resulting HTML/markdown.
Dynamic information $I_{\text{dynamic}}$ : content "exposed only via browser-level interactions such as client-side rendering, incremental loading, or user-triggered actions"—content that requires JavaScript execution, button clicks, form submissions, or navigation through interactive interfaces.

Mainstream IS tool abstractions (search + visit) suffice for $I_{\text{static}}$ but provide "limited access to $I_{\text{dynamic}}$ ." The challenge is to add tooling for $I_{\text{dynamic}}$ without ballooning the action space.

The four tools. The paper proposes exactly four tools, described in Section 3.1:

search: Performs batched Google queries and returns the top-10 ranked results for each. This is the standard entry point—the agent formulates search queries, receives URL-title-snippet triples, and uses them to decide which pages to visit. Batched queries enable the agent to issue multiple searches in a single tool call, reducing turn count.
visit: Fetches a webpage from a URL and extracts information relevant to the given goal. This is the standard page-level retrieval tool, but with a crucial addition: it takes an explicit goal parameter that guides the extraction process. Unlike conventional visit tools that return raw page content, NestBrowse's visit invokes the inner loop to extract only goal-relevant content and returns a compact workspace.
click: Interacts with a clickable element (identified by a DOM element identifier from the semantic snapshot), potentially triggers a page transition (navigation to a new URL or dynamic content loading), and extracts content relevant to the given goal. Like visit, it takes a goal parameter and returns a workspace produced by the inner loop after the page transition completes.
fill: Types text into form fields or other editable elements within the current page. Unlike visit and click, fill does not inherently trigger a page transition—it modifies the state of the current page by entering text. It takes an element identifier and the text to input. The paper implies (though does not exhaustively describe) that fill can be followed by click to submit forms or trigger computations.

Justification for this set. The paper argues these four tools are functionally complete for web information access:

search + visit cover $I_{\text{static}}$ as in existing systems
click covers all interactive navigation and triggering—button presses, link following, tab switching, menu navigation, form submission
fill covers all text input scenarios—search boxes, form fields, calculator inputs, filter parameters

Together, click and fill "cover the full spectrum of dynamic information $I_{\text{dynamic}}$ " while introducing "only two additional actions" beyond the standard search-and-visit baseline. The paper explicitly invokes established principles from the tool-integrated reasoning literature to justify this minimalism (Section 2): toolkits should be "minimal and low in complexity to reduce decision burden, avoid confusion during reasoning, and maintain efficiency and smooth information flow between tool execution and subsequent reasoning" (citing Shen et al., 2023; Qin et al., 2024; Deng et al., 2023; Liu et al., 2023).

What is deliberately excluded. The paper specifically discusses two common browser actions that are not included in the toolkit:

Scrolling: The paper argues (Section 3.2) that scrolling "merely limits content exposure per page read without improving goal-directed information acquisition." The problem scrolling addresses—pages being too large to fit in context—is better solved by the inner loop's goal-conditioned extraction, which processes the full page in segments rather than simply truncating after a scroll boundary.
In-page search (Ctrl+F / find-on-page): Similarly excluded because it is a content-limiting mechanism rather than a relevance-filtering mechanism. The inner loop's extraction function does the work of identifying relevant content more effectively than keyword-based search within a page.

Both exclusions represent a design philosophy: rather than giving the agent low-level tools to manually manage information overload, the system handles information filtering structurally through the nested loop design. The agent does not need to scroll or search within pages because the inner loop automatically processes all content and returns only what matters.

Tool interface format. The paper serializes tool invocations in a structured format (described in Section 3.2 and detailed in Appendix A.1):

Free-form reasoning is enclosed within thinking and response tags
Tool invocations are wrapped in <tool_call> and </tool_call> tags, containing a JSON object with "name" and "arguments" fields
Tool responses (the workspace from the inner loop for page-transition tools, or standard search results for search) are encapsulated using <tool_response> and </tool_response>
The inner loop workspace is further delimited by <useful_info> and </useful_info> tags within the tool response

Nested Browser-Use Framework: The Outer Loop

The outer loop is a standard ReAct-style function-calling loop, but with a critical consequence: when it calls a page-transition tool, the response it receives is not raw page content but the output of an inner-loop extraction process. This decoupling is the core architectural innovation.

Formal definition of the outer loop. At each outer-loop step indexed by $t$ , the agent maintains a context $c_t$ —the accumulated history of reasoning, tool calls, and tool responses up to that point. The agent operates by sampling an action from its policy (Equation 1):

$(a_t, \eta_t) \sim p_\theta(\cdot \mid c_t), \quad a_t \in \mathcal{T}$

where $p_\theta$ is the parameterized IS agent model (the language model being trained), $a_t$ is the selected tool from the toolkit $\mathcal{T}$ (one of search, visit, click, fill), and $\eta_t$ includes the tool arguments (search queries, URLs, goals, element identifiers, text to fill).

What it computes: the outer loop is a conditional generation process. Given the entire conversation history $c_t$ (user query, all previous reasoning steps, all previous tool calls and responses), the model predicts the next action: which tool to call and with what arguments. The model generates this prediction token-by-token, including both the thinking reasoning content and the <tool_call> JSON.

Why this form: this is the standard ReAct formulation (Yao et al., 2023) adapted to the browser toolkit. The key departure from standard ReAct is that the tool execution function (Equation 5, discussed below) is not a simple API call—for page-transition tools, it invokes a nested extraction loop that processes the entire page before returning.

Context update. Executing the tool produces a response $r_t$ (Equation 2):

$r_t = \text{Exec}(a_t, \eta_t)$

The response is appended to context to form the next state (Equation 3):

$c_{t+1} = \text{Update}(c_t, a_t, \eta_t, r_t)$

What this means operationally: at each step, the model sees everything that has happened so far—the user's question, its own reasoning traces, every tool it called, every response it received—and must decide what to do next. The context grows monotonically as the episode proceeds, which is why the inner loop's compression is essential: if $r_t$ were raw page content, the context would explode.

Termination. The outer loop repeats until one of two conditions is met:

Task completion: the model produces a final answer enclosed in <answer>...</answer> tags, indicating it has gathered sufficient evidence and synthesized a response.
Resource exhaustion: the model hits predefined constraints—either the maximum context length of 128K tokens (set during training and inference for both the 4B and 30B-A3B models), or the maximum number of tool invocations capped at 100. If the agent fails to produce a final answer upon reaching either limit, "the episode is forcibly terminated" (Section 4.1).

The outer loop system prompt. Appendix A.1 provides the full system prompt used for outer-loop reasoning. Key elements include:

The model is instructed: "You are a browser-use agent. Your core function is to conduct thorough, multi-source investigations into any topic."
It must "synthesize information from credible, diverse sources to deliver a comprehensive, accurate, and objective response."
The final answer must be enclosed in <answer></answer> tags.
The available tools are provided within <tools>...</tools> XML tags using a JSON schema format.
Tool calls must be formatted as JSON objects within <tool_call>...</tool_call> tags.

The user prompt in the outer loop is simply the raw user query, "without any additional instructional or guiding content" (Appendix A.1).

Nested Browser-Use Framework: The Inner Loop

The inner loop is the paper's primary mechanism for solving the context management problem. It is instantiated whenever the outer loop calls a tool that "transitions the agent into a new page"—specifically visit and click. Its sole responsibility is to extract goal-relevant content from the page and return a compact workspace.

Why a separate inner loop? The paper argues that from a goal-driven perspective, the IS agent needs only a small subset of any page's content. For a visited page with content $P$ , let $g_t$ be the goal passed from the outer loop at step $t$ . Only $P_g \subset P$ is goal-relevant; the rest $P \setminus P_g$ is "extraneous" and "wastes token budget and impairs subsequent reasoning" (Section 3.2). The inner loop's function is to identify and extract $P_g$ while discarding $P \setminus P_g$ .

Page segmentation. The inner loop begins by partitioning the raw textual content of the visited page $P$ into a sequence of segments $\{P_i\}_{i=1}^N$ . The paper does not specify the exact segmentation strategy (by token count, by paragraph, by DOM structure), but the critical property is that each segment is small enough to be processed individually by the model in a single forward pass, while the union of all segments covers the entire page.

Workspace initialization and update. The inner loop maintains a temporary workspace $W$ , initialized as empty ( $W = \emptyset$ ). For each segment $P_i$ , the agent extracts goal-relevant content and updates the workspace (Equation 4):

$W \leftarrow W \cup f(P_i, g_t)$

where $f(P_i, g_t)$ is the extraction function applied to segment $P_i$ under goal $g_t$ .

What this computes: for each page segment, the model reads the raw segment content and the goal, identifies any information in the segment that is relevant to the goal, and adds that information to the workspace. Information from segments that is irrelevant to the goal is discarded. The workspace grows incrementally as successive segments are processed. By the end of the inner loop, $W$ contains all and only the goal-relevant content from the full page.

Why this form: the incremental union update avoids two failure modes. If the system tried to process the entire page at once, it would hit context limits for large pages. If it processed each segment independently and returned only the last, it would lose information from earlier segments. The incremental workspace preserves all relevant information across segments while discarding irrelevant noise at each step.

Extraction function $f$ in practice. The extraction function is implemented by prompting the model (the same model weights used for outer-loop reasoning) with a specialized inner-loop system prompt (Appendix A.1). For each segment, the model is instructed to:

"Content Scanning for Rational": locate the specific sections or data in the webpage content that are directly related to the user's goal
"Key Extraction for Evidence": identify and extract the most relevant information, preserving "the full original context of the content as far as possible, it can be more than three paragraphs"
"Summary Output for Summary": organize the extracted information into a concise paragraph with logical flow, prioritizing clarity and judging the contribution of the information to the goal

The output is a JSON object with three fields—"rational", "evidence", and "summary"—wrapped in <useful_info>...</useful_info> tags. This JSON object is what gets added to the workspace for each segment.

Incremental workspace maintenance. For segments after the first, the inner loop prompt is modified to include the existing workspace content (Appendix A.1, "User Prompt Incremental"). Specifically, the "evidence" and "summary" fields from the previous iteration's workspace are extracted and appended to the current prompt as "Existing Evidence" and "Existing Summary." The instruction tells the model:

"You must build upon and integrate these existing pieces of information to perform incremental processing. Produce a consolidated final result that incorporates both the provided and newly added information, without indicating which parts are new or incremental."

This design ensures that the workspace is not merely a concatenation of independent extractions but a progressively consolidated summary that avoids redundancy while capturing all relevant content.

Inner loop termination and output. The inner loop terminates once all $N$ segments of the page have been processed. At termination, the final workspace is denoted $W^\star(g_t, P)$ —the complete set of goal-relevant content extracted from page $P$ under goal $g_t$ . This workspace is returned to the outer loop as the tool response $r_t$ .

Nested Browser-Use Framework: The Outer-Inner Interface

The interface between the two loops is formalized through the tool execution function (Equation 5):

$\text{Exec}(a_t, \eta_t) = \begin{cases} W^\star(g_t, P), & \text{if } a_t \in \mathcal{T}_{\text{page}}, \\ \text{Exec}_{\text{base}}(a_t, \eta_t), & \text{otherwise} \end{cases}$

where $\mathcal{T}_{\text{page}}$ is the subset of tools that induce page transitions (specifically visit and click), $W^\star(g_t, P)$ is the inner loop's final workspace for the visited page $P$ under goal $g_t$ , and $\text{Exec}_{\text{base}}$ is standard execution for tools that do not induce page transitions (specifically search, which returns top-10 ranked results, and fill, which modifies page state without returning a new workspace).

What this decision boundary means operationally:

When visit or click is called: the outer loop passes the URL (for visit) or element identifier (for click) and the goal $g_t$ to the inner loop. The inner loop takes control: it loads the resulting page, segments it, processes each segment, builds the workspace, and returns $W^\star$ . The outer loop receives this concise, goal-aligned response—not the raw page content. This is the mechanism by which NestBrowse controls information flow into the agent's context.
When search is called: standard execution returns the top-10 results for each query (URL, title, snippet). No inner loop is needed because search engine results pages are compact and the goal at this stage is discovery (finding which URLs to visit), not deep content extraction.
When fill is called: the tool types text into a specified element on the current page. The paper does not explicitly describe whether fill returns a workspace or a simple acknowledgment, but given that fill does not trigger a page transition, it likely returns a status message. The subsequent click (e.g., clicking a submit button) would then trigger a new page load and a new inner loop.

Why this interface design matters for context efficiency. The outer loop never sees raw page content for any page. Even for pages that are hundreds of thousands of tokens in raw form, the workspace returned to the outer loop contains only the extracted evidence and summaries. This is what enables Figure 3's central result: "After approximately 20 tool-call turns, the total processed information already exceeds the agent's maximum context limit (128K tokens). Without NestBrowse, execution would terminate at this point, even though about 85% of tasks remain unfinished." The nested design keeps the outer-loop context within feasible limits "throughout execution, substantially improving the practicality and effectiveness of browser-based information seeking."

The nested metaphor. The framework is called "nested" because the inner loop is fully contained within the execution of specific outer-loop tool calls. From the outer loop's perspective, calling visit is a single step—it issues the tool call, waits for the response, and continues reasoning. But internally, that single step spawns a multi-step process (segment → extract → update → repeat for all segments) that may involve numerous forward passes through the model. The outer loop's reasoning context is isolated from this internal complexity; it sees only the final product (the workspace).

Multi-Task Imitation Learning: Task and Supervision

The paper trains NestBrowse models using multi-task imitation learning—supervised fine-tuning where the model learns to predict both outer-loop agentic behavior (reasoning, tool calls, final answers) and inner-loop extraction behavior (goal-conditioned page content processing) from demonstration trajectories.

Training task: SailorFog-QA-V2. The paper adopts SailorFog-QA-V2 (Li et al., 2025b) as its primary training data source. This is a "high-quality QA set designed to elicit complex browsing behaviors that require both effective tool use and multi-step reasoning from IS agents." The choice is motivated by a negative claim about simpler datasets: "Simple single-hop or multi-hop QA training sets (Yang et al., 2018; Ho et al., 2020; Hendrycks et al., 2021) are insufficient for this purpose, as they can often be solved with only one or a few search queries, without requiring substantive browsing or reasoning" (Section 3.3). In other words, easy QA datasets would not force the model to learn the complex browser-use behaviors that NestBrowse is designed to support—the training tasks must themselves require dynamic web interaction, form filling, multi-step navigation, or similar challenges for the resulting trajectories to contain meaningful browser-use supervision.

Trajectory construction. Training trajectories are constructed by rolling out the agent on SailorFog-QA-V2 questions, following the nested browser-use procedure described in Section 3.2. The model interleaves reasoning with tool calls, inner loops process pages, and the full outer-loop sequence—including all reasoning, tool calls, tool responses, and final answers—is recorded as a trajectory. The inner-loop extraction steps (processing each page segment) are also recorded as separate supervision instances.

Rejection sampling with three criteria. Because "interleaving reasoning with browser interaction constitutes a challenging agentic capability, and model rollouts do not always exhibit the desired behavior," the paper applies rejection sampling to filter trajectories. Only trajectories that satisfy all three of the following criteria are retained for training:

Format violations: "Trajectories that do not adhere to the required output format are discarded, such as failing to enclose reasoning content within thinking and response tags." This ensures the training data respects the serialization format that the model must learn to produce.
Tool-call hallucinations: "We reject trajectories that contain invalid tool names or tool arguments that cannot be correctly executed." A hallucinated tool name (e.g., navigate instead of visit) or an invalid argument (e.g., a non-existent element identifier) would teach the model to produce unexecutable actions, so such trajectories are filtered.
Incorrect final answers: "We assume that only trajectories leading to a correct final answer provide meaningful supervision for learning agentic browsing and reasoning behaviors, and thus discard trajectories with incorrect outcomes." This is a critical quality filter: trajectories where the agent failed to solve the task cannot demonstrate effective strategies, and training on them would reinforce failure patterns.

What is NOT filtered. The paper explicitly states: "Notably, we do not apply additional rejection criteria to intermediate reasoning or browsing steps. This choice preserves diversity in the supervision signal and avoids over-constraining agent behavior with brittle, manually specified rules." This is a deliberate design choice. If the paper filtered based on whether the agent took efficient paths or followed prescribed strategies, it would restrict the diversity of behaviors the model could learn. By filtering only on format validity, tool executability, and final correctness, the paper allows the model to learn from a variety of successful trajectories, even those that took circuitous routes or explored dead ends before finding the answer.

Multi-Task Imitation Learning: Outer-Loop Objective

The outer-loop objective trains the model to produce the correct sequence of tokens for each step of the agent trajectory—reasoning, tool calls, and final answers.

Token-level negative log-likelihood (Equation 6):

$\mathcal{L}_{\text{out}}(\theta) = \mathbb{E}\left[ \sum_t \sum_j -\log p_\theta\left(y_{t,j} \mid c_t, y_{t,<j}\right) \right]$

where $p_\theta$ is the parameterized IS agent model, $c_t$ is the context at outer-loop step $t$ (all previous reasoning, tool calls, and responses), $y_{t,j}$ is the $j$ -th token in the target serialized output at step $t$ , and $y_{t,<j}$ denotes all tokens in the current step's output that precede position $j$ .

What it computes: for each outer-loop step in each accepted trajectory, the model is trained to predict the next token in the target output sequence given the current context and all previously generated tokens for that step. The target output includes the full thinking reasoning block, the <tool_call> JSON, and (for the final step) the <answer> block. The double sum runs over all steps in the trajectory (indexed by $t$ ) and all token positions within each step's output (indexed by $j$ ). The expectation is over the distribution of accepted trajectories in the training set.

Why this form: this is the standard causal language modeling objective (next-token prediction with a cross-entropy loss), applied to the structured agent output format. The model learns to generate reasoning tokens, tool-call JSON, and answer tokens in the correct format because the training data contains exactly these sequences. The autoregressive formulation ( $y_{t,j}$ conditioned on $c_t$ and $y_{t,<j}$ ) means the model learns to produce coherent, format-compliant outputs step by step.

What the context $c_t$ contains. At each step, the model sees the entire conversation history up to that point, serialized as:

The system prompt (defining the agent's role and the tool schemas)
The user query
All previous reasoning blocks ( thinking tags)
All previous tool calls (<tool_call> tags with JSON content)
All previous tool responses (<tool_response> tags, containing <useful_info> workspaces for page-transition tools)

This means the model learns to condition its next action on the evolving state of knowledge—what has been searched for, what pages have been visited, what evidence has been extracted, and what gaps remain.

Multi-Task Imitation Learning: Inner-Loop Objective

The inner-loop objective trains the model to extract goal-relevant evidence from page segments and write it into the workspace in the required JSON format.

Segment-level extraction objective (Equation 7):

$\mathcal{L}_{\text{in}}(\theta) = \mathbb{E}\left[ \sum_{t,i} \sum_j -\log p_\theta\left(u_{t,i,j} \mid h_{t,i,j}\right) \right]$

where $u_{t,i,j}$ is the $j$ -th token of the extracted goal-relevant content for page segment $P_i$ at outer-loop step $t$ , and $h_{t,i,j}$ is the context consisting of the goal $g_t$ (passed from the outer loop), the page segment $P_i$ , and previously generated tokens $u_{t,i,<j}$ for this segment.

What it computes: for each page segment processed during the inner loop, the model is trained to predict the next token in the extraction output. The extraction output is the JSON object with "rational", "evidence", and "summary" fields, wrapped in <useful_info> tags. The triple sum runs over outer-loop steps $t$ (each page visit generates inner-loop data), page segments $i$ within the visited page, and token positions $j$ within the extraction output for each segment.

Why this form: this objective teaches the model to perform goal-conditioned information extraction. The context $h_{t,i,j}$ includes the goal (so the model learns to identify what is relevant), the page segment (so the model learns to locate information within raw web content), and previously generated tokens (so the model learns to produce coherent JSON output). For incremental segments, the context also includes existing evidence and summary from the workspace (Appendix A.1, incremental user prompt), teaching the model to build upon prior extractions rather than duplicating them.

Relationship to outer-loop objective. The inner-loop objective uses the same model parameters $\theta$ (the same language model) but conditions on different context and produces different outputs. The model must learn both modes: agentic reasoning with tool calls (outer-loop objective) and focused page extraction (inner-loop objective). The two objectives are complementary—better page extraction provides better evidence for reasoning, and better reasoning leads to better goals and tool calls that bring the agent to informative pages.

Multi-Task Imitation Learning: Joint Objective

The two objectives are combined into a weighted multi-task loss (Equation 8):

$\mathcal{L}_{\text{MT}}(\theta) = \lambda_{\text{out}} \mathcal{L}_{\text{out}}(\theta) + \lambda_{\text{in}} \mathcal{L}_{\text{in}}(\theta)$

where $\lambda_{\text{out}}$ and $\lambda_{\text{in}}$ balance the contribution of outer-loop and inner-loop supervision. The paper states: "By default, we use equal weighting with $\lambda_{\text{out}} = \lambda_{\text{in}} = 1$ ."

What it computes: the total training loss is simply the sum of the outer-loop and inner-loop next-token prediction losses, with equal weight. The model sees batches composed of both outer-loop trajectory steps and inner-loop extraction steps, and gradients from both contribute equally to parameter updates.

Why equal weighting: the paper does not provide an explicit justification for equal weighting beyond stating it as the default. However, the choice reflects a design philosophy: neither capability is treated as auxiliary to the other. The outer loop cannot function without clean inner-loop extraction (the context would overflow), and the inner loop has no purpose without the outer loop's goal-directed reasoning. Equal weighting ensures that neither objective dominates training, and the model develops both capabilities in parallel.

What "multi-task" means in practice. During training, the model sees interleaved examples from both tasks. An outer-loop training instance might show: given the conversation history so far, predict the next thinking and <tool_call> output. An inner-loop training instance might show: given a page segment and a goal, predict the <useful_info> JSON extraction. The same model weights process both types of instances, and through gradient descent, the model develops representations that support both functions.

Training compute. The paper reports (Section 4.1) that the 4B model was trained for "approximately 1,344 GPU hours" and the 30B-A3B model for "approximately 4,096 GPU hours on an NVIDIA H20 GPU cluster." The base models are Qwen3-4B-Thinking-2507 and Qwen3-30B-A3B-Thinking-2507 (Yang et al., 2025)—models from the Qwen3 family that already have thinking/reasoning capabilities, which the NestBrowse training extends with browser-use and information-seeking skills.

Why starting from Qwen3-Thinking models: the paper does not explicitly justify this choice, but it aligns with the multi-task training design. The Qwen3-Thinking models are pre-trained for extended reasoning chains (enclosed in thinking tags), which maps directly onto the outer loop's reasoning format. Starting from these models means the NestBrowse training does not need to teach basic reasoning capabilities from scratch—it builds browser-use and evidence-synthesis skills on top of existing reasoning competence.

Browser Backend and Page Processing Pipeline

While the paper focuses on the learning framework, several implementation details about the browser backend and page processing pipeline are specified in Section 3.1 and the surrounding discussion.

Playwright headless browser. The browser backend uses Playwright, a Node.js library for browser automation that supports Chromium, Firefox, and WebKit. "Headless" means the browser runs without a visible graphical interface—it loads pages, executes JavaScript, and renders content programmatically, returning the resulting HTML to the system.

HTML-to-DOM-snapshot conversion. When a page is loaded, the raw HTML is parsed into a "semantic DOM snapshot" that serves two purposes:

Interactive element identification: the snapshot "exposes interactive-element identifiers" (likely CSS selectors, XPaths, or aria-labels) that the click and fill tools use to target specific elements. For example, to click a "Calculate" button, the agent must specify an element identifier like [ref=e105] (visible in Figure 5's case study).
Structured, LLM-readable content: the snapshot "presents structured, LLM-readable content" rather than raw tag soup. This likely involves stripping non-semantic markup, organizing text hierarchically, and preserving the logical structure of the page while removing purely presentational HTML.

Text-only constraint. A critical design constraint: "our setup considers only textual page content and does not incorporate any visual information" (Section 3.1, footnote). This means:

Images, videos, and other visual media are not processed
Visual layout information (positioning, styling, visual hierarchy) is not captured
The DOM snapshot must represent all page semantics through text alone
Interactive elements are identified by textual identifiers (e.g., button labels, aria attributes) rather than visual coordinates

This constraint is maintained throughout both training and evaluation. When comparing to baselines in Table 1, the paper distinguishes systems that use "browser (text)" (text-only browser output, like NestBrowse) from those that use full "browser" access (including visual information, like OpenAI-o3 and OpenAI DeepResearch).

Goal as explicit parameter. The paper emphasizes that browser tools that introduce new pages ( $\mathcal{T}_{\text{page}}$ , i.e., visit and click) "explicitly take the goal as an input parameter" (Section 3.2, footnote). This is not merely a documentation detail—it is the mechanism by which the outer loop communicates its current information need to the inner loop. Without this goal parameter, the inner loop would have no way to determine which subset of page content is relevant. The goal is not a fixed string but evolves across outer-loop steps: early steps may have broad exploratory goals ("find information about company X"), while later steps have specific verification goals ("check whether company X was founded in 2019").

Page segmentation strategy. The paper states that the inner loop partitions page content $P$ "into a sequence of segments $\{P_i\}_{i=1}^N$ " and explores them "incrementally" (Section 3.2). However, the specific segmentation algorithm is not described—the paper does not specify whether segmentation is by token count (e.g., 4K-token chunks), by DOM structure (e.g., section-level splitting), or by some other criterion. This is a notable gap: the segmentation strategy directly affects the inner loop's effectiveness (too small = lost context across segment boundaries; too large = extraction quality degradation due to context dilution), but the paper provides no ablation or specification.

Training Data Pipeline: From SailorFog-QA-V2 to Accepted Trajectories

The full data pipeline, reconstructed from Section 3.3 and Section 4.1:

Step 1: Trajectory generation. For each question in SailorFog-QA-V2, the agent model (initially the base Qwen3-Thinking model, possibly iteratively updated) is rolled out following the nested browser-use procedure. The rollout produces a complete trajectory including:

All outer-loop reasoning steps ( thinking blocks)
All tool calls (with arguments)
All inner-loop extraction instances (for each page segment on each visited/clicked page)
The final answer (if one is produced before resource limits are hit)

Step 2: Rejection filtering. Each trajectory is checked against the three rejection criteria:

Format check: does the trajectory consistently use thinking, response, <tool_call>, and <answer> tags correctly?
Tool validity check: are all tool names in the toolkit? Are all arguments valid and executable?
Correctness check: does the final answer match the ground-truth answer for the SailorFog-QA-V2 question?

Trajectories that fail any of these checks are discarded. Trajectories that pass all three are added to the training set. The paper does not report the rejection rate, but given the challenge of interleaving reasoning with browser interaction, it may be substantial.

Step 3: Trajectory decomposition for multi-task training. Each accepted trajectory is decomposed into training instances:

Outer-loop instances: for each step $t$ in the trajectory, an instance is created with context $c_t$ (all history up to step $t$ ) and target $y_t$ (the reasoning, tool call, and tool response for step $t$ ). The final step's target includes the <answer> block.
Inner-loop instances: for each page segment processed during each inner loop, an instance is created with context $h_{t,i}$ (goal, page segment, and optionally existing workspace content for incremental segments) and target $u_{t,i}$ (the extraction output for that segment).

Both types of instances are mixed into the training batches, with equal loss weighting.

Why rejection sampling rather than RL or other methods: the paper argues that imitation learning with rejection sampling is appropriate because "only trajectories leading to a correct final answer provide meaningful supervision." This is a strong assumption—it implies that incorrect trajectories contain no useful signal about what the agent should do differently. The alternative would be reinforcement learning (RL), where the agent receives a reward signal for correct answers and learns from both successes and failures. The paper's choice of imitation learning with correctness-based filtering is simpler and more stable (no credit assignment across long trajectories) but discards potentially informative failure modes that RL could exploit. This tradeoff is not discussed explicitly.

Key Design Choices and Their Justifications

Choice 1: Four tools only, excluding scrolling and in-page search. Justification: established tool-integrated reasoning principles say minimal toolkits reduce decision burden. More specifically, the paper argues that scrolling and in-page search are "content-limiting" mechanisms that "merely limit content exposure per page read without improving goal-directed information acquisition." The nested loop's extraction mechanism handles the filtering that scrolling/in-page search would otherwise require the agent to do manually. This choice shifts the responsibility for information filtering from the agent's explicit actions to the system's structural design.

Choice 2: Nested loop decoupling rather than flat integration. Justification: raw page content is often too large for context limits and too noisy for effective reasoning. The alternative—injecting full page content into the outer loop and relying on truncation—"inevitably risks discarding information." The nested design ensures the outer loop sees only goal-relevant content without risking truncation of important evidence hidden in later parts of the page.

Choice 3: Joint training rather than separate extraction module. Justification: the paper's ablation in Table 3 shows that inner-loop quality directly affects outer-loop performance—"weaker inner-loop models degrade outer-loop performance, while stronger ones yield corresponding improvements." Training both loops jointly under a unified objective ensures the model develops coherent capabilities across both functions, rather than having a reasoning module that struggles to use evidence from an incompatible extraction module.

Choice 4: Rejection sampling with only final-answer filtering, not intermediate-step filtering. Justification: the paper explicitly states this "preserves diversity in the supervision signal and avoids over-constraining agent behavior with brittle, manually specified rules." If the paper filtered for efficient trajectories, the model might learn to follow narrow, prescribed strategies that don't generalize to novel tasks. Correctness-based filtering allows the model to learn from diverse successful strategies.

Choice 5: Text-only browser content, no visual information. Justification (from Section 6): this is "motivated by the need to isolate the effects of tool abstraction and interaction paradigms, and to maintain a controlled and interpretable experimental setting." Adding vision would introduce substantial complexity (multimodal perception, visual grounding) that would confound the paper's core claims about the nested loop design. The strong results with text-only access suggest that visual information, while valuable, is not necessary for substantial improvements over static page fetching.

Choice 6: Equal loss weighting for outer and inner loops. Justification: the paper does not provide an explicit justification, but the choice reflects a view that neither capability is auxiliary—both are essential for the system to function. If one loss dominated, the model might optimize for one capability at the expense of the other, breaking the nested design.

4. Key Insights and Innovations

Innovation 1: Browser-Use as a Meta-Tool Paradigm — the Web Itself Becomes the Agent's Extensible Toolkit

The paper's most conceptually distinctive move is reframing browser interaction not as a mechanism for reading pages, but as a meta-tool interface through which an IS agent gains access to the entire functional ecosystem of the web. This is articulated most explicitly in Section 4.6:

"browser-use can be viewed as a form of meta tool-use, where the effective toolkit available to an agent encompasses the broad collection of tools implicitly embedded within the web itself."

This is fundamentally different from how the field has conceptualized browser interaction for agents. Prior work on web agents (Mind2Web, WebArena, BrowserAgent) frames browser actions as navigation primitives — the agent clicks, scrolls, and types to move through pages toward a specified goal, much like a human would operate a browser. The dominant assumption is that the browser is a medium for reaching information. NestBrowse's framing is different: the browser is a medium for activating functionality. The online calculator in Figure 5 is not information to be retrieved — it is a computational tool that the agent uses to solve a problem. The form interface on a search page is not an obstacle to navigate past — it is a query interface that transforms the agent's information need into structured results.

This reframing matters because it changes the design criteria for browser toolkits. If the browser is for navigation, you need many actions: scroll to see more, in-page search to find elements, hover to reveal tooltips, keyboard shortcuts for efficiency. If the browser is for meta-tool use, you need only the actions that enable functional interaction: navigate to the tool (visit), activate it (click), and provide input (fill). This explains why the paper can claim functional completeness with only four tools — the toolkit is designed for the meta-tool paradigm, not the navigation paradigm. Scrolling and in-page search are excluded precisely because they serve navigation, not tool activation.

This is a fundamental conceptual shift, not an incremental refinement. The evidence that supports it is partly the strong performance results (NestBrowse-4B at 68.9% on GAIA exceeds most larger open-source agents), but more specifically the case study in Figure 5, which demonstrates exactly the meta-tool pattern: the agent searches for a calculator, visits it, fills input fields, clicks a button, and receives a computed result — a workflow that is impossible under the navigation paradigm alone and unnatural under the information-retrieval paradigm that dominates IS agent design.

Innovation 2: Decoupling Agentic Reasoning from Page Exploration as a Structural, Not Heuristic, Solution to Context Management

Prior work handles the context-overflow problem — the fact that web pages routinely exceed language model context windows — through heuristic workarounds: truncate pages at a fixed token limit (common in search-and-visit agents), scroll and read incrementally (in browser agents), or summarize pages post-hoc with a separate model. The paper identifies why these are inadequate: truncation can discard critical information, scrolling "merely limits content exposure per page read without improving goal-directed information acquisition" (Section 3.2), and post-hoc summarization decouples extraction from the reasoning process that determines what is relevant.

NestBrowse's innovation is to structuralize the solution: rather than treating context management as a post-generation compression problem, it embeds the separation of reasoning and extraction into the system architecture through the nested loop design. The outer loop never sees raw page content — it only ever receives the workspace W produced by the inner loop. This is not a heuristic filter; it is a boundary enforced by the tool execution function (Equation 5).

What makes this a conceptual contribution rather than just an engineering choice is the goal-driven nature of the boundary. The inner loop does not summarize pages generically — it extracts content conditionally, driven by the evolving goal g_t passed from the outer loop at each step. The same page visited under different goals would return different workspaces. The decoupling is not merely about reducing token counts; it is about aligning the information that enters the agent's reasoning context with the agent's current information need, while ensuring that no information is structurally excluded (the inner loop processes all page segments, just filters at the output boundary).

The evidence for why this matters is Figure 3: total processed information exceeds the model's 128K context limit after roughly 20 tool-call turns, but the outer-loop context remains manageable because only extracted workspaces are injected. Without NestBrowse, "execution would terminate at this point, even though about 85% of tasks remain unfinished." This is a diagnostic result — it shows that the structural boundary enables task completion that would be impossible under any heuristic truncation strategy, because truncation would either discard information (losing evidence needed for the remaining 85% of tasks) or exceed context limits (terminating early).

This contribution is conceptually fundamental in that it establishes a design principle — decouple reasoning from perception, and use goal-conditioned filtering at the boundary — that generalizes beyond browser-use to any setting where agents interact with large, noisy information sources. It is not an incremental engineering optimization; it is a different way of structuring the agent-environment interface.

A natural default for building a system like NestBrowse would be to modularize: use a strong reasoning model for the outer loop and a separate, possibly smaller and cheaper, model (or a rule-based system, or a dedicated extractive QA model) for the inner loop. This would be easier to implement, would allow independent optimization of each component, and would let the outer-loop model focus exclusively on reasoning. The paper explicitly tests this assumption in Table 3.

The result is a negative finding with positive implications for architecture design: using a weaker inner-loop model (NestBrowse-4B paired with NestBrowse-30B-A3B) degrades outer-loop performance (24.0% vs. 35.0% on BrowseComp), while using a stronger inner-loop model (GPT-OSS-120B) provides corresponding improvements (36.0%). The paper states: "This finding underscores intra-page exploration as a critical component of information acquisition in IS tasks and provides empirical justification for jointly training the outer and inner loops under a unified multi-task objective."

What makes this an innovation is the rejection of the modularity assumption. The dominant engineering intuition in agent systems is that perception (reading pages, extracting content) and reasoning (deciding what to do next) are separable concerns that can be optimized independently. The Table 3 results suggest they are interdependent in a way that matters for performance: the quality of evidence extraction directly constrains the quality of subsequent reasoning, and training both capabilities in the same model (under a joint objective with equal loss weighting) yields better results than training them separately and composing them.

This finding is incremental in nature (it confirms a hypothesis through an ablation rather than introducing a new principle) but practically significant because it challenges a common engineering instinct. If the modularity assumption held, the field could build IS agents by composing off-the-shelf reasoning models with off-the-shelf extraction models. The fact that joint training outperforms modular composition means that NestBrowse is not just a system architecture — it is a training methodology that produces a qualitatively different kind of model, one that has internalized the interaction between exploration and reasoning rather than treating them as independent modules connected by an API.

Innovation 4: The Diagnostic Concept of "Functional Completeness" for Browser Toolkits — Why Four Actions Suffice

The paper introduces a specific design concept that the field has lacked: functional completeness for web information access. This is the claim that the four-tool set {search, visit, click, fill} is sufficient to access all web content, both static and dynamic, without requiring any additional browser primitives.

This is not a theoretical claim in the formal sense (like Turing completeness), but a design argument grounded in a specific partition of web content into I_static and I_dynamic. The claim is:

search + visit cover I_static (as established by the entire search-and-visit IS agent literature)
click covers all interactive navigation and state transitions that expose I_dynamic (page transitions, dynamic content loading, form submission)
fill covers all text input scenarios required to interact with I_dynamic (form fields, search boxes, computational inputs)

Prior work on browser toolkits has lacked any principled basis for determining which actions to include. Web agent systems (Deng et al., 2023; Yu et al., 2025) typically include many actions — scroll, hover, keyboard shortcuts, tab management, history navigation — based on what a human would use, without a criterion for what is necessary. The field has operated under the implicit assumption that realistic browser interaction requires realistic browser action granularity.

The paper's innovation is to provide a criterion for action inclusion: does the action enable access to a category of web content that is not otherwise reachable? Scrolling does not — it limits how much content the agent sees at once but does not unlock new content. In-page search does not — it filters visible content but does not surface hidden content. click and fill do — they activate interactive elements that expose I_dynamic content not accessible through static page loading. This criterion explains not only what is included but what is excluded, and it justifies the "minimal" in "minimally complete."

The practical significance is demonstrated in the ablation study (Table 2): the Simplified setting (four-action toolkit without goal-conditioned extraction) improves GAIA performance from 46.6% to 55.3% over the Naive setting (standard browser toolkit). This shows that action-space simplification alone provides measurable benefits, independent of the nested loop design. The concept of functional completeness thus provides a framework that other agent designers can use to evaluate their own toolkits: for any proposed action, ask whether it unlocks a category of information access that existing actions cannot reach. If not, it adds complexity without adding capability.

This is a methodological innovation — it provides a vocabulary and a decision procedure for a design problem that previously relied on intuition and imitation of human browser behavior.

5. Experimental Analysis

Evaluation Methodology

Dataset. NestBrowse is evaluated on four deep information-seeking benchmarks: BrowseComp (Wei et al., 2025), an English benchmark with 1,266 questions requiring complex browsing to find hard-to-access web information; GAIA (Mialon et al., 2023), from which the paper uses the 103-question text-only subset following Li et al. (2025d); BrowseComp-zh (Zhou et al., 2025), a Chinese adaptation of BrowseComp with analogous deep search difficulty; and XBench-DeepSearch (XBench) (Xbench-Team, 2025), a Chinese benchmark for which the paper reports results on both the 2505 version and the more challenging 2510 version (denoted with † in Table 1). All four benchmarks are web-based QA tasks requiring agents to locate, navigate, and synthesize hard-to-find information that is not directly retrievable via simple search queries—they explicitly test the ability to access dynamic content, interact with forms, and navigate multi-step page structures that static search-and-visit agents cannot handle. In total, these benchmarks represent a combined evaluation set of over 1,800 questions spanning English and Chinese, wide and deep search, and varying difficulty levels, with performance measured on the full datasets except for GAIA where the text-only subset is used.

Base models. The paper trains two models from the Qwen3-Thinking family (Yang et al., 2025): Qwen3-4B-Thinking-2507 (a 4-billion-parameter dense model with thinking/reasoning capabilities) and Qwen3-30B-A3B-Thinking-2507 (a 30-billion-parameter Mixture-of-Experts model with 3 billion active parameters per forward pass, also with thinking capabilities). These models were chosen to span two substantially different scales while both possessing the extended reasoning chain capability ( thinking tags) that maps directly onto the outer loop's structured output format. The paper explicitly argues for the value of demonstrating strong browser-use capabilities at small scale: "training agentic capabilities on relatively small models is highly valuable" (Section 4.2), and the 4B-to-30B-A3B range tests whether the nested browser-use framework can compensate for limited parametric capacity through better information access. The Qwen3-Thinking models are not pre-trained for browser interaction—the NestBrowse training is what equips them with search, click, fill, evidence extraction, and multi-step IS reasoning.

Metrics. The primary metric is final answer accuracy measured via pass@1—the fraction of test questions for which the agent's single generated answer matches the ground-truth answer. Answers are verified using an LLM-as-a-Judge protocol with GPT-4.1 (OpenAI, 2025a) following the official evaluation prompts provided by each benchmark (Section 4.1). This protocol accounts for the fact that many deep IS answers are natural language strings, lists, or structured responses that cannot be naively string-matched, and the use of each benchmark's official evaluation prompts ensures comparability with prior work. The paper does not report intermediate metrics (e.g., tool-call accuracy, page extraction quality at test time, step-level correctness), focusing entirely on end-to-end task completion.

Baselines. The paper compares against an extensive set of both open-source and proprietary IS agents, organized in Table 1:

Closed-source systems (included as reference points, not direct competitors):

Claude-4-Sonnet and Claude-4-Opus (Anthropic, 2025): proprietary agents with undisclosed web toolkits
Kimi Researcher (Team, 2025a): proprietary system using text-based browser interaction
OpenAI-o4-mini and OpenAI-o3 (OpenAI, 2025c): proprietary systems with text-based (o4-mini) and full visual (o3) browser access
OpenAI DeepResearch (OpenAI, 2025d): proprietary deep research agent with full browser access
UI-TARS-2 (Wang et al., 2025): proprietary GUI agent using vision-based browser interaction

Open-source systems using only search and visit (the primary comparison class):

ASearcher-Web-32B (Gao et al., 2025): search-and-visit agent at 32B scale
DeepDive-32B (Lu et al., 2025): search-and-visit agent incorporating knowledge graphs and multi-turn RL
DeepDiver-V2-38B (Team, 2025b): search-only agent (no visit tool)
Kimi-K2-Instruct-1T (Team et al., 2025a): search-and-visit agent at 1 trillion parameter scale—a critical baseline for the "scale vs. tool design" argument
GLM-4.5-355B (Zeng et al., 2025): large-scale agent with undisclosed toolkit
WebExplorer-8B (Liu et al., 2025): search-and-visit agent at 8B scale
WebDancer-QwQ-32B (Wu et al., 2025a): search-and-visit agent
WebSailor-32B and WebSailor-72B (Li et al., 2025c): search-and-visit agents at two scales
WebShaper-QwQ-32B (Tao et al., 2025b): search-and-visit agent
MiroThinker-32B-DPO-V0.2 (Team et al., 2025b): search-and-visit agent
WebSailor-V2-30B-A3B-SFT (Li et al., 2025b): the most recent search-and-visit agent from the same research group as NestBrowse, serving as a strong in-house baseline
WebLeaper-30B-A3B-RU (Tao et al., 2025a): search-and-visit agent

Several of these baselines have substantially larger parameter counts than NestBrowse-4B and NestBrowse-30B-A3B (e.g., Kimi-K2-Instruct at 1T, GLM-4.5 at 355B, WebSailor-72B at 72B), allowing the paper to test whether the framework's design compensates for model scale. However, critically, none of these open-source baselines use browser-based interaction—they are all restricted to the search-and-visit paradigm. This means the comparison is between NestBrowse's browser-use approach and the static-retrieval approach that dominates open-source IS agents, not between different browser-use implementations.

Generation budget / compute accounting. The paper defines resource constraints in terms of two caps rather than a FLOPs budget: a maximum context length of 128K tokens (applied during both training and inference) and a maximum of 100 tool invocations per episode (Section 4.1). If the agent fails to produce a final answer within either limit, the episode is forcibly terminated and counted as incorrect. The context limit is the more binding constraint for browser-use scenarios, as demonstrated in Figure 3: without NestBrowse's nested design, raw page content would exceed 128K tokens after roughly 20 turns, terminating execution prematurely. Both NestBrowse variants (4B and 30B-A3B) are evaluated under identical resource constraints, and when comparing to baselines, the paper reports pass@1 scores as published in prior work or official leaderboards, implicitly assuming comparable evaluation budgets. The paper does not report wall-clock time or dollar cost for training or inference.

Cross-validation / statistical protocol. The paper does not describe any cross-validation protocol, statistical significance testing, or confidence interval reporting for its main results. The pass@1 scores in Table 1 are reported as point estimates without error bars or variance estimates. For the ablation studies (Tables 2 and 3, Figures 3 and 4), the paper specifies the evaluation subsets: the BrowseComp subset used for inner-loop analysis uses 100 examples (Section 4.5), and the context efficiency analysis (Figure 3) uses the "BrowseComp subset" without further specification. The GAIA and XBench ablation results in Table 2 use the full 103-question GAIA text-only subset and the full XBench dataset respectively, but the paper does not report how many runs or seeds were used. This absence of statistical rigor is a notable weakness—with the BrowseComp subset at 100 examples and GAIA at 103, differences of a few percentage points may not be statistically significant, yet the paper makes comparative claims based on these point estimates without acknowledging uncertainty.

Main Quantitative Results

Overall Benchmark Performance (Table 1)

The headline result is that NestBrowse-30B-A3B achieves 31.6% on BrowseComp, 42.6% on BrowseComp-zh, 75.7% on GAIA, and 75.0% on XBench-2505 (45.0% on the more challenging XBench-2510), while NestBrowse-4B achieves 22.4%, 28.4%, 68.9%, and 74.0% (38.0% on XBench-2510) respectively. These results are reported in Table 1 alongside all baselines.

Comparison to open-source search-and-visit agents (the primary competitive baseline class). On BrowseComp—the most challenging English deep IS benchmark—NestBrowse-30B-A3B (31.6%) substantially outperforms every open-source search-and-visit agent listed. The best search-and-visit open-source agent is GLM-4.5-355B at 26.4%, followed by WebSailor-V2-30B-A3B-SFT at 24.4%. NestBrowse-30B-A3B's 31.6% represents a 19.7% relative improvement over GLM-4.5-355B, despite GLM-4.5 having roughly 11.8x more parameters (355B vs. 30B total, and both are MoE architectures with different active parameter counts). NestBrowse-4B at 22.4% is competitive with WebLeaper-30B-A3B-RU (23.0%) and WebSailor-V2-30B-A3B-SFT (24.4%), despite having only 4B parameters—an 8.6x parameter efficiency advantage over the 30B-A3B MoE models and an 89x advantage over GLM-4.5-355B.

On GAIA, NestBrowse-30B-A3B achieves the highest score among all listed agents, both open-source and proprietary, at 75.7%. This exceeds OpenAI-o3 (70.5%), GLM-4.5-355B (66.0%), Kimi-K2-Instruct-1T (57.7%), and WebSailor-V2-30B-A3B-SFT (66.0%). NestBrowse-4B at 68.9% similarly exceeds all open-source search-and-visit agents and matches or exceeds several proprietary systems. The GAIA benchmark is the one where NestBrowse shows the strongest absolute advantage over search-and-visit approaches: the best non-NestBrowse open-source agent on GAIA is WebLeaper-30B-A3B-RU at 67.0%, meaning NestBrowse-30B-A3B provides a 13.0% relative improvement (75.7% vs. 67.0%).

On BrowseComp-zh, NestBrowse-30B-A3B (42.6%) outperforms all listed open-source agents except GLM-4.5-355B (37.5%)—though the paper reports 42.6% vs. 37.5%, which is the reverse of what the GLM-4.5 comparison would suggest (GLM-4.5 at 37.5% is lower than 42.6%). It is competitive with proprietary systems: OpenAI-o4-mini achieves 44.3%, UI-TARS-2 achieves 50.5%, and OpenAI-o3 achieves 58.1%.

On XBench-2505, NestBrowse-30B-A3B (75.0%) and NestBrowse-4B (74.0%) exceed all listed open-source agents (GLM-4.5-355B at 70.0% is the highest non-NestBrowse) and are competitive with or exceed proprietary systems (Kimi Researcher at 69.0%, OpenAI-o3 at 66.7%).

Comparison to proprietary systems. Against proprietary systems with browser access, NestBrowse-30B-A3B is competitive but not dominant on all benchmarks. On BrowseComp, OpenAI DeepResearch (51.5%) and OpenAI-o3 (49.7%) substantially outperform it, though NestBrowse-30B-A3B (31.6%) slightly exceeds UI-TARS-2 (29.6%) and Claude-4-Opus (18.8%). On BrowseComp-zh, OpenAI-o3 (58.1%) and UI-TARS-2 (50.5%) outperform NestBrowse-30B-A3B (42.6%). The paper does not claim NestBrowse matches the strongest proprietary systems—it positions NestBrowse as demonstrating that "small-scale agent models can acquire effective browser-use capabilities" and that the framework enables competitive performance without massive scale or proprietary infrastructure.

Cross-lingual generalization. The paper notes that "NestBrowse is trained solely on English data," yet its "browser-use and IS capabilities generalize well to out-of-distribution Chinese benchmarks" (Section 4.2). This is evident in the BrowseComp-zh and XBench results, where NestBrowse models are competitive with Chinese-language agents trained on Chinese data. The paper does not provide a controlled experiment isolating the source of this generalization (e.g., whether it comes from the base Qwen3 models' multilingual pretraining or from the NestBrowse training procedure), but the empirical result is clear: the framework's design principles transfer across languages without language-specific training.

Scale vs. design tradeoff evidence. The most striking evidence for the paper's claim that "performance is not solely determined by model scale, but is critically influenced by how agents are designed to access, organize, and interact with external information sources" comes from comparing NestBrowse-4B to much larger search-and-visit agents. NestBrowse-4B outperforms Kimi-K2-Instruct-1T on GAIA (68.9% vs. 57.7%), BrowseComp-zh (28.4% vs. 28.8%—roughly tied), and XBench-2505 (74.0% vs. 50.0%). It outperforms GLM-4.5-355B on GAIA (68.9% vs. 66.0%) and XBench-2505 (74.0% vs. 70.0%). These comparisons are not perfectly controlled—the models have different base architectures, training data, and training procedures—but the consistent pattern across four benchmarks and multiple large-model baselines supports the qualitative claim that browser-use design provides gains that cannot be recovered simply by scaling parameters in a search-and-visit paradigm.

Ablation of Browser-Use Strategies (Table 2)

The paper isolates the contributions of toolkit simplification and goal-relevant extraction through a controlled ablation using GPT-OSS-120B (OpenAI, 2025b) as the agent model across all variants, evaluated on GAIA and XBench (Table 2).

Four settings compared:

Naive: standard browser toolkit (many actions including scrolling, in-page search, etc.) without simplification and without goal-conditioned extraction; raw page content returned to the outer loop
Simplified: the NestBrowse four-action toolkit (search, visit, click, fill) but without goal-conditioned extraction; full (potentially truncated) page content returned
Compressed: the original (non-simplified) toolkit but with goal-relevant content extraction applied to page responses
NestBrowse: the full system with both toolkit simplification and goal-relevant extraction

Results on GAIA: Naive achieves 46.6%, Simplified achieves 55.3%, Compressed achieves 60.2%, and NestBrowse achieves 73.8%. The incremental gains are: +8.7 percentage points from toolkit simplification alone (Naive → Simplified), +13.6 points from goal-relevant extraction alone (Naive → Compressed), and +27.2 points from the combination (Naive → NestBrowse). The full NestBrowse outperforms the Naive baseline by a factor of 1.58x in absolute accuracy.

Results on XBench: Naive achieves 40.0%, Simplified achieves 40.0%, Compressed achieves 61.0%, and NestBrowse achieves 71.0%. On this benchmark, toolkit simplification alone provides no benefit (Naive and Simplified are tied at 40.0%), but goal-relevant extraction provides a +21.0 point gain, and the combination provides a +31.0 point gain over Naive.

Key observations from Table 2. First, the two components are additive: NestBrowse's combined performance (73.8% on GAIA, 71.0% on XBench) exceeds either component alone. Second, the relative importance differs by benchmark: on GAIA, both simplification (+8.7) and extraction (+13.6) contribute meaningfully, with extraction being roughly 1.6x more impactful; on XBench, simplification provides zero benefit while extraction provides +21.0 points, making extraction the dominant factor. The paper attributes this to the nature of the benchmarks—XBench tasks may involve more complex page structures where information filtering is critical, while GAIA tasks benefit from both the reduced decision complexity of the simplified toolkit and the context efficiency of extraction. Third, and crucially, this ablation uses a much stronger agent model (GPT-OSS-120B) than the trained NestBrowse models, for all variants, controlling for model capability and isolating the effect of strategy design. The NestBrowse-4B and NestBrowse-30B-A3B results in Table 1 are from models trained with the NestBrowse framework, not from applying the NestBrowse strategy to an untrained model—this ablation demonstrates the strategy's effectiveness independent of the training procedure.

Context Efficiency Analysis (Figure 3)

The paper quantifies the context management benefit of the nested design through a trajectory-level analysis on the BrowseComp subset (exact subset size not specified, but described as "the BrowseComp subset" in Section 4.4).

Figure 3 shows two curves as a function of outer-loop tool-call turn index:

Outer Loop Trajectory (the lower curve): the actual context length maintained in the outer loop's reasoning context. This includes the system prompt, user query, all reasoning blocks, all tool calls, and all tool responses—but for page-transition responses, only the extracted workspace <useful_info> content, not raw page content. The 128K token context limit is marked as a horizontal dashed line.
Whole Information Processed (the upper curve): the total volume of page content processed jointly by the outer and inner loops—i.e., the sum of all raw page segments across all pages visited, before extraction. This represents what would be injected into the outer loop's context if there were no nested design.

Key finding from Figure 3: "After approximately 20 tool-call turns, the total processed information already exceeds the agent's maximum context limit (128K tokens)." At this point, the Whole Information Processed curve crosses above the 128K threshold, while the Outer Loop Trajectory curve remains well below it (the paper estimates roughly 40K-60K tokens at this point based on the figure's y-axis scale). The gray bars in the background show the number of remaining active trajectories (tasks that have not yet terminated) at each turn index. The paper states: "Without NestBrowse, execution would terminate at this point, even though about 85% of tasks remain unfinished." This means that under a naive page-injection approach, context overflow would force termination at turn ~20, leaving 85% of benchmark tasks unsolved—a catastrophic failure mode for deep IS tasks that require sustained multi-turn information gathering.

Post-threshold behavior. After turn 20, the Whole Information Processed curve continues to grow (reaching roughly 700K-800K tokens by turn 80-100), while the Outer Loop Trajectory curve grows much more slowly and remains comfortably below the 128K threshold throughout the episode. The number of remaining active trajectories (gray bars) gradually decreases as tasks complete, with most tasks finishing between turns 20 and 80. The nested design thus enables agents to process total information volumes 5-6x larger than their context limit while maintaining feasible context sizes for reasoning.

This analysis is a diagnostic, not a comparative result—it demonstrates why NestBrowse's design is necessary for deep IS tasks, not how much better it is than alternatives. The paper does not show a comparable curve for a truncation-based baseline, which would be the natural comparison (showing that truncation either discards critical information or similarly overflows). The claim that "without NestBrowse, execution would terminate" thus assumes that the alternative is raw page injection without truncation, rather than a smart truncation strategy.

Intra-Page Exploration Quality (Figure 4)

The paper evaluates the inner loop's extraction quality on 100 trajectories per benchmark using GPT-4.1 as a judge model along two dimensions:

Raw snapshot retention: how well the agent preserves the original page snapshot in its extraction output, measured to assess whether the workspace retains the full context needed for subsequent interactions (e.g., element identifiers for future click actions)
Goal-relevant extraction accuracy: how well the extracted content aligns with the given goal, measured to assess whether the inner loop correctly identifies and captures relevant information while filtering irrelevant content

Figure 4 compares the base model (Qwen3-Thinking, before NestBrowse training) against NestBrowse (after multi-task training) on both metrics. The paper reports: "compared to the base agent model, NestBrowse achieves substantial improvements on both metrics." The specific numerical improvements are not quoted in the text—the figure uses bar charts with a scale from 0 to 1 (presumably accuracy rates from GPT-4.1's judgments), showing NestBrowse bars substantially taller than base model bars for both raw snapshot retention and goal-relevant extraction accuracy across all four benchmarks (BrowseComp, BrowseComp-zh, GAIA, XBench).

This result validates the multi-task training objective. The inner-loop training loss (Equation 7) directly supervises the model to produce goal-relevant extractions from page segments. The GPT-4.1 evaluation confirms that this supervision translates to improved extraction quality at test time—the trained model is better at both preserving page content (retention) and filtering for relevance (extraction accuracy) than the untrained base model. The paper interprets this as evidence that "multi-task training... simultaneously strengthens outer-loop agentic reasoning and inner-loop intra-page exploration" (Section 4.5).

Caveat: The evaluation uses GPT-4.1 as a judge, which is itself an imperfect evaluator. The paper does not report inter-annotator agreement between GPT-4.1 and human judgments, does not validate the judge's accuracy on a calibration set, and does not report the specific prompts used for evaluation. The "substantial improvements" claim thus rests on an uncalibrated LLM judge.

Impact of Inner-Loop Quality on Outer-Loop Performance (Table 3)

Table 3 presents a cross-model ablation on the BrowseComp subset (100 examples) that tests whether inner-loop extraction quality causally affects outer-loop task completion:

Outer-Loop Model	Inner-Loop Model	BrowseComp
NestBrowse-30B-A3B	NestBrowse-4B	24.0
NestBrowse-30B-A3B	NestBrowse-30B-A3B	35.0
NestBrowse-30B-A3B	GPT-OSS-120B	36.0

The outer-loop model is always NestBrowse-30B-A3B (the stronger reasoning model), while the inner-loop model varies. When the inner-loop uses the weaker NestBrowse-4B (4B parameters, trained for extraction), BrowseComp accuracy drops from 35.0% to 24.0%—a 31.4% relative degradation. When the inner-loop uses the stronger GPT-OSS-120B, accuracy rises to 36.0%—a modest 2.9% relative improvement over the 30B-A3B inner loop.

Interpretation. The paper states this shows "a clear positive relationship between the two" and "underscores intra-page exploration as a critical component of information acquisition." The large drop from 30B-A3B → 4B inner-loop suggests that extraction quality is a bottleneck: even a strong reasoning model cannot compensate for poor evidence extraction from pages. The small gain from 30B-A3B → GPT-OSS-120B inner-loop suggests either (1) the 30B-A3B inner loop is already near the quality ceiling for this task, (2) the outer-loop reasoning (by the same 30B-A3B model) becomes the bottleneck when extraction is sufficiently good, or (3) the small sample size (100 examples) limits the resolution of the comparison.

This result provides the empirical justification for joint training. If inner-loop and outer-loop capabilities were fully separable—if a strong reasoning model could work equally well with any extraction module—the three rows in Table 3 would show identical or near-identical performance. The measured 11-percentage-point gap between the weakest and strongest inner-loop configurations contradicts this separability assumption and supports the paper's architectural choice to train both capabilities jointly in a single model, with equal loss weighting.

Caveat: The paper does not report results for the reverse experiment (varying the outer-loop model while keeping the inner-loop fixed) or for the case where neither loop uses a NestBrowse-trained model. This would help distinguish whether the degradation comes from the 4B model's weaker capacity or from the fact that it was trained on the multi-task objective (NestBrowse-4B is a NestBrowse-trained model with inner-loop capability). A full disentanglement would require testing: (a) a 4B model without inner-loop training as the inner loop, (b) a separately trained extraction model not using the multi-task objective, and (c) the base Qwen3 models without any NestBrowse training.

Case Study: Meta-Tool Use via Browser-Based Calculator (Figure 5)

The paper presents a qualitative case study from GAIA where NestBrowse-30B-A3B solves a numerical computation task (Newton's Method iteration) by using an online browser-based calculator rather than performing the computation internally. The workflow proceeds in three phases:

Search phase: The agent searches for "Newton's method" and identifies a relevant URL (planetcalc.com/7748/), an online calculator for Newton's method.
Interaction phase: The agent visits the calculator page, observes that it has a default function ( $x^3 + 3x^2 + 12x + 8$ ) that does not match the task's function ( $f(x) = x^3 + 4x^2 - 3x + 8$ ), fills the input fields with the correct function and initial value ( $x_0 = -5$ ), and clicks the "Calculate" button.
Evidence extraction phase: The agent receives the computed result from the page (the iteration table produced by the calculator), extracts the relevant numerical values, and synthesizes the final answer.

The paper highlights this case as demonstrating a key advantage of browser-use: "Rather than serving solely as a medium for information access, browser-use enables agents to exploit the rich functional ecosystem of the web, including interactive utilities that are inaccessible through static page fetching alone" (Section 4.6). For a 4B or 30B-A3B model, multi-step numerical computation with rounding to four decimal places would be error-prone through internal reasoning. By outsourcing the computation to a purpose-built web utility, the agent reduces its reasoning burden and increases reliability.

This case study is an existence proof rather than a quantitative result—it demonstrates that NestBrowse can engage in meta-tool use, not how frequently it does so or whether this pattern contributes significantly to overall benchmark performance. The paper does not report what fraction of NestBrowse's correct answers involve interactive tool use versus static page extraction.

Ablation Studies and Robustness Checks

Toolkit simplification vs. goal-relevant extraction (Table 2): Both components independently improve performance over the Naive baseline, with extraction contributing more on both GAIA (+13.6 points) and XBench (+21.0 points) than simplification (+8.7 and 0.0 points respectively). The full NestBrowse achieves the strongest performance on both benchmarks (73.8% GAIA, 71.0% XBench), confirming an additive effect. A non-obvious finding is the benchmark-dependent contribution of toolkit simplification: it provides substantial gains on GAIA but zero gain on XBench. The paper does not investigate this difference, but it suggests that the action-space complexity of standard browser toolkits is more harmful on certain task distributions than others.

Inner-loop model quality affects outer-loop performance (Table 3): Using NestBrowse-4B as the inner loop degrades NestBrowse-30B-A3B's BrowseComp accuracy from 35.0% to 24.0% (a 31% relative drop), while using GPT-OSS-120B as the inner loop improves it to 36.0% (a modest 2.9% relative gain). This confirms that extraction quality is not a separable concern—it constrains reasoning performance. The asymmetric effect (large drop from weak extraction, small gain from very strong extraction) suggests that the 30B-A3B inner loop is near the quality ceiling for the outer-loop model's reasoning capability, but a 4B inner loop is a significant bottleneck.

Context efficiency of the nested design (Figure 3): Without NestBrowse, execution would terminate at approximately 20 tool-call turns due to context overflow, leaving 85% of BrowseComp tasks unfinished. The nested design keeps the outer-loop context within the 128K limit while processing total information volumes exceeding 700K tokens by turn 80-100. This is a diagnostic result demonstrating necessity, not a comparative ablation against truncation-based alternatives.

Inner-loop extraction quality after multi-task training (Figure 4): GPT-4.1-as-judge evaluation shows NestBrowse-trained models achieve substantially higher raw snapshot retention and goal-relevant extraction accuracy compared to the untrained base model, across all four evaluation benchmarks. This validates that the inner-loop training objective (Equation 7) produces measurable improvements in extraction capability.

Cross-lingual generalization without Chinese training data: NestBrowse is trained only on English data (SailorFog-QA-V2) but achieves competitive performance on Chinese benchmarks (42.6% on BrowseComp-zh, 75.0% on XBench-2505 for the 30B-A3B model). This is a robustness observation rather than a controlled ablation, but it suggests the framework's design principles—minimal toolkit, nested extraction, goal-conditioned filtering—transfer across languages.

Missing ablations. Several experiments that would strengthen the paper's claims are absent:

No ablation of the number of tools: While the paper argues four is "minimally complete," it never tests three-tool or five-tool variants. Would adding scroll as a fifth tool degrade performance (as the action-complexity argument predicts) or improve it (by enabling the agent to handle pages that require scrolling to load dynamic content)? Would removing fill (leaving only search, visit, click) maintain functional completeness for benchmarks that don't require text input?
No ablation of the segmentation strategy: The paper segments pages into chunks but never specifies the segmentation algorithm or ablates different chunk sizes. Chunk size directly affects extraction quality—too small loses cross-segment context, too large degrades per-segment model performance—yet this is not studied.
No ablation of loss weighting: The paper uses λ_out = λ_in = 1 by default but never sweeps these weights. Does imbalanced weighting (e.g., λ_out = 0.1, λ_in = 0.9) produce better extraction at the cost of reasoning, or vice versa? The optimal ratio might depend on the task distribution.
No ablation of rejection sampling strictness: The three filtering criteria (format, tool validity, final correctness) are applied as hard filters, but the paper does not report the rejection rate or test whether relaxing any criterion (e.g., including trajectories with tool hallucinations but correct final answers) changes model performance.
No comparison to truncation-based baselines: Figure 3 shows NestBrowse avoids context overflow, but the paper never implements a reasonable truncation baseline (e.g., truncate pages to the first 16K tokens, or to the first N paragraphs) and measures how much accuracy is lost for how much context savings.
No comparison to separate-model architectures: Table 3 varies the inner-loop model while keeping the outer-loop model fixed, but the paper never compares this joint-training approach to a baseline where the outer-loop and inner-loop models are trained entirely separately (e.g., a dedicated extraction model fine-tuned on a page extraction task, composed with a reasoning model fine-tuned on tool-use trajectories with perfect extraction). The claim that joint training is superior rests on the intuition that the two capabilities are interdependent, but this is not directly tested.

Critical Assessment

Claim 1: "NestBrowse enables effective browser-use for IS agents and achieves strong performance across challenging benchmarks"

The evidence for this claim is the most robust in the paper. Table 1 shows NestBrowse-30B-A3B achieving 31.6% on BrowseComp, 42.6% on BrowseComp-zh, 75.7% on GAIA, and 75.0% on XBench-2505. These numbers are reported as pass@1 scores on the full benchmark datasets against a comprehensive set of baselines. The claim is straightforward—"NestBrowse works"—and the experimental evidence is sufficient to support it.

However, what "works" means requires qualification. NestBrowse outperforms open-source search-and-visit agents across all four benchmarks (the primary competitive class), but it does not match the strongest proprietary browser-using agents (OpenAI-o3 at 49.7% BrowseComp, OpenAI DeepResearch at 51.5%). The paper explicitly positions NestBrowse as enabling strong performance at small model scale rather than as state-of-the-art overall. This claim is well-supported.

A genuine weakness: the paper does not demonstrate that the strong performance is specifically due to browser-use as opposed to other factors that differ between NestBrowse and the search-and-visit baselines—different training data (SailorFog-QA-V2 vs. whatever each baseline used), different base models (Qwen3-Thinking vs. various architectures), and different training procedures (multi-task imitation learning with rejection sampling vs. SFT, RL, or other methods). The ablation in Table 2 uses the same agent model (GPT-OSS-120B) for all strategy variants, which controls for model capability, but this ablation isolates the strategy design, not the training procedure. The NestBrowse-4B and NestBrowse-30B-A3B results come from models trained with the NestBrowse objective on SailorFog-QA-V2, while most baselines were trained with different objectives on different datasets. The performance gap cannot be cleanly attributed to browser-use versus search-and-visit alone.

Claim 2: "Performance is not solely determined by model scale, but is critically influenced by how agents are designed to access, organize, and interact with external information sources"

This claim is supported across multiple comparisons in Table 1: NestBrowse-4B (4B parameters) outperforms Kimi-K2-Instruct-1T (~250x larger parameters) on GAIA (68.9% vs. 57.7%) and XBench (74.0% vs. 50.0%), and outperforms GLM-4.5-355B (~89x larger) on GAIA (68.9% vs. 66.0%) and XBench (74.0% vs. 70.0%).

However, the claim describes a correlation between design quality and performance, not a controlled causal relationship. The large-model baselines differ from NestBrowse in many ways beyond browser-use design: base model architecture, pretraining data, instruction tuning data, tool-use training procedure, and evaluation protocol details (even when using the same benchmark, different papers may use slightly different evaluation configurations). The paper's own ablation (Table 2) demonstrates that browser-use strategy design matters within a controlled setting (same model, same evaluation), but the cross-model comparisons in Table 1 are uncontrolled. The evidence supports the qualitative claim that design matters, but quantifying how much design matters relative to scale would require a parametric experiment (e.g., training NestBrowse and a search-and-visit baseline from the same base model on the same training data with the same compute budget) that the paper does not perform.

Additionally, the claim is directional—"not solely determined by model scale"—which is a weak claim. It would be more informative to characterize the exchange rate between scale and design: does NestBrowse-4B outperform a search-and-visit agent of what parameter count? At what scale does a search-and-visit agent catch up to NestBrowse-4B? The paper provides cross-sectional point estimates (4B NestBrowse vs. 1T search-and-visit) but no systematic trading curve across scales.

Claim 3: "The nested design enables controlled information flow that keeps agent context within feasible limits throughout execution"

Figure 3 provides strong diagnostic evidence for this claim: the outer-loop context remains below 128K tokens while total processed information exceeds 700K tokens, and execution can continue past turn 20 where a naive approach would overflow. The data is clear and the claim is narrow (the nested design controls context usage), so this is well-supported.

The weakness is the missing comparison to a truncation baseline. The paper establishes that the naive alternative (injecting all raw page content) fails catastrophically at turn ~20, but this is a straw-man baseline—no serious IS agent would inject unlimited raw page content without any truncation or filtering. A fair comparison would be: NestBrowse vs. a smart truncation strategy (e.g., keep the first N tokens or the most semantically relevant paragraphs). The paper does not establish whether the nested design is better than reasonable alternatives or merely better than an obviously broken approach. The presence of earlier work on context summarization for IS agents (Wu et al., 2025c, cited in the paper) suggests that truncation and summarization baselines exist and are used in practice—the paper should compare against these.

Claim 4: "Joint training of outer-loop and inner-loop capabilities is beneficial, as evidenced by the interdependence between the two"

Table 3 provides evidence for interdependence: varying the inner-loop model changes outer-loop performance (24.0% → 35.0% → 36.0%). This demonstrates that extraction quality constrains reasoning—a weak inner loop hurts the outer loop. The paper interprets this as supporting joint training.

However, what Table 3 demonstrates is interdependence, not that joint training is the optimal way to achieve high performance on both. A modular system with separately trained but high-quality components (e.g., GPT-OSS-120B as the inner loop, NestBrowse-30B-A3B as the outer loop) achieves 36.0%—slightly better than the jointly trained pure NestBrowse-30B-A3B (35.0%). If the jointly trained model were clearly superior to all modular compositions, the case for joint training would be strong. The fact that the best result in Table 3 comes from a modular composition (GPT-OSS-120B inner + NestBrowse-30B-A3B outer) actually provides evidence against the necessity of joint training. The paper's argument for joint training rests on (1) the practical advantage of having a single model rather than two, and (2) the assumption that joint training produces better inner-loop performance than a separately trained extraction model of comparable size—but this assumption is not tested.

The missing experiment is a comparison between: (a) NestBrowse-30B-A3B trained jointly (the current approach), and (b) the same base model trained separately on the outer-loop objective and a dedicated inner-loop model of comparable size trained separately on the inner-loop objective, then composed at inference time. If (a) outperforms (b), joint training is demonstrably better. If (b) matches or exceeds (a), the joint training claim is weaker, and the architectural choice becomes an engineering convenience rather than a performance necessity.

Claim 5: "The minimal four-tool browser toolkit provides functionally complete web information access while reducing decision burden"

The ablation in Table 2 provides some evidence: the Simplified setting (four-tool toolkit without extraction) outperforms the Naive setting (standard toolkit without extraction) by 8.7 points on GAIA, suggesting that toolkit simplification alone improves performance. On XBench, the two settings tie (both 40.0%), suggesting the benefit is benchmark-dependent.

The "functional completeness" claim—that four tools suffice to access all web content categories—is not directly tested. The paper never demonstrates that NestBrowse achieves higher coverage of dynamic content than search-and-visit agents (this would require instrumenting the evaluation to count what fraction of tasks require dynamic interaction and what fraction of those NestBrowse successfully completes). The case study (Figure 5) provides an existence proof—NestBrowse can use a web calculator—but not a quantitative characterization. The claim that the toolkit is complete is an assertion about the space of web interactions, not an empirical finding.

Additionally, the paper does not test whether the excluded actions (scrolling, in-page search) would actually harm performance if included. The argument that these actions "merely limit content exposure per page read without improving goal-directed information acquisition" is a theoretical claim about their function, not an empirical demonstration that including them degrades accuracy or efficiency. An ablation adding these actions back to the Simplified toolkit and measuring the impact would directly test this.

Overall assessment of experimental rigor

Strengths: The paper evaluates on four diverse benchmarks spanning two languages and multiple difficulty levels, uses a comprehensive set of open-source and proprietary baselines, conducts controlled ablations on strategy design (Table 2) and component interdependence (Table 3), and provides diagnostic analyses of context efficiency (Figure 3) and extraction quality (Figure 4). The total evaluation set of over 1,800 questions is reasonably sized for the claims being made. The ablation in Table 2 is particularly well-designed because it uses the same strong base model (GPT-OSS-120B) for all strategy variants, cleanly isolating the effect of the NestBrowse design choices from model capability.

Weaknesses:

No statistical reporting. All results are point estimates without confidence intervals, standard deviations, or significance tests. With GAIA at 103 questions and the BrowseComp subset at 100 questions (used in Tables 2-3 and Figures 3-4), a difference of a few percentage points may not be statistically significant. The paper makes comparative claims based on these point estimates without acknowledging uncertainty.
No evaluation on search-and-visit tasks. The paper evaluates only on deep IS benchmarks that require browser interaction. It does not evaluate on standard multi-hop QA or shallow IS benchmarks where search-and-visit agents excel, which would establish whether browser-use imposes a cost (in efficiency or accuracy) on simpler tasks.
No comparison of training data or compute. The paper does not control for training data quality or quantity when comparing to baselines—NestBrowse is trained on SailorFog-QA-V2 with a specific multi-task objective and rejection sampling, while baselines use various undisclosed training datasets and procedures. The performance gap may partly reflect data quality differences rather than the browser-use design.
Single base model family. All NestBrowse models are trained from Qwen3-Thinking. The framework's claims about tool abstraction and nested interaction are architecture-agnostic in principle, but the paper provides no evidence that the approach transfers to other model families (e.g., Llama, DeepSeek, Gemma).
Oracle evaluation of inner-loop quality. The inner-loop evaluation (Figure 4) uses GPT-4.1 as a judge without reporting calibration, inter-annotator agreement, or comparison to human judgments. The "substantial improvements" claim over the base model rests on an unvalidated LLM judge.
Missing cost analysis. The paper does not report the token cost per task, the average number of tool calls per completed task, or the average wall-clock time. The nested design processes entire pages in the inner loop, which may be computationally expensive (each segment requires a forward pass through the model for extraction). A latency or cost comparison against search-and-visit agents would contextualize the accuracy gains.
Missing negative results or failure analysis. The paper reports only aggregate pass@1 scores and one qualitative success case. It does not analyze failure modes, categorize error types, or report per-category breakdowns. Understanding when and how NestBrowse fails (e.g., does it fail at search, at page navigation, at extraction, at reasoning?) would strengthen the diagnostic value of the evaluation and guide future improvements.

6. Limitations and Trade-offs

6.1 Text-Only Browser Interaction Excludes Visually-Grounded Information

The assumption or constraint. NestBrowse deliberately restricts all browser interaction to textual content, parsing pages into semantic DOM snapshots that capture structure and interactive elements through text alone. The paper explicitly acknowledges this in Section 6 (Limitations and Future Work):

"we intentionally restrict our browser modeling to textual content. This design choice is motivated by the need to isolate the effects of tool abstraction and interaction paradigms, and to maintain a controlled and interpretable experimental setting."

This means that images, videos, charts, diagrams, visual layouts, and any information encoded purely in visual form (screenshots of tables, rendered graphs, CAPTCHAs, image-based navigation) are invisible to the agent. The paper's footnote in Section 3.1 reinforces this: "our setup considers only textual page content and does not incorporate any visual information."

The consequence. In real-world browsing, substantial information is conveyed only through visual modalities. A product specification might be rendered as an image rather than HTML text. A data table might exist only as a screenshot. Navigation elements might be identifiable only by their visual appearance (icons without alt text, image buttons, spatially-arranged menus). An agent restricted to text-only DOM snapshots is blind to all of these. More critically, the benchmarks the paper evaluates on—BrowseComp, GAIA, BrowseComp-zh, XBench—may systematically under-represent such visually-grounded information by design (they are text-answer QA tasks), meaning the text-only limitation's severity in a deployment context is not measured. The paper's strong results on these benchmarks do not guarantee that NestBrowse's approach would transfer to tasks requiring visual understanding, such as interpreting infographics, navigating image-heavy e-commerce sites, or completing CAPTCHA-gated workflows.

Additionally, the text-only design has a subtler consequence for action grounding. The click and fill tools rely on interactive-element identifiers extracted from the DOM snapshot. If a page's interactive elements lack textual identifiers (e.g., buttons with only CSS-class-based selectors, dynamically generated IDs that change between page loads, or icon-only elements), the agent may be unable to target them. Vision-based agents can ground actions in screen coordinates; NestBrowse's text-only agent must rely on the semantic DOM to provide usable identifiers, which is not guaranteed across the heterogeneous web.

What evidence exists in the paper. None directly. The paper does not evaluate NestBrowse on any benchmark requiring visual understanding, does not compare text-only to visual browser-use on the same tasks, and does not report what fraction of desired interactions fail due to missing or ambiguous element identifiers. The baseline systems in Table 1 that use full "browser" access (OpenAI-o3, OpenAI DeepResearch) achieve substantially higher BrowseComp scores (49.7% and 51.5% vs. NestBrowse-30B-A3B's 31.6%), and while this gap cannot be attributed to visual access alone (these are larger proprietary models with undisclosed training procedures), it is consistent with the hypothesis that visual information provides additional capability that text-only systems cannot recover.

Mitigation status. The paper does not mitigate this limitation. It explicitly defers multimodal extension to future work (Section 6): "Incorporating additional modalities such as vision or audio would introduce substantial modeling and system complexity, making it difficult to disentangle the contributions of browser-use learning from those of multimodal perception. Nevertheless, non-textual modalities often convey important information in real-world browsing scenarios. Extending the proposed NestBrowse to support multimodal information acquisition and reasoning represents a promising future direction." This is a transparent acknowledgment of the limitation without any attempt to bound its severity. A practitioner deploying NestBrowse would need to independently assess whether their target web domains contain critical visual-only information.

6.2 The Difficulty Estimation and Rejection Sampling Pipeline Is Expensive and Unquantified

The assumption or constraint. The training pipeline relies on rejection sampling to filter trajectories generated by rolling out the agent on SailorFog-QA-V2, retaining only those that (1) adhere to the output format, (2) contain valid and executable tool calls, and (3) lead to correct final answers. The paper does not report the rejection rate—what fraction of generated trajectories are discarded. Since "interleaving reasoning with browser interaction constitutes a challenging agentic capability, and model rollouts do not always exhibit the desired behavior" (Section 3.3), the rejection rate could be high, particularly early in training when the base model has no browser-use skills.

The consequence. The cost of training NestBrowse is not simply the ~1,344 GPU hours (4B) and ~4,096 GPU hours (30B-A3B) reported in Section 4.1—these represent the training compute on accepted trajectories. The cost of generating the trajectories that were subsequently rejected is unaccounted for. If the rejection rate is, say, 90%, the total compute (generation + training) is roughly 10× the reported training compute. A practitioner seeking to replicate NestBrowse on a new domain or base model would need to budget for this unquantified generation overhead, which could dominate the total cost.

Beyond the unquantified cost, the rejection sampling approach has a coverage consequence. By filtering to only correct trajectories, the training data contains no examples of error recovery—the model never sees a trajectory where the agent makes a mistake, realizes the mistake, and corrects it. All training trajectories are successful end-to-end, which means the model learns what successful information seeking looks like but never learns to recognize or recover from failure. At inference time, when the agent inevitably makes an error (a bad search query, a visit to an irrelevant page, a click on the wrong element), it has no training signal for how to detect the error and backtrack. This may contribute to the 100-tool-call cap being reached (a failure mode the paper does not analyze) and limits the agent's robustness to the inevitable stochastic errors in tool use.

What evidence exists in the paper. None. The paper does not report the rejection rate, the number of trajectories generated per training question, the distribution of rejection reasons, or the compute cost of trajectory generation. The paper does not analyze failure modes of the trained agent to determine whether error recovery is a weakness. The only evidence that rejection sampling was performed at all is the procedural description in Section 3.3 and the training compute numbers in Section 4.1.

Mitigation status. Not addressed or acknowledged as a limitation. The paper treats rejection sampling as a quality filter without discussing its cost or coverage implications. A practitioner would need to independently determine acceptable rejection rates for their domain and potentially augment the training data with synthetic error-recovery trajectories to improve robustness.

6.3 Evaluation Is Limited to Four Text-Answer QA Benchmarks; Generalization to Other Information-Seeking Tasks Is Unproven

The assumption or constraint. All four evaluation benchmarks—BrowseComp, GAIA, BrowseComp-zh, and XBench-DeepSearch—share a common structure: they are text-answer QA tasks where the agent must find a specific fact, number, or short string and produce it as a final answer enclosed in <answer> tags. There is always a ground-truth answer against which to score pass@1 accuracy. The evaluation methodology assumes that the benchmark questions test the ability to access dynamic web content, but the paper provides no instrumentation of the evaluation to verify what fraction of tasks actually require the browser toolkit's click and fill capabilities versus what could be solved with search and visit alone.

The consequence. The paper's central claim—that NestBrowse enables effective browser-use for IS agents—is supported only on this narrow class of text-answer QA tasks. Real-world information seeking encompasses a much broader spectrum: open-ended research (producing a multi-page report with citations), comparative analysis (evaluating product options across multiple dimensions), temporal monitoring (tracking changes over time), structured data extraction (populating a spreadsheet from multiple sources), and verification tasks (checking whether a claim is substantiated by web evidence). None of these are evaluated. A practitioner deploying NestBrowse for, say, competitive intelligence research (requiring synthesis of information across dozens of pages into a structured brief) has no evidence that the framework transfers.

There is also a language and domain coverage gap: the English benchmarks (BrowseComp, GAIA) and Chinese benchmarks (BrowseComp-zh, XBench) test web interaction in two languages, but the paper notes that NestBrowse is "trained solely on English data" (Section 4.2). The strong Chinese-benchmark performance is attributed to cross-lingual generalization from the base Qwen3 models, but there is no controlled experiment isolating whether this generalization comes from the base model's multilingual pretraining or the NestBrowse training. The framework's behavior on other languages, or on non-English web domains with different interaction conventions, is unknown.

Additionally, the evaluation is limited to the exact tool configuration used in training. The benchmarks test Google search (the search tool's backend), Playwright-based headless browsing, and DOM-to-text conversion. Performance may not transfer if the search backend changes (e.g., different search engine ranking), if pages render differently across browsers, or if the DOM-to-text conversion produces different outputs for different page structures.

What evidence exists in the paper. The four-benchmark evaluation in Table 1 provides point estimates of pass@1 accuracy. There is no task-type breakdown within benchmarks (e.g., what fraction of GAIA questions require form interaction vs. static retrieval, and how NestBrowse performs on each fraction). The paper does not evaluate on open-ended generation, comparative analysis, or structured extraction tasks. The cross-lingual generalization is observed but not systematically tested (e.g., no ablation of Chinese training data).

Mitigation status. The paper does not acknowledge evaluation scope as a limitation. It treats the four benchmarks as representative of "deep information-seeking" without discussing what task classes are excluded. The cross-lingual results are presented as a positive finding without discussing the absence of controlled experiments.

6.4 The Nested Design Introduces a Latency-for-Context Tradeoff That Is Not Characterized

The assumption or constraint. The nested browser-use framework processes each visited page through an inner loop that segments the page content, performs a forward pass through the model for each segment, and incrementally updates a workspace. The number of inner-loop forward passes scales linearly with page size: a 100K-token page segmented into 4K-token chunks requires 25 sequential model forward passes before the outer loop receives its response. Each forward pass involves the same model weights used for outer-loop reasoning, meaning the inner loop competes for compute and, critically, introduces serial dependency—the outer loop cannot proceed until the inner loop completes all segments.

The consequence. For large pages (which the paper identifies as common: "A single page can easily exceed 64K tokens and may even surpass 1M tokens," Section 3.2), the inner loop imposes a substantial latency penalty. An agent visiting a 200K-token page with 4K-token segments requires approximately 50 sequential model forward passes just to generate the workspace returned to the outer loop as a single tool response. In a deployment scenario, this translates directly to wall-clock time: the agent is blocked on page extraction, not on reasoning. For tasks requiring multiple page visits, this latency compounds. The outer loop's 100-tool-call maximum could translate to thousands of inner-loop forward passes (if each visited page is large), making total inference latency potentially minutes or hours per task.

This is the fundamental tradeoff the paper does not resolve: context efficiency (keeping the outer-loop context small) is achieved at the cost of inference latency (processing pages through multiple inner-loop forward passes). The paper's Figure 3 demonstrates that the nested design prevents context overflow, which enables longer-horizon tasks to complete. But it does not demonstrate that this comes at an acceptable latency cost, or characterize the latency-context tradeoff space.

Additionally, because the inner-loop processing is goal-conditioned, the same page visited under different goals at different points in the agent's trajectory would be re-processed from scratch—the inner loop has no mechanism for caching or reusing extraction results across the same page accessed multiple times, a pattern that occurs in real IS tasks (e.g., re-visiting a page to extract different information).

What evidence exists in the paper. Figure 3 shows the total processed information reaching ~700K-800K tokens by turn 80-100, but the paper does not report how many inner-loop forward passes this corresponds to, the average wall-clock time per task, or the latency distribution across tasks. The training compute is reported in GPU-hours, but inference latency is not discussed anywhere in the paper.

Mitigation status. Not addressed. The paper treats the nested design purely as a context-management solution without acknowledging the latency cost. A practitioner deploying NestBrowse would need to independently measure whether the latency is acceptable for their use case and whether it can be reduced through techniques like segment-level batching, speculative extraction, or caching of intermediate workspace states for re-visited pages.

6.5 No Comparison Against the Most Obvious Alternatives: Truncation-Based Baselines and Separate-Model Architectures

The assumption or constraint. The paper's ablation studies (Tables 2 and 3) compare NestBrowse against: (1) a naive full-toolkit no-extraction setting, (2) toolkit simplification without extraction, (3) extraction without toolkit simplification, and (4) varying the inner-loop model quality. These are all internal ablations—they test variants of NestBrowse's own components. The paper never compares NestBrowse against two architecturally distinct approaches that represent the most natural alternatives:

Truncation-based context management: instead of the nested inner loop, simply truncate raw page content to the first N tokens (e.g., 8K, 16K, 32K) and inject it directly into the outer loop. This is the approach used by "most existing IS agents" (Section 3.2) and represents the pragmatic baseline the paper's design is meant to improve upon.
Separate extraction and reasoning models: train a dedicated model (possibly smaller and faster) for the inner-loop extraction task, and compose it with the outer-loop reasoning model at inference time. This is the natural modular alternative to joint training.

The consequence. Without a truncation baseline, the paper cannot quantify the benefit of the nested design over the pragmatic alternative that practitioners would actually use. Figure 3 demonstrates that injecting all raw page content overflows context at turn ~20, but no real system would do this—they would truncate. The question is whether NestBrowse's goal-conditioned extraction preserves enough information relative to smart truncation to justify the latency cost (see Section 6.4) and implementation complexity. The paper provides no evidence to answer this.

Without a separate-model baseline, the paper's claim that joint training is beneficial (Section 4.5, interpretation of Table 3) is weakened. Table 3 shows that a modular composition with GPT-OSS-120B as the inner loop achieves 36.0% on the BrowseComp subset, slightly better than the jointly trained NestBrowse-30B-A3B at 35.0%. This suggests that a sufficiently strong separately-trained extraction model can match or exceed joint training performance. The paper provides no comparison between jointly trained NestBrowse-30B-A3B and a baseline where the same base model is split into separately trained reasoning and extraction modules with comparable total parameters and training compute. Without such a comparison, the case for joint training rests on the practical convenience of a single model, not on a demonstrated performance advantage.

What evidence exists in the paper. None. The paper does not implement or evaluate a truncation baseline. The paper does not implement or evaluate a separately-trained extraction model composed with a separately-trained reasoning model (Table 3 uses GPT-OSS-120B, a proprietary model, as the extraction module, not a model trained using the NestBrowse inner-loop objective in isolation).

Mitigation status. Not acknowledged as a gap. The paper treats the internal ablations as sufficient to validate the design, but these ablations do not rule out simpler or more modular alternatives achieving comparable performance. A practitioner would need to run their own comparison against truncation-based context management and modular architectures before adopting the complexity of the nested joint-training framework.

6.6 The Training Data Requirement (SailorFog-QA-V2) Is a Single, Task-Specific Dataset; Generalization to Other Domains May Require Comparable Browser-Use Training Data

The assumption or constraint. The paper trains NestBrowse exclusively on SailorFog-QA-V2 (Li et al., 2025b), described as "a high-quality QA set designed to elicit complex browsing behaviors that require both effective tool use and multi-step reasoning from IS agents" (Section 3.3). The paper explicitly argues that simpler datasets (single-hop QA, multi-hop QA) are insufficient because they "can often be solved with only one or a few search queries, without requiring substantive browsing or reasoning." This means the browser-use capabilities acquired through training are tightly coupled to the distribution of tasks and required interactions represented in SailorFog-QA-V2.

The consequence. A practitioner seeking to deploy NestBrowse in a different domain—medical literature review, legal document research, financial data aggregation, e-commerce comparison, scientific paper synthesis—faces an open question: can the NestBrowse-trained model generalize its browser-use skills to these domains, or must the practitioner construct a domain-specific dataset of comparable complexity and repeat the multi-task training pipeline? The paper provides no zero-shot transfer evaluation to domains outside SailorFog-QA-V2's distribution.

The cross-lingual generalization (English training → strong Chinese-benchmark performance) provides some evidence that the acquired skills transfer across languages, but this transfer is likely mediated by the Qwen3 base model's multilingual pretraining and by the structural similarity of the benchmarks (BrowseComp-zh mirrors BrowseComp's design). It does not demonstrate transfer to structurally different task types (e.g., open-ended research report generation, multi-criteria comparative analysis) or to domains with different interaction patterns.

Furthermore, the paper's claim about simpler datasets being insufficient implies that SailorFog-QA-V2 has specific properties (complex browsing requirements, multi-step reasoning demands) that are necessary to elicit the desired behaviors during training. If this is true, then replicating NestBrowse for a new domain requires identifying or constructing a dataset with those same properties—a non-trivial data engineering challenge that the paper does not provide guidance for.

What evidence exists in the paper. The evaluation covers four benchmarks that share a task structure (text-answer QA) but span two languages and different construction methodologies. The cross-lingual results (42.6% on BrowseComp-zh, 75.0% on XBench-2505) provide evidence of language transfer but not task-type transfer. The paper does not evaluate on any benchmark or task that is structurally different from the training distribution (e.g., a summarization or comparison task requiring browser use).

Mitigation status. The paper references SailorFog-QA-V2 as "our primary training task" and provides a brief justification for the choice, but does not discuss the data requirement as a limitation for domain transfer. There is no analysis of what specific properties of SailorFog-QA-V2 are critical for effective training, and no guidance for constructing comparable datasets in new domains. A practitioner would need to either (1) run their own experiments to determine whether NestBrowse models zero-shot transfer to their target domain, or (2) construct domain-specific browser-use training data with unknown computational cost for trajectory generation and rejection sampling (see Section 6.2).

7. Implications and Future Directions

How This Work Changes the Landscape

This paper advances a new design philosophy for information-seeking agents: the web is not a collection of documents but an extensible meta-toolkit, and the agent's interface to that toolkit should be structurally optimized for goal-conditioned information acquisition rather than reconstructed from human browsing metaphors. The change this represents is primarily methodological and conceptual rather than a paradigm shift—the core technology (ReAct-style function-calling, supervised fine-tuning, headless browser automation) is well-established—but the specific combination of design decisions constitutes a substantive reframing of how IS agents should be built.

The paper makes three specific contributions to the field's thinking:

First, it demonstrates that the search-and-visit paradigm is an artificial ceiling, not a fundamental constraint of text-only IS agents. Prior to this work, the dominant open-source IS agent architecture used exactly two web tools: search for discovery and visit for static page retrieval. This was not because anyone argued two tools were sufficient in principle—the paper's characterization of dynamic web content ( $I_{\text{dynamic}}$ ) makes clear why they are not—but because adding browser interaction seemed to require either (a) the full complexity of GUI automation toolkits (dozens of actions, visual perception, coordinate-based grounding) or (b) proprietary systems whose approaches were unpublished. NestBrowse demonstrates a third path: four tools are sufficient for functional completeness, and the complexity of browser interaction can be managed through structural decoupling (the nested loop) rather than through model scale or visual perception. The empirical evidence is the 4B model's 68.9% on GAIA—a score exceeding 1T-parameter search-and-visit agents. This establishes that browser-use is not an exclusively large-model or proprietary capability.

Second, it reframes context management from a post-hoc compression problem to an architectural boundary problem. The field's standard response to context overflow in IS agents has been heuristic: truncate pages, summarize with a separate model, or scroll incrementally. These approaches treat context overflow as a nuisance to be worked around. NestBrowse treats it as a design constraint that should be reflected in the system architecture: if the agent's reasoning context has limited capacity, then the system should structurally guarantee that only goal-relevant information crosses the boundary into that context. The nested loop is the mechanism that enforces this guarantee—the inner loop absorbs the full page complexity and the outer loop sees only the filtered workspace. This is a different type of solution than any prior IS agent architecture, and it has implications beyond browser-use: any agent that interacts with large, noisy information sources (document databases, code repositories, knowledge graphs) could benefit from a similar decoupling of perception from reasoning with a goal-conditioned filter at the boundary.

Third, it provides concrete evidence that extraction quality is a bottleneck that cannot be compensated by reasoning quality alone. Table 3's demonstration that using a 4B inner-loop model degrades a 30B-A3B outer loop from 35.0% to 24.0% on BrowseComp—a 31% relative drop—is a diagnostic result that challenges the modularity assumption common in agent system design. The engineering instinct to separate perception and reasoning into independently optimized modules, then compose them, is natural. NestBrowse's evidence suggests this instinct is wrong for IS tasks: the two capabilities are sufficiently interdependent that degrading either one substantially harms the other, and joint training under a unified objective produces better composed performance than training them separately (though the paper does not fully prove this claim—see the earlier discussion of the missing separate-training baseline). This finding, if replicated across other model families and task domains, would influence how future IS agents are architected: not as pipelines of specialized modules but as unified models that internalize both exploration and reasoning capabilities.

The paper also partially reconciles a tension in the IS agent literature. Prior work has oscillated between two poles: (1) sophisticated agent architectures with many tools and complex reasoning patterns that achieve strong performance on specific benchmarks but are difficult to replicate, adapt, or scale; and (2) minimalist search-and-visit agents that are simple and reproducible but hit a performance ceiling on tasks requiring genuine web interaction. NestBrowse demonstrates that the tradeoff between simplicity and capability is not inherent—a carefully designed four-tool interface with a nested interaction structure can be both simple (easier to train, easier to replicate, easier to adapt to new models) and capable (competitive with larger proprietary systems on deep IS benchmarks). This resolution, if it holds up under replication, would redirect research effort away from both ever-more-complex tool schemas and ever-larger models with naive interfaces, toward principled interface and interaction design for smaller, trainable models.

What becomes more attractive as a research direction:

Designing interaction abstractions for specific information-access modalities, treating the abstraction itself as a research contribution rather than an engineering afterthought
Joint training of perception and reasoning for agent tasks, rather than modular composition of separately trained components
Small-model agent systems that compete with large models through superior information access rather than through raw reasoning capability
Text-only browser interaction as a practical middle ground between static page fetching and full multimodal GUI automation

What becomes less attractive:

Simply scaling model parameters in search-and-visit agents as a path to better IS performance—NestBrowse-4B outperforms many much larger search-and-visit agents, suggesting diminishing returns to scale without architectural changes
Adding browser actions ad hoc (every new interaction pattern gets a new tool) without a functional completeness criterion—the paper's ablation (Table 2) shows that toolkit simplification alone provides measurable gains (8.7 points on GAIA), suggesting that tool proliferation actively harms performance
Treating the ReAct paradigm's context management as a post-hoc problem—NestBrowse's nested design shows that architectural boundaries between reasoning and perception can structurally solve the context overflow problem rather than merely mitigating it

Follow-Up Research This Work Enables

Stress-testing the functional completeness claim through controlled benchmark subsets. The paper asserts that four tools are functionally complete for web information access but provides no quantitative decomposition of benchmark tasks by required interaction type. A natural follow-up would instrument the evaluation: categorize each question in BrowseComp, GAIA, BrowseComp-zh, and XBench according to whether it requires only $I_{\text{static}}$ access (solvable with search-and-visit), requires form interaction ( $I_{\text{dynamic}}$ via fill), requires navigation interaction ( $I_{\text{dynamic}}$ via click), or requires both. Then measure NestBrowse's accuracy on each category, and compare against a search-and-visit baseline on the same decomposition. If NestBrowse's advantage is concentrated in the fill-and-click categories, the functional completeness claim is directly supported. If the advantage also appears in the static-only category, then other factors (training data quality, base model capability, multi-task objective) are driving the performance gap, and the functional completeness claim should be weakened accordingly. This experiment requires no new models—only a human or LLM annotation of benchmark questions by required interaction type.

Measuring the actual latency cost of the nested design and comparing to truncation baselines. Section 6.4 of this analysis identified the uncharacterized latency-for-context tradeoff as a critical gap. A direct follow-up experiment would: (1) instrument NestBrowse-30B-A3B to record the number of inner-loop forward passes, the total wall-clock time, and the outer-loop turns-to-completion for each benchmark question; (2) implement a family of truncation baselines (truncate each visited page to the first 8K, 16K, 32K, 64K tokens, inject directly into the outer loop without inner-loop processing) and measure their pass@1 accuracy and wall-clock time on the same benchmarks; (3) plot accuracy against latency for both approaches. The paper's Figure 3 implies NestBrowse can solve tasks that truncation cannot (because truncation would either overflow context or discard critical information), but this is not empirically demonstrated. A well-designed truncation baseline—particularly one that preserves the page's first N tokens (which often contain the most salient content) or uses a simple relevance heuristic—might achieve comparable accuracy with substantially lower latency on many tasks, and this experiment would reveal the exact regimes where NestBrowse's full nested design is worth its cost.

Separate-model training baseline to isolate the contribution of joint training. Table 3 shows that a modular composition (GPT-OSS-120B inner loop + NestBrowse-30B-A3B outer loop) achieves 36.0% on the BrowseComp subset, slightly better than the jointly trained NestBrowse-30B-A3B at 35.0%. This is weak evidence that modular composition works, but GPT-OSS-120B is a proprietary model with unknown training and is much larger than the 30B-A3B inner loop. A definitive experiment would: (1) take the same Qwen3-30B-A3B-Thinking-2507 base model; (2) train one copy with the full multi-task objective (the standard NestBrowse-30B-A3B); (3) train a second copy on only the outer-loop objective, using trajectories with oracle (ground-truth) extraction to provide perfect inner-loop supervision; (4) train a third copy (or a smaller model from the same family) on only the inner-loop objective to serve as a dedicated extraction module; (5) compose the separately trained models and compare against the jointly trained one. If the jointly trained model substantially outperforms the composed separate models, joint training is validated as a performance-improving technique rather than merely a practical convenience. If the composed models match or exceed joint training, then the field can safely modularize, using specialized extraction models (which could be much smaller and faster, addressing the latency concern) paired with reasoning models.

Zero-shot domain transfer evaluation to test the portability of NestBrowse-trained browser-use skills. The paper trains exclusively on SailorFog-QA-V2 and evaluates on four QA benchmarks that share a text-answer structure. A realistic deployment scenario would involve structurally different tasks: open-ended research report generation (e.g., "write a report comparing the safety profiles of drug X and drug Y using FDA adverse event data"), structured data extraction (e.g., "populate a spreadsheet with the last 5 years of revenue figures for companies A, B, and C from their investor relations pages"), or temporal monitoring (e.g., "track the price of product X across three retailers daily for a week"). Evaluating NestBrowse zero-shot on any of these task types—without additional training, using only the browser-use and extraction skills acquired from SailorFog-QA-V2—would test whether the framework teaches generalizable browser-use or merely overfits to the QA distribution. The hypothesis to test is that the nested design and extraction training produce a general browser-use capability that transfers across task types; the null hypothesis is that performance degrades substantially on tasks requiring synthesis, comparison, or structured output because these patterns are absent from the training data. A strong negative result (zero-shot failure on non-QA tasks) would motivate developing multi-task training datasets that cover diverse IS task types, not just QA.

Scaling the rejection sampling cost curve to inform replication efforts. The paper reports training compute (1,344 and 4,096 GPU-hours for the 4B and 30B-A3B models) but not the cost of generating and filtering trajectories. For a practitioner seeking to replicate NestBrowse on a new base model or domain, the unknown rejection rate is the primary budget uncertainty. A valuable follow-up would train a NestBrowse model from scratch on a smaller, publicly available base model (e.g., Qwen2.5-7B-Instruct or Llama-3.1-8B-Instruct) while recording: (a) the number of trajectories generated per training question, (b) the rejection rate at each training iteration, (c) the GPU-hours spent on generation vs. training, and (d) the relationship between rejection rate and model capability (does the rejection rate decrease as training progresses, and if so, how quickly?). This would produce a cost curve that other researchers can use to budget replication efforts. Additionally, testing alternative trajectory quality filters—soft filtering (weighting trajectories by a quality score rather than hard-filtering), filtering only on format without correctness, or filtering only on correctness without format—would reveal which rejection criteria contribute most to final model quality and whether less aggressive filtering can reduce generation cost without sacrificing performance.

Practical Applications and Downstream Use Cases

On-device or edge-deployed research assistants using small models. NestBrowse-4B achieves 68.9% on GAIA and 28.4% on BrowseComp-zh despite having only 4 billion parameters. For a deployment scenario where a user needs a research assistant that runs locally (on a laptop or mobile device) to answer complex questions requiring web research, a 4B model is feasible to run while a 1T-parameter model is not. The paper's results suggest that equipping such a small model with NestBrowse's browser-use framework would enable it to answer deep research questions that would be impossible with a search-and-visit interface, because interactive web utilities (calculators, lookup tools, form-based databases) become accessible. The key benefit is enabling complex, multi-source web research on resource-constrained devices without cloud dependency. The 4B model's 74.0% on XBench-2505 further suggests that the approach transfers across languages, making it viable for non-English on-device deployment.

Cost-efficient batch inference for structured data extraction at scale. Organizations that need to extract specific data points from many web pages (e.g., monitoring competitor pricing, aggregating clinical trial results, tracking regulatory filings) face a compute cost challenge: using a large proprietary model for each extraction query is expensive, while using a search-and-visit agent fails when the target data is behind form interfaces or dynamic loading. NestBrowse's nested design is well-suited to this setting because: (1) the four-tool interface is simple enough that a small, cost-efficient model can operate it; (2) the inner loop's goal-conditioned extraction means the outer loop receives structured, relevant data rather than raw pages, reducing downstream processing cost; and (3) the text-only design avoids the computational overhead of visual processing. The GAIA result (75.7% for the 30B-A3B model) on tasks specifically requiring web interaction suggests that a significant fraction of structured data extraction tasks would be solvable. The practical deployment would involve running the NestBrowse-trained model with per-task goals specifying the target data fields, collecting the extracted workspaces, and post-processing them into structured databases—replacing expensive human extraction or brittle web scraping pipelines with an LLM-driven but cost-controlled alternative.

Training data generation for self-improving IS agents. The paper's own training pipeline—generating trajectories on SailorFog-QA-V2, applying rejection sampling, and training on successful trajectories—is a form of self-improvement (the model generates data that is used to train the next iteration of the model). This pipeline could be extended to bootstrap browser-use capabilities in new domains: deploy NestBrowse on a target domain's question set, collect trajectories that pass the rejection filter (correct answers), and use those trajectories to fine-tune the model for domain-specific browser interaction patterns. The benefit is that the initial NestBrowse model provides a strong starting point—it already knows how to use the four browser tools and how to extract goal-relevant content—so domain adaptation requires fewer trajectories and less compute than training from scratch. The practical scenario would be an organization with a specialized web research need (e.g., legal document analysis, scientific literature review, medical guideline synthesis) that collects a few hundred example questions with answers, runs NestBrowse to generate training trajectories, filters for correct completions, and fine-tunes—achieving domain-adapted browser-use without the full cost of the original training pipeline.

When to Prefer This Method

The paper positions NestBrowse against two named alternatives: (1) search-and-visit agents that cannot access dynamic web content, and (2) full browser toolkits that overwhelm agents with action complexity and raw page content. It does not compare against truncation-based context management, separate-model architectures, or vision-based browser agents in a controlled way, so a broader tradeoff matrix is not supported by the paper's own evidence. Based on what the paper does demonstrate, the decision conditions are:

Prefer NestBrowse over search-and-visit agents when the target tasks require accessing information behind interactive barriers—form submission, client-side rendering, multi-step navigation, or online computational utilities—that a static visit call cannot surface. The evidence is the performance gap on BrowseComp (NestBrowse-30B-A3B at 31.6% vs. best search-and-visit open-source agent GLM-4.5-355B at 26.4%) and the case study in Figure 5 demonstrating calculator-based computation that is impossible without fill and click.
Prefer NestBrowse over full browser toolkits (with many actions and raw page injection) when operating under tight context limits (128K tokens or fewer) on tasks requiring sustained multi-turn information gathering. The evidence is Figure 3: the nested design keeps outer-loop context within limits while total processed information exceeds 700K tokens, enabling task completion rates that would be impossible with raw page injection (85% of BrowseComp tasks remain unfinished at the point where a naive approach would overflow). The ablation in Table 2 further supports this: the Simplified toolkit (four actions) outperforms the Naive toolkit (many actions) by 8.7 points on GAIA even without extraction, suggesting action-space simplification alone provides measurable benefit.
Prefer NestBrowse when training small IS agent models (4B-30B parameters) that must compete with much larger systems. The evidence is NestBrowse-4B's 68.9% on GAIA versus Kimi-K2-Instruct-1T's 57.7% and GLM-4.5-355B's 66.0%. The nested design and multi-task training appear to provide sufficient information-access leverage that parametric scale becomes less determinative of performance—making the approach suitable for deployment scenarios where large models are infeasible due to hardware, cost, or latency constraints.