WebSwarm: Recursive Multi-Agent Web Search

• WebSwarm is a recursive multi-agent framework that enables deep-and-wide web search by dynamically delegating tasks among specialized search nodes.
• It addresses single-agent limitations by decomposing queries, facilitating adaptive collaboration, and aggregating evidence across diverse search modes.
• Empirical results demonstrate improved accuracy and efficiency over baseline methods, validating its design for complex web search tasks.

WebSwarm is a progressive recursive delegation framework for deep-and-wide web search in which dynamically instantiated agentic search nodes jointly construct task decomposition, recursive expansion, and agent collaboration during inference. It was proposed to address a specific failure mode of LLM-based web search: a single ReAct-style agent is constrained by one long trajectory and limited context, while earlier multi-agent systems improve search coverage through parallel execution and aggregation but still exhibit limitations in recursive depth, collaboration adaptability, and evidence-grounded expansion. In WebSwarm, each node couples a local objective with a search mode, can either solve locally or delegate child nodes, and returns evidence and results upward so that parent nodes can expand, revise, or aggregate the search process (Song et al., 9 Jul 2026).

1. Problem setting and conceptual scope

WebSwarm is defined around three task classes. Deep search denotes multi-hop, constraint-satisfying reasoning where the entity or answer is not directly named and must be inferred from indirect clues. Wide search denotes broad coverage over many rows, entities, items, or events and their attributes. Deep-and-wide tasks interleave deep inference and wide enumeration, or require deep reasoning to identify the correct entity set and then wide coverage to collect attributes (Song et al., 9 Jul 2026).

The framework is motivated by three orchestration challenges. First, most multi-agent frameworks decompose at the root once and then run subagents that behave like large ReAct agents, so deep substructure is compressed into a single long trajectory inside one subagent. Second, subtasks differ substantially in their collaboration requirements: fact lookup, deep reasoning, wide table filling, and open-ended enumeration are not well served by a single global collaboration pattern. Third, correct expansion should align with how information is actually organized on the web; when decomposition follows only the surface semantics of the query, systems risk over-decomposition of centralized resources or decomposition along the wrong axis for distributed resources (Song et al., 9 Jul 2026).

This framing makes WebSwarm less a fixed hierarchy than an inference-time orchestration policy. A plausible implication is that the central design object is not the individual agent but the evolving delegation tree that determines depth, breadth, and evidence flow as search proceeds.

2. Delegation tree and node semantics

The fundamental unit in WebSwarm is the agentic search node. For each node $v$, the system maintains a local objective $q_v$, a search mode $$m_v \in \{\text{atom}, \text{deep}, \text{wide}, \text{entity\_collect}\}$$, accumulated child results $R_v$, and optionally a web-structure hint $h_v$ and experience $k_v$. The nodes form a dynamically constructed recursive delegation tree $\mathcal{T} = (\mathcal{V}, \mathcal{E})$, rooted at $v_0$ with the original user query $q_0$ (Song et al., 9 Jul 2026).

Delegation is defined by a child set

$C_v = \{ (q_i, m_i) \}_{i=1}^{n_v},$

where each pair instantiates a new child node. When a child finishes, the parent updates

$q_v$0

and when the parent deems its objective satisfied it returns

$q_v$1

There is no explicit numeric reward or scoring function in the formulation; decisions such as whether to deepen, broaden, or aggregate are implemented through LLM reasoning via routines such as Ready(q_v, R_v) and SolveOrDelegate(q_v, m_v, R_v, h_v, k) (Song et al., 9 Jul 2026).

The inference procedure is organized around SolveNode(v, k). A node initializes $q_v$2 and a local trajectory $q_v$3, probes the web structure when needed, either solves locally or emits child delegations, optionally runs scouts to extract process-level experience, executes remaining children with that shared experience, and returns the aggregate result and trajectory once Ready holds. The root orchestrator is itself a special node that receives the user query, chooses a mode for top-level subtasks through solve_subtask, and finally emits submit_answer (Song et al., 9 Jul 2026).

Architecturally, this yields progressive and evidence-driven construction. What nodes exist, how many of them are instantiated, and how they collaborate are not hard-coded up front; they emerge during search as evidence accumulates.

3. Search modes, web probing, and sibling experience

WebSwarm defines four search modes, each tied to a distinct collaboration pattern.

Mode	Function	Typical collaboration pattern
atom	atomic fact lookup	short ReAct-style search and page browsing
deep	iterative search and verification	searchers plus verifiers as child atom nodes
wide	parallel divide-and-conquer	expansion along an axis, then aggregation
entity_collect	multi-path recall and verification	multiple recall paths, merge, deduplicate, verify

In atom, the node directly uses the web tools for focused retrieval or verification. In deep, the parent coordinates multiple rounds of hypothesis generation and checking: searcher nodes follow different clue paths, and verifier nodes independently check whether a candidate satisfies all constraints. In wide, the parent determines an expansion axis and spawns many children, which can themselves be atom, deep, wide, or entity_collect nodes. In entity_collect, the set itself is unknown, so the node dispatches multiple child paths to enumerate candidates, merges and deduplicates them, and may verify low-confidence cases (Song et al., 9 Jul 2026).

A distinctive mechanism is web probing. Before a wide-style expansion, a dedicated Web-Probing Agent performs quick search and browsing to determine whether the relevant information topology is centralized, centralized_with_gaps, or distributed. If it is distributed, the probe also recommends an organization dimension such as tour, brand, program, or country. Formally,

$q_v$4

and delegation is then conditioned on $q_v$5. This causes the tree structure to reflect how information is actually organized online rather than how the original query happened to be phrased (Song et al., 9 Jul 2026).

A second distinctive mechanism is within-instance process-level experience sharing across homogeneous siblings. From a batch of child delegations, WebSwarm selects a small scout subset $q_v$6, executes those children, and summarizes process advice from their trajectories: $q_v$7 The extracted experience is then injected into the remaining siblings: $q_v$8 The experience is explicitly process-level rather than factual answer content; examples in the evaluation include guidance such as using official brand sites and avoiding third-party shopping sites. This preserves within-task coordination without introducing cross-task memory (Song et al., 9 Jul 2026).

The tool layer is deliberately narrow. All methods in the evaluation use the same two tools: a Web-Search tool based on Serper, which returns top-5 search results with titles, URLs, snippets, and metadata, and a Page-Browse tool based on Jina Reader, which returns Markdown content up to approximately 80K tokens. Because each node reasons over a localized objective and a localized evidence set, recursive decomposition converts context limitations into a structuring constraint rather than a pure bottleneck (Song et al., 9 Jul 2026).

4. Evaluation and empirical profile

WebSwarm was evaluated on BrowseComp-Plus, WideSearch, DeepWideSearch, and GISA, with GLM-4.5 as the main backbone and additional tests on Qwen3-32B, Qwen3.5-35B, Kimi-K2-Thinking, and Qwen3-235B. The comparison set included the single-agent ReAct baseline and the multi-agent systems Swarm-Agent, Flash-Searcher, Table-as-Search, InfoSeeker, and ROMA; all methods used the same Serper search and Jina Reader page-browse tools, with a maximum of 200 tool-action steps per agent (Song et al., 9 Jul 2026).

Benchmark	ReAct	Best baseline	WebSwarm
BrowseComp-Plus (ACC)	50.50	64.50	68.00
WideSearch-EN (Item F1 / Row F1 / SR)	64.61 / 33.23 / 4.00	71.91 / 39.98 / —	74.37 / 44.14 / 7.00
DeepWideSearch-EN (Item F1 / Row F1 / SR)	46.63 / 20.08 / 3.95	55.10 / 25.81 / —	58.40 / 29.64 / 6.58
GISA Overall	55.54	58.99	62.30

The reported gains are largest in hard deep and deep-wide settings. On BrowseComp-Plus, WebSwarm’s deep mode combines searchers and verifiers, leading to more exhaustive clue exploration and independent constraint checking. On WideSearch, the recursive pattern entity_collect → wide → atom, combined with web probing and experience sharing, improves table completeness and row correctness. On DeepWideSearch, the ability to interleave deep and wide subtrees allows the framework to resolve hidden entities and then perform structured table filling under the same orchestration regime (Song et al., 9 Jul 2026).

Ablation results isolate three central mechanisms. Removing recursion, so that only the root can delegate, reduces performance from 68.00 to 63.50 on BrowseComp-Plus, from 74.37 to 68.38 on WideSearch Item F1, and from 58.40 to 55.79 on DeepWideSearch Item F1. Forcing all non-atom nodes to wide preserves some wide-task performance but hurts deep tasks; forcing all non-atom nodes to deep almost preserves deep performance but degrades wide tasks. The paper interprets this as direct evidence that recursive depth and per-subtask mode adaptivity are both necessary (Song et al., 9 Jul 2026).

The efficiency analysis separates quality gains from tool-use savings. Removing Web-Probing leaves Item F1 approximately unchanged on WideSearch and DeepWideSearch but increases web tool calls from 137.03 to 239.90 and from 203.73 to 331.39, respectively. Removing experience reuse decreases WideSearch Item F1 from 74.37 to 71.20 and DeepWideSearch Item F1 from 58.40 to 55.48. The pattern is therefore asymmetric: probing primarily improves efficiency, whereas sibling experience primarily improves accuracy and consistency (Song et al., 9 Jul 2026).

The model-generalization study shows that the orchestration gains are not tied to one backbone. For Qwen3-32B on BrowseComp-Plus, accuracy rises from 12.00 with ReAct to 19.50 with WebSwarm. For Qwen3.5-35B on WideSearch, Item F1 and Row F1 rise from 64.82 and 37.38 to 75.91 and 47.54. This suggests that WebSwarm operates as a backbone-agnostic inference scaffold rather than as a model-specific prompt recipe (Song et al., 9 Jul 2026).

5. Relation to broader swarm architectures on the web

Although WebSwarm is a named framework for recursive multi-agent web search, adjacent literature uses the term in a broader, interpretive sense for web-scale swarm orchestration. This suggests a wider design family in which global coordination, local specialization, and selective decentralization are combined rather than treated as mutually exclusive.

In cloud-edge robotics, HiveMind provides a cloud-centric but edge-aware swarm coordination design that was explicitly described as mapping naturally to a web/serverless “WebSwarm” system. Its division of labor places motion control, obstacle avoidance, and lightweight approximate perception on the UAVs, while a centralized controller and OpenWhisk-based serverless backend handle global visibility, work partitioning, dynamic load rebalancing, image recognition, face-based disambiguation, and continuous model retraining. The same line of work later extended HiveMind into a hardware-software stack with a DSL, program synthesis for task placement, a centralized controller integrated with serverless, and a reconfigurable FPGA fabric for network and remote-memory acceleration (Hu et al., 2020, Patterson et al., 2021).

In decentralized compute and agent networks, SwarmHarness describes a fully decentralized, incentive-aligned protocol that was also interpreted as a WebSwarm. Its architecture comprises a DHT-based SwarmRegistry for peer discovery and capability advertisement, a utility-based SwarmRouter that dispatches tasks using capability, load, latency, and trust, and SwarmCredit, a Shapley-value-based incentive layer that updates both credit and trust. The formal node model

$q_v$9

makes the contrast with WebSwarm in the search sense especially clear: instead of recursively delegating reasoning subproblems, the system self-organizes task routing across autonomous nodes without any central authority (Jose, 27 May 2026).

A different systems lineage comes from swarm management and measurement for BitTorrent. A framework for automated swarm creation and control introduced a Commander–Server architecture, instrumented clients that emit periodic status information and verbose protocol logs, a database-backed analysis pipeline, and an explicit future-work item to add a web-based interface to the Commander. In effect, it supplies a control plane, data plane, and analysis plane for a web-based platform to create, manage, and analyze swarms, although not under the proper name WebSwarm (Deaconescu et al., 2011).

In large-scale content distribution, ByteDance’s Swarm offers yet another neighboring design: a centralized tracker cluster controls a decentralized data plane of peer servers, with a client-side library implementing multipath parallel transmission, startup via CDN, and fallback to CDN when P2P quality degrades. The system operates at over a hundred thousand peer servers and nearly a hundred million users daily, and the paper explicitly frames it as a blend of a centralized control plane with a decentralized data plane (Wei et al., 2024).

Taken together, these systems indicate that “WebSwarm” can denote either a specific recursive search framework or, more broadly, a class of architectures in which web-scale coordination emerges from structured interaction among many specialized nodes. The unifying pattern is not one particular transport or control regime, but a shared concern with balancing global orchestration against local autonomy.

6. Limitations and research directions

WebSwarm, in its named 2026 formulation, is an inference-only orchestration framework. It does not learn delegation policies, search-mode assignments, or cooperation strategies during training; all such decisions depend on the base LLM’s reasoning at inference time. As a result, a weaker model may misdelegate, assign the wrong mode, or misread the web topology returned by the probe agent (Song et al., 9 Jul 2026).

The framework also increases resource cost and latency relative to a single-agent searcher. Multi-agent orchestration naturally increases LLM calls and web-tool requests, and even though Web-Probing reduces unnecessary tool usage, the overall system remains more expensive than a single ReAct agent. The implementation is designed for text-based search and browse tools and does not explicitly handle multimodal web content, video, images, or GUI interaction. The paper also notes potential additional concerns such as robustness to noisy search results and the operational complexity of maintaining several specialized prompts for the root agent, web probing, and experience extraction (Song et al., 9 Jul 2026).

The principal future directions identified for the framework are multi-agent training, multimodal and GUI-capable web interaction, learning reusable skills across tasks rather than only within-task experience sharing, and better cost-control policies that decide how many nodes to spawn and how deep to search under explicit cost or latency constraints (Song et al., 9 Jul 2026).

In the broader systems interpretation of WebSwarm, additional open problems recur across the related literature: real-time guarantees and network QoS in cloud-edge swarms, security and privacy for uploaded sensor data or peer communication, multi-tenant operation, adaptive networking under intermittent connectivity, Byzantine robustness for decentralized compute swarms, and the valuation of internal credit or reputation systems. This suggests that the future of WebSwarm, whether as recursive search orchestration or as web-scale swarm infrastructure, lies in integrating richer coordination policies with stronger resource, trust, and systems guarantees.