Paper deep dive
Search, Inspect, Fetch: Exploiting Boolean Retrieval for Deep-Research Agents
Shuai Wang, Haodong Chen, Yu Yin, Shengyao Zhuang, Bevan Koopman, Guido Zuccon
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 8/5/2026, 4:28:29 AM
Summary
The paper introduces SIEVE, a deep-research agent framework that utilizes a Search-Inspect-Fetch workflow driven by Boolean Query Language (BQL). Unlike conventional Search-Visit agents that retrieve and read entire web pages, SIEVE uses fielded Boolean retrieval to filter eligible documents, ranks them, presents structure-rich result cards for inspection, and fetches only specific sections. This approach improves accuracy while reducing token usage by 20.7-50.6% across three QA collections (BCP-S, HotpotQA, MuSiQue).
Entities (10)
Relation Signals (9)
SIEVE → evaluatedon → HotpotQA
confidence 95% · Across three QA collections... HotpotQA
SIEVE → evaluatedon → BrowseComp-Plus
confidence 95% · Across three QA collections... BROWSECOMP-PLUS
SIEVE → evaluatedon → MuSiQue
confidence 95% · Across three QA collections... MuSiQue
SIEVE → uses → Boolean Query Language (BQL)
confidence 95% · SIEVE, a search-inspect-fetch strategy built around a Boolean Query Language (BQL).
SIEVE → outperforms → Search-Visit
confidence 92% · SIEVE achieves higher accuracy than the most accurate conventional Search-Visit configuration
SIEVE → implements → SkimSearchAgent
confidence 90% · Our implementation is included in the SkimSearchAgent library
SIEVE → reduces → Token usage
confidence 90% · using 20.7-50.6% fewer tokens
SIEVE → usesranker → BM25
confidence 90% · SIEVE’s default R combines BM25 scores
SIEVE → usesranker → BAAI/bge-base-en-v1.5
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Existing deep-research agents use a search-visit workflow that retrieves and reads whole pages, without considering the addressable structure that web sources expose through titles, headings, sections, and metadata. This prevents agents from directly constraining retrieval to document fields and often carries irrelevant page content into their context. We introduce SIEVE, a search-inspect-fetch interface driven by fielded Boolean retrieval (BQL). SIEVE filters candidates over document fields, ranks the admitted set, presents structure-rich result cards for inspection, and fetches only selected sections. Across three QA collections, SIEVE achieves higher accuracy than the most accurate conventional Search-Visit configuration on each collection while using 20.7-50.6% fewer tokens. Further analyses show that BQL filtering improves all tested rankers and that the accuracy-context advantage persists across retriever choices and agent backbones. Code and data are available at this https URL.
Tags
Links
- Source: https://arxiv.org/abs/2608.02751v1
- Canonical: https://arxiv.org/abs/2608.02751v1
Trouble viewing inline? Open PDF directly →
Full Text
92,535 characters extracted from source content.
Expand or collapse full text
Search, Inspect, Fetch: Exploiting Boolean Retrieval for Deep-Research Agents Shuai Wang 1 Haodong Chen 1 Yu Yin 1 Shengyao Zhuang 1 Bevan Koopman 2 Guido Zuccon 1 1 The University of Queensland, Brisbane, Australia 2 CSIRO, Brisbane, Australia shuai.wang2, y.yin1, s.zhuang, g.zuccon@uq.edu.au haodong.chen1@student.uq.edu.au bevan.koopman@csiro.au Abstract Existing deep-research agents typically search for web pages, inspect short result snippets, and visit selected pages in full. This Search–Visit workflow ignores the ad- dressable structure that web sources expose through titles, headings, sections, and metadata. Consequently, agents cannot constrain retrieval to document fields or avoid car- rying irrelevant sections into their context. We introduce SIEVE, a search–inspect–fetch strategy built around a Boolean Query Language (BQL). BQL constraints define which documents are eligible, an interchangeable ranker orders them, structure-rich result cards support inspection, and fetch returns only selected sections. Across three QA collections, SIEVE is more accurate than the strongest conventional Search–Visit configuration on each collec- tion while using20.7–50.6%fewer tokens. Adding BQL candidate selection improves accuracy with every tested ranker, and the accuracy–context advantage persists across retriever choices and agent backbones. Our imple- mentation is included in the SkimSearchAgent library at https://github.com/ielab/skim-search-agent. 1 Introduction Deep-research agents answer difficult questions by alter- nating search and reading. At each iteration, an agent formulates a subquery, inspects a ranked list of short page snippets, visits selected pages, and uses the resulting ev- idence either to answer or to formulate the next query. Unlike single-pass retrieval, this Search–Visit loop lets the search evolve as evidence accumulates (Tongyi Deep- Research Team et al., 2025; Li et al., 2025b; Chen et al., 2026). Yet reading remains page-level: after choosing a result from its short representation, the agent receives the complete page even when only one section is relevant. 102030405060 25 30 35 40 45 BCP-S HotpotQA MuSiQue Distinct tokens per question (thousands) Accuracy (%) BM25 Search–Visit SIEVE Figure 1: Higher and farther left is better. Accuracy is the judge verdict on BROWSECOMP-PLUS-STRUCTURED (BCP-S) and exact match on HotpotQA and MuSiQue. Relative to BM25 Search–Visit, SIEVE has higher ob- served accuracy while reading30.4–50.6%fewer distinct tokens. Page-level reading is a poor match for how web sources are organized. HTML commonly exposes titles, head- ings, sections, dates, authors, and other fields that can be parsed directly. Current agent workflows may display some of these cues, but they do not let the agent use doc- ument structure to control both retrieval and reading. We argue that structure should be preserved throughout the research process. An agent should search document fields to identify eligible sources, inspect their structure to lo- cate relevant sections, and fetch only the content needed. We call this strategy search–inspect–fetch. Making structure actionable requires retrieval to do more than rank pages. The agent must also define which documents are eligible for inspection. A question may require terms in particular fields, a date within a specified range, or the absence of an unwanted concept. A ranker can prefer sources with these properties, but cannot guar- antee that every result satisfies them. Fielded Boolean retrieval was designed for this selec- 1 arXiv:2608.02751v1 [cs.IR] 3 Aug 2026 tion problem. It composes exact constraints over doc- ument fields to produce an eligible set, after which a lexical or dense ranker can order the remaining docu- ments. Boolean selection therefore determines what may be considered, while ranking determines what should be inspected first. This division also keeps ranking modular: the same Boolean-selected set can be ordered by BM25, a dense retriever, or a fusion of both. Consider an agent looking for government heatwave plans published after 2020 that recommend school clo- sures but are not workplace-safety guidance. During search, it can require “heatwave plan” in the title, “school closure” anywhere in the section field, a qualifying date, and the absence of “workplace safety” from the title. The returned result cards expose the actual section headings of each matching document. The agent inspects those headings and fetches a named section only after seeing which sections the document contains; it does not guess a section name during search. Fielded Boolean queries remain central to professional search, including medical systematic reviews (Wang et al., 2023a,b, 2025, 2026). A longstanding barrier, however, is the effort and specialist knowledge required to formu- late and revise them. Language-model agents change this trade-off. They can construct compositional queries from a user’s question, inspect the returned evidence, and revise the constraints during the research loop. The con- straints remain explicit, while the agent takes on much of the formulation work. We instantiate this idea in Sieve. During search, the agent formulates a Boolean Query Language (BQL) ex- pression that selects eligible documents over their fields. An interchangeable ranker then orders the selected set. During inspection, compact result cards expose titles, section headings, and query-focused snippets. During fetching, the agent requests a named section rather than opening the complete document. Structure is therefore preserved across all three actions rather than discarded between retrieval and reading. Appendices B.1– B.3 de- scribe the language, agent instructions, issued queries, and a complete logged interaction. Existing QA collections do not directly support this comparison because they do not provide controlled access to document structure. We therefore derive paired flat and structured variants of BrowseComp-Plus, HotpotQA, and MuSiQue. Within each pair, the questions and emit- ted text are identical; the flat variant hides section and metadata fields, whereas the structured variant makes them explicitly addressable. This design tests access to structure without changing the evidence available to the agent. Across agent strategies and ranker choices, SIEVE achieves the highest accuracy on all three collections. Its default BM25+Dense configuration improves over the most accurate Search–Visit configuration by1.6/3.1/0.7 accuracy points while using20.7–50.6%fewer tokens. Matched Search–Fetch controls show that BQL candi- date selection improves all nine ranker–collection pairs. Further analyses show that query-focused snippets make section-level inspection effective and that the gains persist across retrievers and three agent backbones. Contributions. This work makes three contributions. First, we identify the mismatch between structured web sources and page-level Search–Visit workflows, and for- mulate search–inspect–fetch as a strategy for preserving structure from retrieval through reading. Second, we introduce SIEVE, which combines fielded Boolean can- didate selection, interchangeable ranking, structure-rich result inspection, and selective section fetching. Third, we show that SIEVE improves accuracy while reading 20.7–50.6%fewer tokens than the strongest conventional Search–Visit configuration on each collection. Matched analyses further identify the roles of BQL selection and query-focused snippets and show that the gains persist across retrievers and agent backbones. 2 Related Work SIEVE builds on three areas: iterative retrieval for re- search agents, Boolean query formulation, and retrieval over document structure. Retrieval workflows for research agents. Deep- research agents commonly use a ReAct-style loop (Yao et al., 2023): keyword or dense search returns a top-k list, after which the agent opens a page (Nakano et al., 2021; Jin et al., 2025; Li et al., 2025a; Song et al., 2025; Sun et al., 2025; Gao et al., 2025). QA systems improve planning, memory, and evidence aggregation (Trivedi et al., 2023; Gutiérrez et al., 2024, 2025), but generally retain this Search–Visit workflow. DCI instead removes the retriever and lets an agent search raw files directly (Li et al., 2026b; Subramanian et al., 2025), reporting cost advantages under cached reads and aggregate pricing assumptions. RISE uses BM25 to bound the corpus in which an agent performs such direct interaction (Zhuang et al., 2026). We instead ask whether preserving doc- ument structure from search through reading improves efficiency without sacrificing effectiveness. 2 Booleansearchandagent-generatedqueries. Boolean retrieval expresses precise inclusion and exclu- sion criteria over structured records. Field restrictions distinguish a term in a title from the same term in the body; Boolean operators combine constraints; and phrases, wildcards, and ranges refine the candidate set. These capabilities remain important in specialist search, particularly biomedical systematic reviews (Wang et al., 2023a,b, 2025, 2026). This line of work shows both why fielded Boolean queries remain useful and why their formulation is difficult: controlled terminologies can improve retrieval, while query effectiveness depends strongly on the generating model, prompt, and validation procedure.Once a Boolean query has selected a candidate pool, a separate ranker can prioritize the documents within it (Wang et al., 2023c). This separation between selection and ranking is also central to SIEVE. Earlier retrieval models combined exact selection with graded evidence and field-sensitive ranking (Turtle and Croft, 1991; Metzler and Croft, 2004; Robertson et al., 2004). Most directly, Clarke and Smucker (2026) equip an LLM-based agent with a Boolean retrieval engine over MS MARCO segments and obtain strong first-stage retrieval effectiveness using only substring-match density. Their work supports Boolean retrieval as an agent tool, but studies segment ranking rather than structured web sources or the downstream search–inspect–fetch interac- tion. SIRA compiles an answer sketch into a weighted BM25 query (Yang et al., 2026), while LogicalRAG generates Boolean queries within a multi-turn loop (Zeng et al., 2026). Both still return whole documents. SIEVE instead connects fielded candidate selection to result inspection and selective reading. Structure and retrieval granularity.Focused retrieval has long targeted passages or document components (Callan, 1994; Trotman and Sigurbjörnsson, 2005). More recent systems vary dense indexing granularity (Chen et al., 2024) or construct hierarchies over otherwise un- structured text (Sarthi et al., 2024). SIEVE instead uses structure already available in the collection: fielded con- straints construct a candidate set, a separate ranker orders it, result listings expose matching sections, and the read action retrieves a selected section. We ask whether carry- ing document structure through this complete interaction improves both answer quality and context efficiency. Ap- pendix C.4 additionally compares the proposed executor with an Indri-style structured-retrieval alternative while holding result cards and reading fixed. 3SIEVE: Search–Inspect–Fetch SIEVE follows one design principle: document structure should survive the complete interaction, from retrieval to reading. If search can identify a relevant section but the result list discards that information, or if the subsequent read still returns the whole page, the structure provides lit- tle practical benefit. We therefore separate four decisions that conventional Search–Visit workflows often collapse: which documents qualify, how they are ranked, what the agent sees before reading, and which content enters its context (Figure 2). Operationally, one turn moves from a BQL query to ranked result cards and then to a selected section; the evidence returned from that section informs the next turn. Structured source representation. We represent a sourcedby its metadatam d and an ordered sequence of heading–content pairs: d = m d ,⟨(h d,j ,x d,j )⟩ n d j=1 .(1) A conventional visit returns the concatenated pagex d = x d,1 ⊕·⊕ x d,n d , whereas a section fetch returns one selectedx d,j . The representation preserves the emitted document text while separating titles, headings, section bodies, and available metadata. Which fields are address- able depends on the collection and operation: search uses indexed fields, while result cards and fetch may expose additional metadata such as infoboxes. Appendix A gives the exact representation of each collection. The difference is not whether a heading remains visible in the text, but whether the tools let the agent act on it. In a flat record, the agent cannot restrict a query to that heading or name its section as a fetch target. This distinction motivates both the paired collections in §4 and the complete-system comparison. Search: Boolean selection followed by ranking.The agent submits a BQL expression that can combine terms withAND,OR, andNOT; restrict terms to fields; use phrases and wildcards; and filter date ranges. Its purpose is to control eligibility, not to replace ranking. For a collection D and BQL expression q, the search result is C q =d∈D : d|= q, L q = TopK d∈C q R(d,q + ), (2) whereq + denotes the positive query terms andRis an interchangeable ranker. This separation is important: 3 Figure 2: Conventional Search–Visit and SIEVE use the same research agent and can use the same ranker. SIEVE instead changes how the agent accesses the collection, inspects results, and selects content to read. Boolean constraints express which sources are accept- able, while ranking decides which acceptable sources the agent should inspect first. The BQL expression compiles to a Lucene filter that constructsC q . SIEVE’s defaultRcombines BM25 scores over positive title and body terms with dense scores from BAAI/bge-base-en-v1.5 using reciprocal rank fu- sion (Robertson and Zaragoza, 2009; Xiao et al., 2024; Cormack et al., 2009). Lexical and semantic scores pro- vide complementary orderings within the constrained set (Wang et al., 2021). The ranking stage remains modular: our controlled variants use BM25 or dense ranking alone, and no ranker can reintroduce a document rejected by the Boolean filter. Exact constraints are useful only if an over-constrained query can recover. If the filter admits no documents, the system removes the Boolean constraints and ranks the full collection using the query’s positive terms. The fallback is invoked only after a zero-result query and never broad- ens a non-empty candidate set. It occurs in36.8–53.7% of SIEVE’s search calls, reflecting how often agents rely on lexical recovery after an exact query returns nothing. The fallback uses a separate BM25 implementation from the Lucene scorer used for ordinary ranked retrieval; Ap- pendix C.4 quantifies their divergence. Together, precise selection and recovery let the agent test a constrained hypothesis, obtain evidence when it is too restrictive, and reformulate the next query. Appendices B.1, B.3, and C.4 give the grammar, issued queries, compilation, and fall- back details. Inspect: structure-rich result cards. A ranked list alone does not tell the agent why a source matched or which part is worth reading; returning the document body would remove the intended efficiency benefit. The top kdocuments are therefore rendered as compact result cards. Each card identifies the source by title, exposes section headings as possible reading targets, and includes a25-token query-focused snippet as local relevance ev- idence. To produce this snippet, the renderer removes Boolean operators and field syntax, scores candidate pas- sages by lexical overlap with the remaining positive terms, selects the highest-scoring passage, and truncates it to25 whitespace-delimited tokens. Cards also expose matched fields and available infobox keys. The snippet ablation changes only this representation: candidate selection, ranking, and reading remain fixed. Fetch: selective reading.The headings exposed during inspection become actionable through the fetch opera- tion. The agent chooses a listed document and requests one of its named sections or fields; the tool returns the correspondingx d,j rather than the concatenatedx d . The agent may alternate search, inspection, and fetching until it can answer or reaches the common interaction budget described in §4.1. Fetch and visit share the same per-read token ceiling, so this comparison changes reading gran- ularity rather than the maximum content available from one action. Appendix B.3.2 traces one complete logged interaction. The complete SIEVE strategy therefore combines Boolean candidate selection, modular ranking, structure- rich result cards, and section-level fetching. Each com- 4 ponent resolves a different decision in the interaction: Boolean search controls admissibility, ranking priori- tizes candidates, cards support the decision to read, and fetch limits the resulting context. Our default uses BM25+Dense ranking. We evaluate the complete strategy as the primary method and hold the surrounding interac- tion fixed when ablating individual components. 4 Evaluation Our evaluation first compares the complete search– inspect–fetch strategy with conventional Search–Visit. We then test the role of its components, sensitivity to the retriever and agent backbone, where the system fails, and how agents use the Boolean language in practice. Controlled collections. Existing QA benchmarks do not isolate access to document structure. We therefore derive paired flat and structured versions of HotpotQA (Yang et al., 2018b), MuSiQue (Trivedi et al., 2022), and BROWSECOMP-PLUS (Chen et al., 2026). Within each pair, the questions, documents, and emitted text are identical. The flat version exposes title and body, whereas the structured version additionally makes sections and available metadata explicitly addressable. The collections increase in difficulty and source com- plexity. HotpotQA is the more tractable Wikipedia multi- hop setting; MuSiQue requires more connected composi- tion; and BCP-S poses difficult deep-research questions over a much larger, heterogeneous web collection. We discuss results in this order. We report exact match on the Wikipedia collections and LLM-judge accuracy on BCP-S, so accuracy should be compared within rather than across collections. For HotpotQA and MuSiQue, no model-based segmen- tation is needed. The Structured Wikipedia release (Wiki- media Enterprise, Wikimedia Foundation, 2026) already provides sections and infoboxes. We match benchmark titles to this collection and remove unmatched articles and questions left without gold evidence. This retains 7,343/7,405HotpotQA and2,409/2,417MuSiQue ques- tions. Appendix A gives the full preprocessing procedure. BROWSECOMP-PLUS contains100,195documents and830questions but does not provide addressable section annotations.We therefore use OpenAI’s gpt-5.5-nanoonce to propose section headings and boundaries. A deterministic procedure applies these boundaries without rewriting the document body. Both variants contain the full collection and emit identical text, and every experimental condition searches the same doc- uments. Appendix A reports the full construction proce- dure and section-quality audit. Why pair the collections? The paired design changes whether agents can act on document structure while hold- ing the content fixed. It does not remove every structural cue: headings remain visible in flat text, and the read tool can recover sections from many flat pages. The contrast therefore measures the value of exposing structure as ad- dressable fields. The complete-system comparison asks the broader question of whether SIEVE improves deep research over conventional Search–Visit. 4.1 Experimental Setup 4.1.1 Baseline Systems The baselines are organized around two decisions: whether retrieval is repeated and how much content en- ters the agent’s context after each search. Together with the matched no-BQL control, they separate the value of iteration, selective reading, and BQL candidate selection instead of attributing every difference to the complete system. The one-shot retrieve-then-read baselines perform one retrieval and pass its results to one answering call. Search–AutoRead retains an agent loop but returns full document text with each search result, without a separate reading action. We run both with BM25 and dense re- trieval. The conventional Search–Visit baseline instead lets the agent search repeatedly, inspect compact results, and open selected documents in full. Search–Fetch retains iterative, unfiltered search but replaces whole-document visits with section fetches. It is the closest no-Boolean control for SIEVE: both use the same rankers, top-kresult depth, and section-level reading, while SIEVE adds BQL candidate selection. We run Search–Visit, Search–Fetch, and SIEVE with BM25, dense, and BM25+Dense ranking. These matched Search– Fetch comparisons are especially important because their differences cannot be attributed to the ranker, result depth, or reading granularity. DCI gives the agent shell search and file-reading tools over the shared experimental corpus (Li et al., 2026b). BM25-bounded DCI first stages a fixed working set of ten retrieved documents and exposes the same tools within the set, following RISE (Zhuang et al., 2026). Appendix C.3 documents these reimplementations and their differences from the published setups; Appendix B.2 maps each condition to its instructions and reproduces the Search–Fetch manual. 5 4.1.2 Models and Retrieval Agent backbones. The primary agent is Tongyi- DeepResearch-30B-A3B (Tongyi DeepResearch Team et al., 2025), served with vLLM (Kwon et al., 2023) in its released ReAct scaffold. We preserve that scaffold and vary only the collection-access tools and their condition- specific instructions. The agent-backbone study addition- ally uses Qwen-AgentWorld-35B-A3B (Zuo et al., 2026) and OpenResearcher-30B-A3B (Li et al., 2026a). Every generation uses temperature0.6and seed42. Serving details are in Appendix C.1. Retrievers. Sparse retrieval uses Pyserini/Lucene BM25 (Lin et al., 2021; Yang et al., 2018a); dense re- trieval uses exact inner-product search with BAAI/bge- base-en-v1.5, and BM25+Dense combines the two rank- ings by reciprocal rank fusion (Cormack et al., 2009). In SIEVE, each ranker operates only on the BQL-admitted candidate set. To test retriever sensitivity, we replace only SIEVE’s dense channel with the small, base, and large bge-en-v1.5 models (Xiao et al., 2024), and Qwen3- Embedding-0.6B, 4B, and 8B (Zhang et al., 2025), while holding all other components and hyperparameters fixed. 4.1.3 Evaluation Protocol Budgets.Every search call returns at mostk=5results, every read has a12,000-token ceiling, and every iterative condition has a maximum of100agent steps. The ten- document DCI working set is a one-time staging depth and is separate from the per-callkused by search agents. Metrics.We use the standard accuracy metric for each collection. On BCP-S, accuracy is the verdict from Ope- nAI’sgpt-4o-minijudge; on HotpotQA and MuSiQue, it is SQuAD-style exact match.We refer to these benchmark-specific measures collectively as accuracy. Tok. is the mean total number of input and output tokens used to answer a question, without recounting earlier con- versation history at later calls; LLM calls is the mean number of model invocations. Appendix D.4 also re- ports step-summed tokens, which recount the growing conversation history at every call. The primary token measure captures how much distinct content the strat- egy introduces, while the step-summed measure better reflects serving work when the full conversation is pro- cessed again. Reporting both prevents a reduction caused only by one accounting convention. Significance testing. All accuracy comparisons are paired on identical questions. We use exact McNemar tests for binary outcomes and pairedt-tests for tokens and calls, two-sided at α=0.05, with Bonferroni correction. Implementation. Our implementation of SIEVE, in- cluding the BQL executor, search and reading tools, col- lection builders, and evaluation harness, is included in the SkimSearchAgent library athttps://github.com /ielab/skim-search-agent. 5 Results Table 1 presents the full system comparison. We first ask whether SIEVE improves the accuracy–context trade- off over conventional Search–Visit, then use the remain- ing systems to identify where that improvement comes from. Complete per-collection metrics are reported in Appendix D.4. 5.1 Accuracy and Context Efficiency SIEVE improves accuracy without paying for that im- provement with more context. Its default BM25+Dense configuration is more accurate than BM25 Search–Visit on all three collections while reading30.4–50.6%fewer tokens. This pattern also holds against the most accurate Search–Visit configuration on each collection, despite the strongest ranker changing across collections: SIEVE remains more accurate while using20.7–50.6%fewer tokens. The gains over BM25 Search–Visit are signifi- cant on HotpotQA and MuSiQue. On BCP-S, both judge accuracy and strict exact match improve. The reduction comes from controlling what enters the context, rather than curtailing the search. SIEVE makes more model calls on the Wikipedia collections and a similar number on BCP-S, but reads substantially less text overall. Section-level fetching lets the agent continue following an evidence chain without repeatedly carrying complete pages into later decisions. Step-summed token accounting leads to the same conclusion (Appendix D.4). The number of calls alone is therefore a poor proxy for context cost: SIEVE can take an additional search or fetch step while keeping each step focused on a much smaller portion of the collection. Figure 3 tests whether this aggregate saving is driven by a few unusually long pages. SIEVE reads less for roughly two-thirds of the BCP-S questions, and accuracy gains outnumber losses among questions whose judge ver- dict changes. The improvement is therefore distributed 6 Table 1: Main system comparison. Acc. is exact match on HotpotQA and MuSiQue and the LLM-judge on BCP-S; Tok. and LLM calls report mean context use and model invocations per question. BQL-filtered ranks only BQL-admitted documents. Bold marks the best iterative-system value in each column. Full metrics are in Appendix D.4. HotpotQAMuSiQueBCP-S ConditionAcc.Tok.LLM callsAcc.Tok.LLM callsAcc.Tok.LLM calls One-shot retrieve-then-read BM2529.91k1.0 7.82k1.02.22k1.0 Dense30.31k1.011.01k1.06.92k1.0 Iterative Search–AutoRead BM2542.472k36.8 20.9108k78.313.6142k85.4 Dense39.962k35.820.595k71.213.0122k76.3 Direct corpus interaction DCI (no retriever)42.835k21.826.963k39.422.2107k53.6 BM25-bounded DCI (RISE-style)42.621k22.126.347k39.633.475k64.0 Iterative Search–Visit (whole-document reading) BM2543.720k15.9 26.143k28.734.768k64.1 Dense43.021k25.925.542k47.636.558k65.7 BM25+Dense40.221k35.421.839k56.333.753k68.5 Iterative Search–Fetch (section-level reading) BM2541.013k31.124.522k50.330.640k76.6 Dense40.714k33.223.423k53.930.137k78.6 BM25+Dense40.514k32.624.623k53.034.935k73.6 SIEVE (BQL-filtered BM25)44.515k27.927.924k47.633.649k62.0 SIEVE (BQL-filtered Dense)45.815k27.928.224k48.034.648k61.5 SIEVE (BQL-filtered BM25+Dense) 45.314k20.929.221k32.637.246k62.2 across the collection. The broader accuracy–context fron- tier supports the same conclusion: configurations that read more do not systematically answer more questions correctly (Appendix Figure 8). 5.2 Full-System Comparison Retrieving once is insufficient; returning everything is expensive.The one-shot systems are the least accurate on every collection, confirming that multi-step questions require iterative retrieval. Iteration alone is not sufficient. Search–AutoRead adds the full text of every result and consumes the most context, but does not deliver a com- parable accuracy gain. A useful workflow must therefore support repeated search while preserving the agent’s abil- ity to choose what to read. Direct corpus interaction does not remove the need for retrieval.DCI is competitive with Search–Visit on the Wikipedia collections but trails it on the larger, hetero- geneous BCP-S collection. Restricting DCI to a BM25- retrieved working set recovers much of that gap and re- duces context use, but neither form surpasses SIEVE. Giving the agent direct access to files is therefore not a substitute for organizing candidates before inspection. lost gained Judge verdict gained (133)lost (112) 0200400600800 Questions, sorted by token change 100 0 100 distinct tokens (k) fewer tokens on 559/830 queries 27 bars clipped at ±120k Figure 3: Per-question changes from BM25 Search–Visit to SIEVE on BCP-S. Both panels share the ordering induced by token change. Top: gained and lost judge ver- dicts; unchanged verdicts lie on the centre line. Bottom: change in distinct tokens (SIEVE minus Search–Visit), clipped at±120k for display. Appendix C.3 documents our implementation and its dif- ferences from the published DCI setup. 7 Ranking and reading interact. The strongest ranker changes with both the collection and the reading strategy. BM25 is best for whole-document Search–Visit on the Wikipedia collections, while dense retrieval is best on BCP-S. With SIEVE, fusion is strongest on MuSiQue and BCP-S, whereas dense retrieval is strongest on Hot- potQA. Ranking quality should therefore be considered together with how results are inspected and read. BQL filtering helps every ranker. Search–Fetch pro- vides the cleanest control for the role of BQL: it uses the same rankers and section-level reading, but retrieves without BQL candidate selection (§4.1.1). SIEVE im- proves accuracy in all nine matched ranker–collection comparisons. Its advantage is thus not specific to the default BM25+Dense ranker. In these pairs, both systems can inspect and fetch sections; the remaining difference is whether the agent can define an eligible set before ranking. The result therefore supports the complete BQL-enabled retrieval path rather than a particular ranking model. The contribution of individual operators is examined in §6. 6 Ablation and Diagnostic Analysis Having compared the complete systems, we now ask which components produce the gain, whether it persists across retrievers and agent backbones, and where errors remain. Additional controls and the complete efficiency frontier appear in Appendices D.1 and D.2. 6.1 Components and Robustness Query-focused snippets.An addressable section is use- ful only if the agent can judge whether it is worth fetching. A heading describes the section’s topic, but may not re- veal its relevance to the current question. We therefore remove the25-token query-focused snippet while keeping candidate selection, ranking, instructions, result depth, and fetching unchanged (Figure 4). Removing snippets lowers accuracy by2.9–6.8points across the three collections, with a significant drop in every case. The agent also makes more model calls, but this additional search does not recover the lost accuracy. The snippets make the exposed structure actionable: they give the agent enough local evidence to decide which section should be read next. Retriever choice. BQL determines the eligible docu- ments, while the ranker determines which candidates the agent sees first. To separate these roles, we replace only 0246 Accuracy gain with snippets (points) BCP-S MuSiQue HotpotQA +6.8 +4.3 +2.9 Figure 4: Accuracy change from adding query-focused snippets. Full accuracy and cost values appear in Ap- pendix Table 9. 33M110M335M0.6B4B8B Dense encoder parameters (log scale) 34 35 36 37 38 Accuracy (%) BM25 Search--Visit default bge Qwen3-Embedding Figure 5: Accuracy by dense-encoder size on BCP-S. Lines distinguish encoder families, the outer circle marks the default encoder, and the dashed line marks BM25 Search–Visit. the dense retriever in SIEVE and keep the rest of the system fixed. We run this analysis on BCP-S, where retrieval accounts for most remaining errors (Figure 5). Context use remains between46k and48k tokens for all six encoders, compared with68.1k for Search– Visit, while accuracy ranges from34.6to38.0. Qwen3- Embedding-4B (Zhang et al., 2025) performs best, al- though larger encoders are not consistently more accurate. The narrow context range shows that the saving is not tied to a particular encoder. Retriever choice nevertheless remains important for final accuracy. The non-monotonic size trend also shows that SIEVE does not require the largest available encoder to retain its context advantage. Agent backbone. The agent backbone controls query reformulation, result inspection, and section fetching. We repeat the Search–Visit and SIEVE comparison with two additional deep-research agents to test whether the re- sult depends on Tongyi-DeepResearch. Across the nine backbone–collection pairs, SIEVE uses less context in 8 15304560 35 40 45 HotpotQA 20406080 20 25 30 MuSiQue 45607590 20 30 40 BCP-S Tokens per question (k) Accuracy (%) Tongyi-DRQwen-AgentWorldOpenResearcher Figure 6: Agent-backbone transfer across all three collections. Arrows run from BM25 Search–Visit (open) to SIEVE (filled); axes are scaled separately for readability. Appendix Table 8 reports the exact values. 0255075100 MuSiQue / SIEVE MuSiQue / Search–Visit HotpotQA / SIEVE HotpotQA / Search–Visit BCP-S / SIEVE BCP-S / Search–Visit Share of incorrect runs (%) RetrievalSelectionSynthesis Figure 7: Failure composition among incorrect runs. Retrieval means no gold document surfaced; selection means surfaced but unopened; synthesis means incorrect after opening one. BCP-S uses exact match. eight and improves accuracy in seven; the remaining two accuracy differences are within0.6points (Figure 6). On BCP-S, all three backbones move toward both higher accuracy and lower context use. The largest savings occur when the baseline reads heav- ily. With OpenResearcher, SIEVE more than halves token use on both Wikipedia collections while keeping accuracy within0.6points. Both alternative agents also make sub- stantial accuracy gains on BCP-S while reading less. The complete results appear in Appendix Table 8. These trans- fers show that the main result is not tied to one agent’s search policy or prompting conventions. 6.2 Failures and BQL Use Where errors arise.Using the interaction traces, we di- vide incorrect runs into retrieval, selection, and synthesis failures (Figure 7). HotpotQA and MuSiQue are mainly synthesis-bound: in81–89%of their errors, the agent opens a gold doc- ument but still answers incorrectly. BCP-S presents a different bottleneck: in65–68%of incorrect runs, no gold document is surfaced. SIEVE reduces the propor- tion of selection failures on every collection, consistent with structured cards helping the agent choose among retrieved sources. Further gains therefore require better retrieval on BCP-S, but better evidence extraction and synthesis on the Wikipedia collections. Appendix D.3 provides examples of all three failure types. How agents use BQL. The interaction logs confirm that agents use the additional BQL expressivity. Field restrictions appear in42.8–69.1%of questions, and Boolean combinations in34.1–44.1%(Appendix Ta- ble 3); representative queries are given in Appendix B.3. Exact constraints and fallback retrieval play complemen- tary roles. Calls with matches retain the submitted con- straints, while a zero-hit call triggers ranked term re- trieval. This fallback handles36.8–53.7%of search calls, and removing it lowers BCP-S accuracy by6.4points. Together with the nine gains over the ranker-matched no-BQL control (§5), these findings show that effective BQL search requires both precise selection and reliable recovery. The two play complementary roles: non-empty queries preserve explicit constraints, while recovery lets 9 the agent revise an over-constrained intermediate query using newly surfaced terms. Additional controls show that the gain cannot be explained by structure exposure alone or reproduced by a matched Indri-style executor (Appendices D.1 and C.4). 7 Conclusion In this study, we exploit the structure of web sources to improve how deep-research agents search and read. We introduce SIEVE, a search–inspect–fetch strategy built around fielded Boolean retrieval. Across three QA col- lections, SIEVE achieves the highest observed accuracy on each collection. Its default configuration also outper- forms the best conventional Search–Visit configuration on every collection while using20.7–50.6%fewer to- kens. These gains persist across retriever choices and three agent backbones. Our findings show that source structure is not merely a formatting artifact or a preprocessing convenience. When exposed as searchable and fetchable fields, it shapes what the agent retrieves, what it inspects, and how much evi- dence enters its context. This suggests a broader direction for deep research: retrieval systems should preserve and expose the organization of sources rather than reduce them to flat pages, allowing agents to search and read information at the granularity at which it was written. Language-model agents also change the practical role of Boolean retrieval. Historically, authoring and revis- ing precise fielded queries required specialist effort. An agent can perform that work during its research loop while retaining the explicit selection constraints that make Boolean search useful. This makes capabilities long used in professional search practical for general deep-research systems. Limitations The full comparison grid uses one primary backbone. Transfer experiments with Qwen-AgentWorld and Open- Researcher cover all three collections and reproduce the clearest gains when Search–Visit uses substantial context. We evaluate three collections; on Wikipedia, incomplete judge coverage makes exact match the primary metric. Query-language conditions receive condition-specific manuals, and answer-recovery coverage is incomplete for some Wikipedia conditions; Appendices B.2 and C.2 reproduce the instructions and document these asymme- tries. The structured/flat pairs withhold fields, not their text, and agents do not consistently invoke structured-only fields; their null comparison therefore does not show that structure is unhelpful. SIEVE jointly changes can- didate construction, result representation, and reading. We ablate snippets and dense fusion and cross search with reading, but do not fully cross every component. The evidence therefore supports the complete system, not an independent effect of Boolean operators. Ranking is available to both paths and is not a contribution. Zero- hit BQL queries also fall back to ranked term retrieval using a separate BM25 implementation from the Lucene ranker. Thus, SIEVE is a Boolean-capable workflow with designed zero-hit recovery, not a pure strict-Boolean or Lucene implementation. The BCP-S section trees are model-generated and may contain imperfect headings or boundaries. Wikipedia title matches use a newer snapshot without a content check; article drift may therefore add noise. References James P. Callan. Passage-level evidence in document retrieval. In Proceedings of the 17th Annual Inter- national ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 1994), pages 302–310, Dublin, Ireland, 1994. Springer. doi: 10.1007/978-1-4471-2099-5_31. Tong Chen, Hongwei Wang, Sihao Chen, Wenhao Yu, Kaixin Ma, Xinran Zhao, Hongming Zhang, and Dong Yu. Dense X retrieval: What retrieval granularity should we use? In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Process- ing (EMNLP 2024), pages 15159–15177, Miami, USA, 2024. Association for Computational Linguistics. doi: 10.18653/v1/2024.emnlp-main.845. Zijian Chen, Xueguang Ma, Shengyao Zhuang, Ping Nie, Kai Zou, Sahel Sharifymoghaddam, Andrew Liu, Joshua Green, Kshama Patel, Ruoxi Meng, et al. BrowseComp-Plus: A fair and disentangled evaluation benchmark for deep search agents. In Proceedings of the 64th Annual Meeting of the Association for Com- putational Linguistics (Volume 1: Long Papers), pages 22349–22370, San Diego, USA, 2026. Association for Computational Linguistics. doi: 10.18653/v1/2026.acl -long.1023. Charles L. A. Clarke and Mark D. Smucker. Boolean queries are all you need?, 2026. 10 Gordon V. Cormack, Charles L. A. Clarke, and Stefan Büttcher. Reciprocal rank fusion outperforms Con- dorcet and individual rank learning methods. In Pro- ceedings of the 32nd International ACM SIGIR Con- ference on Research and Development in Information Retrieval (SIGIR 2009), pages 758–759, Boston, USA, 2009. Association for Computing Machinery. doi: 10.1145/1571941.1572114. Jiaxuan Gao, Wei Fu, Minyang Xie, Shusheng Xu, Chuyi He, Zhiyu Mei, Banghua Zhu, and Yi Wu. Beyond ten turns: Unlocking long-horizon agentic search with large-scale asynchronous RL, 2025. Bernal Jiménez Gutiérrez, Yiheng Shu, Yu Gu, Michihiro Yasunaga, and Yu Su. HippoRAG: Neurobiologically inspired long-term memory for large language mod- els. In Advances in Neural Information Processing Systems (NeurIPS 2024), pages 59532–59569, Van- couver, Canada, 2024. Curran Associates, Inc. doi: 10.52202/079017-1902. Bernal Jiménez Gutiérrez, Yiheng Shu, Weijian Qi, Sizhe Zhou, and Yu Su. From RAG to memory: Non- parametric continual learning for large language mod- els. In Proceedings of the 42nd International Con- ference on Machine Learning (ICML 2025), pages 21497–21515, Vancouver, Canada, 2025. JMLR.org. doi: 10.48550/arXiv.2502.14802. URLhttps://pr oceedings.mlr.press/v267/gutierrez25a.html. Bowen Jin, Hansi Zeng, Zhenrui Yue, Jinsung Yoon, Ser- can Arik, Dong Wang, Hamed Zamani, and Jiawei Han. Search-R1: Training LLMs to reason and lever- age search engines with reinforcement learning. In Second Conference on Language Modeling (COLM 2025), Montreal, Canada, 2025. OpenReview.net. URL https://openreview.net/forum?id=Rwhi91ideu. Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and Ion Stoica. Efficient memory manage- ment for large language model serving with PagedAt- tention. In Proceedings of the 29th ACM Symposium on Operating Systems Principles (SOSP 2023), pages 611– 626, Koblenz, Germany, 2023. Association for Com- puting Machinery. doi: 10.1145/3600006.3613165. Xiaoxi Li, Guanting Dong, Jiajie Jin, Yuyao Zhang, Yu- jia Zhou, Yutao Zhu, Peitian Zhang, and Zhicheng Dou. Search-o1: Agentic search-enhanced large rea- soning models. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Process- ing (EMNLP 2025), pages 5420–5438, Suzhou, China, 2025a. Association for Computational Linguistics. doi: 10.18653/v1/2025.emnlp-main.276. Xiaoxi Li, Jiajie Jin, Guanting Dong, Hongjin Qian, Yongkang Wu, Ji-Rong Wen, Yutao Zhu, and Zhicheng Dou. WebThinker: Empowering large reasoning mod- els with deep research capability. In Advances in Neu- ral Information Processing Systems (NeurIPS 2025), San Diego, USA, 2025b. URLhttps://proceeding s.neurips.c/paper_files/paper/2025/hash/a e03bdef276132fae089692445725635-Abstract-C onference.html. Zhuofeng Li, Dongfu Jiang, Xueguang Ma, Haoxiang Zhang, Ping Nie, Yuyu Zhang, Kai Zou, Jianwen Xie, Yu Zhang, and Wenhu Chen. OpenResearcher: A fully open pipeline for long-horizon deep research trajectory synthesis, 2026a. Zhuofeng Li, Haoxiang Zhang, Cong Wei, Pan Lu, Ping Nie, et al. Beyond semantic similarity: Rethinking retrieval for agentic search via direct corpus interaction, 2026b. Jimmy Lin, Xueguang Ma, Sheng-Chieh Lin, Jheng- Hong Yang, Ronak Pradeep, and Rodrigo Nogueira. Pyserini: A Python toolkit for reproducible informa- tion retrieval research with sparse and dense represen- tations. In Proceedings of the 44th International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 2021), pages 2356–2362, Canada, 2021. Association for Computing Machinery. doi: 10.1145/3404835.3463238. Donald Metzler and W. Bruce Croft. Combining the language model and inference network approaches to retrieval. Information Processing & Management, 40 (5):735–750, 2004. doi: 10.1016/j.ipm.2004.05.001. Reiichiro Nakano, Jacob Hilton, Suchir Balaji, Jeff Wu, Long Ouyang, Christina Kim, Christopher Hesse, Shantanu Jain, Vineet Kosaraju, William Saunders, et al. WebGPT: Browser-assisted question-answering with human feedback, 2021. Stephen Robertson and Hugo Zaragoza. The probabilistic relevance framework: BM25 and beyond. Foundations and Trends in Information Retrieval, 3(4):333–389, 2009. doi: 10.1561/1500000019. Stephen E. Robertson, Hugo Zaragoza, and Michael J. Taylor. Simple BM25 extension to multiple weighted 11 fields. In Proceedings of the Thirteenth ACM Inter- national Conference on Information and Knowledge Management (CIKM 2004), pages 42–49, Washington, DC, USA, 2004. Association for Computing Machin- ery. doi: 10.1145/1031171.1031181. Parth Sarthi, Salman Abdullah, Aditi Tuli, Shubh Khanna, Anna Goldie, and Christopher D. Manning. RAPTOR: Recursive abstractive processing for tree-organized retrieval. In International Conference on Learning Representations (ICLR 2024), Vienna, Austria, 2024. OpenReview.net. URLhttps://openreview.net/f orum?id=GN921JHCRw. Huatong Song, Jinhao Jiang, Yingqian Min, Jie Chen, Zhipeng Chen, Wayne Xin Zhao, Lei Fang, and Ji- Rong Wen. R1-Searcher: Incentivizing the search capability in LLMs via reinforcement learning, 2025. Trevor Strohman, Donald Metzler, Howard Turtle, and W. Bruce Croft. Indri: A language model-based search engine for complex queries. In Proceedings of the International Conference on Intelligence Analysis, vol- ume 2, pages 2–6, McLean, USA, 2005. URLhttps: //ciir.cs.umass.edu/pubfiles/ir-416.pdf. Shreyas Subramanian, Adewale Akinfaderin, Yanyan Zhang, Ishan Singh, Mani Khanuja, Sandeep Singh, and Maira Ladeira Tanke. Keyword search is all you need: Achieving RAG-Level performance without vector databases using agentic tool use, 2025. URL https://arxiv.org/abs/2602.23368. Hao Sun, Zile Qiao, Jiayan Guo, Xuanbo Fan, Yingyan Hou, Yong Jiang, Pengjun Xie, Yan Zhang, Fei Huang, and Jingren Zhou. ZeroSearch: Incentivize the search capability of LLMs without searching, 2025. Tongyi DeepResearch Team et al. Tongyi DeepResearch technical report, 2025. URLhttps://arxiv.org/ab s/2510.24701. Harsh Trivedi, Niranjan Balasubramanian, Tushar Khot, and Ashish Sabharwal. MuSiQue: Multihop questions via single-hop question composition. Transactions of the Association for Computational Linguistics, 10: 539–554, 2022. doi: 10.1162/tacl_a_00475. Harsh Trivedi, Niranjan Balasubramanian, Tushar Khot, and Ashish Sabharwal. Interleaving retrieval with chain-of-thought reasoning for knowledge-intensive multi-step questions. In Proceedings of the 61st An- nual Meeting of the Association for Computational Lin- guistics (Volume 1: Long Papers), pages 10014–10037, Toronto, Canada, 2023. Association for Computational Linguistics. doi: 10.18653/v1/2023.acl-long.557. Andrew Trotman and Börkur Sigurbjörnsson. Narrowed extended XPath I (NEXI). In Advances in XML In- formation Retrieval: Third International Workshop of the Initiative for the Evaluation of XML Retrieval, Lecture Notes in Computer Science, vol. 3493, pages 16–40, Dagstuhl Castle, Germany, 2005. Springer. doi: 10.1007/11424550_2. Workshop held Dec. 2004; Springer LNCS volume copyright/published 2005 per Crossref. Howard Turtle and W. Bruce Croft. Evaluation of an inference network-based retrieval model. ACM Trans- actions on Information Systems, 9(3):187–222, 1991. doi: 10.1145/125187.125188. Shuai Wang, Shengyao Zhuang, and Guido Zuccon. BERT-based dense retrievers require interpolation with BM25 for effective passage retrieval. In Proceed- ings of the 2021 ACM SIGIR International Confer- ence on Theory of Information Retrieval, pages 317– 324. Association for Computing Machinery, 2021. doi: 10.1145/3471158.3472233. URLhttps: //doi.org/10.1145/3471158.3472233. Shuai Wang, Hang Li, and Guido Zuccon. MeSH sug- gester: A library and system for MeSH term sugges- tion for systematic review Boolean query construction. In Proceedings of the Sixteenth ACM International Conference on Web Search and Data Mining, pages 1176–1179, 2023a. Shuai Wang, Harrisen Scells, Bevan Koopman, and Guido Zuccon. Can ChatGPT write a good Boolean query for systematic review literature search? In Proceedings of the 46th International ACM SIGIR Conference on Research and Development in Information Retrieval, pages 1426–1436. Association for Computing Machin- ery, 2023b. doi: 10.1145/3539618.3591703. URL https://doi.org/10.1145/3539618.3591703. Shuai Wang, Harrisen Scells, Martin Potthast, Bevan Koopman, and Guido Zuccon. Generating natural lan- guage queries for more effective systematic review screening prioritisation. In Proceedings of the Annual International ACM SIGIR Conference on Research and Development in Information Retrieval in the Asia Pa- cific Region, pages 73–83. Association for Computing Machinery, 2023c. doi: 10.1145/3624918.3625322. URLhttps://doi.org/10.1145/3624918.362532 2. 12 Shuai Wang, Harrisen Scells, Bevan Koopman, and Guido Zuccon. Reassessing large language model Boolean query generation for systematic reviews. In Proceed- ings of the 48th International ACM SIGIR Confer- ence on Research and Development in Information Retrieval (SIGIR 2025), pages 3296–3305, Padua, Italy, 2025. Association for Computing Machinery. doi: 10.1145/3726302.3730329. Shuai Wang, Harrisen Scells, Bevan Koopman, and Guido Zuccon. AutoBool: Reinforcement-learned LLM for effective automatic systematic reviews Boolean query generation. In Proceedings of the 19th Conference of the European Chapter of the Association for Compu- tational Linguistics (Volume 1: Long Papers), pages 1468–1493, Rabat, Morocco, 2026. Association for Computational Linguistics. doi: 10.18653/v1/2026.e acl-long.68. URLhttps://aclanthology.org/202 6.eacl-long.68/. Wikimedia Enterprise, Wikimedia Foundation. Struc- tured Contents Wikipedia. Hugging Face dataset, May 2026. URLhttps://huggingface.co/datasets/ wikimedia/structured-wikipedia. Shitao Xiao, Zheng Liu, Peitian Zhang, Niklas Muen- nighoff, Defu Lian, and Jian-Yun Nie. C-Pack: Packed resources for general Chinese embeddings. In Pro- ceedings of the 47th International ACM SIGIR Con- ference on Research and Development in Information Retrieval (SIGIR 2024), pages 641–649, Washington, DC, USA, 2024. Association for Computing Machin- ery. doi: 10.1145/3626772.3657878. Peilin Yang, Hui Fang, and Jimmy Lin. Anserini: Repro- ducible ranking baselines using Lucene. ACM Journal of Data and Information Quality, 10(4):16:1–16:20, 2018a. doi: 10.1145/3239571. Zeyu Yang, Qi Ma, Jason Chen, and Anshumali Shrivas- tava. Superintelligent retrieval agent: The next frontier of agentic retrieval, 2026. Zhilin Yang, Peng Qi, Saizheng Zhang, Yoshua Bengio, William W. Cohen, Ruslan Salakhutdinov, and Christo- pher D. Manning. HotpotQA: A dataset for diverse, explainable multi-hop question answering. In Proceed- ings of the 2018 Conference on Empirical Methods in Natural Language Processing (EMNLP 2018), pages 2369–2380, Brussels, Belgium, 2018b. Association for Computational Linguistics. doi: 10.18653/v1/D18-1 259. Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. ReAct: Synergizing reasoning and acting in language models. In International Conference on Learning Representa- tions (ICLR 2023), Kigali, Rwanda, 2023. OpenRe- view.net. URLhttps://openreview.net/forum?i d=WE_vluYUL-X. Yuqi Zeng, Qixiang Deng, Yulei Wan, Ruiquan Jiang, Xiaoqing Zheng, and Xuanjing Huang. Rethinking agentic RAG: Toward LLM-Driven logical retrieval beyond embeddings, 2026. Chengxiang Zhai and John Lafferty. A study of smooth- ing methods for language models applied to ad hoc information retrieval. In Proceedings of the 24th An- nual International ACM SIGIR Conference on Re- search and Development in Information Retrieval (SIGIR 2001), pages 334–342, New Orleans, USA, 2001. Association for Computing Machinery. doi: 10.1145/383952.384019. Yanzhao Zhang, Mingxin Li, Dingkun Long, Xin Zhang, Huan Lin, Baosong Yang, Pengjun Xie, An Yang, Day- iheng Liu, Junyang Lin, Fei Huang, and Jingren Zhou. Qwen3 embedding: Advancing text embedding and reranking through foundation models, 2025. Shengyao Zhuang, Yuansheng Ni, Hengxin Fun, Jimmy Lin, and Xueguang Ma. Towards retrieving interaction spaces for agentic search, 2026. Yuxin Zuo, Zikai Xiao, Li Sheng, Fei Huang, Jianhong Tu, Yuxuan Liu, Tianyi Tang, Xiaomeng Hu, Yang Su, Qingfeng Lan, et al. Qwen-AgentWorld: Language world models for general agents, 2026. A Dataset Construction and Statistics BROWSECOMP-PLUS source and document uni- verse. We load and de-obfuscate the complete Tevatron/browsecomp-plusrelease:100,195docu- ments and all830questions. We preserve the released document identifiers, questions, and relevance annota- tions. The flat and structured variants contain the same full document universe, and every BCP-S condition searches it. Corpus membership is therefore indepen- dent of the evaluation questions; no query-pool filtering or query-dependent document selection is applied. 13 BCP-S fields and sectioning. Title, author, and date are parsed from the de-obfuscated document frontmatter; placeholder and boilerplate author values are removed. A one-time pass with OpenAI’sgpt-5.5-nanoproposes section headings and boundary lines. A deterministic procedure applies those boundaries; the model does not rewrite document text. The sectioning requests cover all100,195documents. Rare documents that exceed the per-request input limit are truncated to fit before their boundaries are generated. Title, cleaned author, date, and sections are scopeable in the structured variant. The flat twin contains the same emitted text, including inserted headings and folded author/date text, but hides those fields from fielded retrieval. In a20,000-document audit sample, every document has a non-emptysectionsfield,94.9%have multiple sections, and the mean is 14.7 sections per document. Wikipedia reconstruction. HotpotQA and MuSiQue are rebuilt from the Structured Wikipedia release (Wikimedia Enterprise, Wikimedia Foundation, 2026) (enwiki_namespace_0), which supplies native sections, infoboxes, and abstracts; no LLM pass is used. We match benchmark titles to article names and URL-derived titles after Unicode, case, punctuation, whitespace, and dia- critic normalization. Because the title is treated as the article identity, a title match is accepted without a content check. Documents with no match, typically renamed or deleted articles, are dropped. Gold references to them are removed, followed by any question left with no gold document. Table 2: Wikipedia collection sizes after title matching. Questions retained reports retained/original questions; Coverage is the corresponding retention rate. CollectionDocs retainedQuestions retainedCoverage HotpotQA59,8337,343/7,405 99.16% MuSiQue16,5832,409/2,417 99.67% Each retained collection is emitted as two twins. The structured version retains title, sections, and infobox data; the flat version exposes title and text only. Their doc- ument identifiers, questions, qrels, and emitted text are identical, so BM25 and dense retrieval see the same con- tent. Fielded retrieval can scope over sections. A post-hoc audit found that infobox data remained available to the result and read tools but were not indexed for search as the manual claimed; we report this mismatch in Ap- pendix B.2.4. In a20,000-document HotpotQA sample, every docu- ment has at least one section,89.6%have multiple sec- tions, and the mean is8.44; a full scan of59,833docu- ments gives89.3%and8.29. Across all16,583MuSiQue documents, the corresponding values are100%,87.9%, and9.70. These counts include the leading(intro)unit. Unlike the Wikipedia structures, the BCP-S section trees are model-generated, which we treat as a limitation. Section-quality audit. Section counts alone do not show that the boundaries are useful. We therefore in- spect200random BCP-S documents (seed 42). The sample averages16.2sections per document (median9.0; 10th–90th percentile3.0–28.1), and98.0%contain mul- tiple sections. The gap between the mean and median reflects a long right tail. All sampled section lists partition their source text cleanly. Among headings for which the measure is ap- plicable,87.1%share a content word with their section body. Near-empty sections account for1.9%of the sam- ple. Repeated headings over different content occur in 3.5%of documents; in the worst case, one heading is re- peated across 83 sections. Thus, section-targeted reading is well supported for most documents, although a small degenerate tail remains. B Method Details This appendix specifies the BQL language and tool behav- ior used by SIEVE. We first document the query grammar and executor behavior, then reproduce the instructions shown to the agents, and finally give issued queries and a complete worked interaction. B.1 Query Grammar and Tool Behavior The agent-facing BQL supports field restrictions, Boolean composition, wildcards, phrases, and date ranges. A query of the formterm[field]restricts a term to a named field;AND,OR, andNOTcombine conditions; paren- theses control grouping;word*expresses a wildcard; and a quoted"phrase"requires an exact span. Where a typed date field exists, date[RANGE] filters by date. Available search fields depend on the corpus. The Wikipedia collections index title, section, and body. Their records also contain infobox data for inspection and read- ing, but a post-hoc audit found that the advertised in- fobox search field was not indexed. BCP-S indexes ti- tle, section, body, author, and date, but has no infobox field. Its documents contain section trees;94.9%of a 14 20,000-document audit sample are multi-section, and fetchcan address those sections. However, the man- ual used in the experiments was written for an earlier corpus build and incorrectly stated that sections were un- available. We discuss both instruction–index mismatches in Appendix B.2.4. When a hardANDquery returns no exact matches, the default executor ranks documents using the query’s pos- itive terms. This fallback was enabled in every primary experiment, so the main BQL-filtered conditions are not strict Boolean retrievers. An appendix control disables the fallback while holding the remaining SIEVE workflow fixed (Table 7). The lower-level executor also implementsNEAR/w with LuceneSpanNearQuery, but the agent-facing to- kenizer has noNEARtoken. It rewritesNEAR/5(a,b)into a string that the parser rejects. Proximity use is therefore zero by construction. Two other parser behaviors were absent from the agent manuals. First, an unquoted multi- word sequence compiles to anANDover its words rather than to the adjacent phrase described in the manuals. Sec- ond, lowercase Englishand,or, andnotare parsed as Boolean operators even inside an otherwise plain query. The language follows familiar Boolean and fielded- search conventions. For example, its field restriction corresponds tox[ti]in Ovid/PubMed orTI(x)in West- law/Lexis; Boolean operators map directly; andword* mirrors truncation forms such as Ovid’s auth*. Auxiliary Boolean/structured retrieval comparison. The appendix additionally reports Indri (Strohman et al., 2005) to situate BQL against an established system for Boolean and structured queries. Its ordered and unordered proximity operators compile to LuceneSpanNearQuery; typed dates compile to fielded range queries; and belief- combination operators useLMDirichletSimilarity withμ=2500(Zhai and Lafferty, 2001). This condition is excluded from the main systems and result table. Observed operator use. Table 3 reports how often SIEVE uses each part of the language. Table 3: Share of questions for which each BQL operator class appears at least once. Rows overlap because one question may use several classes. No field/Boolean/date excludes those three operator classes but may include phrases or wildcards. Operator classBCP-SHotpotQAMuSiQue Quoted phrase88.476.089.2 Field restriction42.866.069.1 Boolean34.141.944.1 Wildcard1.84.98.4 Typed date range0.70.20.1 Proximity0.00.00.0 No field/Boolean/date54.730.930.1 B.2 Query-Language Instructions B.2.1 Instruction Assignment by Condition Only conditions that expose a query language receive query-writing instructions. SIEVE and its ranker abla- tion receive the Search–Fetch instructions reproduced below. The BQL-filtered whole-document controls re- ceive a related control manual, while the appendix-only Indri comparison receives instructions for Indri syntax. BM25, dense, BM25+Dense, DCI, and retrieve-then-read receive no query-language manual. The source filenames for the whole-document control manuals end in_v2. This suffix is an internal filename only: it does not denote a second or improved SIEVE model. We call them the whole-document control manu- als throughout the paper because that is their experimen- tal role. Table 4 gives the assignment; the filenames are retained in parentheses solely for reproducibility. 15 Table 4: Query-language manual assigned to each con- dition. “Wikipedia” denotes HotpotQA and MuSiQue, and “BrowseComp” denotes BCP-S. The_v2suffix is an internal filename, not a separate SIEVE version. ConditionInstructions shown to the agent SIEVE; SIEVE without dense fusion Search–Fetch manual: Wikipedia (bql_doc.md); BrowseComp (bql_browsecomp.md) BQL-filtered BM25 or BM25+Dense, whole-page reading Whole-document control manual: Wikipedia (bql_doc_v2.md); BrowseComp (bql_browsecomp_v2.md) Indri and Indri+Dense (appendix only) Indri query manual (indri_doc.md) All other reported conditions None 16 B.2.2 Complete Search–Fetch Instructions SIEVE receives the instructions below on HotpotQA and MuSiQue. Its ablation without dense fusion receives identical instructions. Line breaks are wrapped at 80 columns for typesetting; the wording is otherwise unchanged. Section B.2.3 explains the corpus-specific instructions used on BCP-S. Complete agent-facing manual. The following listing reproducesagent_search/prompts/skills/bql_doc.md. It is byte-identical to the source apart from line wrapping and the replacement of its single Unicode right arrow with the ASCII digraph->for typesetting compatibility. # Structured document search: field-tagged`term[field]` Boolean + fetch Search the corpus with a Boolean query language: one expression selects the documents whose named fields contain your words. It matches words, not meaning — no embeddings, so exact terms matter (`OR` or`*` for variants). The language: `term[field]`,`AND`/`OR`/`NOT`, parentheses, wildcard`*`, quoted`"phrase"`. A **search never shows document bodies** — only structure (title, matched fields, section names, infobox keys). **fetch** then pulls the one slice that should hold the fact. Terms are case-insensitive. Two moves, in order: 1. **search** a query -> ranked DOCUMENTS: each hit shows the title, the fields your terms matched, the doc's section names, and its infobox keys — numbered for`fetch`. 2. **fetch** a named section (or`infobox`) of a numbered doc — a name from that doc's list — to read its text. Never the whole document. ## How to search 1. Query entity NAMES, never the question's wording — relation words (spouse, owner, founder) are what you look FOR in the fetched slice, not what you search for. Unsure between spellings?`OR` them:`zurich[title] OR "zürich"[title]`. When the question only DESCRIBES a thing (no name given), don't AND the whole description — each added clause loses more docs, so a long AND of common words 0-hits. Start from the 1–2 tokens most likely to appear VERBATIM in the target doc — a proper name, a domain term, an exact number like`1897` — not the framing words (described, mentioned). 2. Field-scope tightly.`x[title]` = the doc is ABOUT x;`x[body]` = x is merely mentioned somewhere;`x[tiab]` = title-or-body;`x[infobox]` = the reverse link — whose FACTS name x (a founder, an owner) when x has no page of its own. 3. Pick the hit by the TYPE the question implies, from the listing, not a fetch. Infobox keys type a hit at a glance — Released/Label = a work, Born/Spouse = a person, Country/State = a place. A title carrying a work marker — `(album)`/`(film)`/`(song)` — is that work, not a same-named person or place. ## The fields | field | matches | reach for it when | |---|---|---| |`title` \|`ti` | the document's name | the entity should be the doc's SUBJECT | |`section` \|`sec` | the heading names | a doc devotes a whole section to it | |`body` \|`ab` \|`text` | the section texts | it's merely mentioned, not the subject | |`infobox` \|`ib` | the key: value facts | the reverse link — whose facts name it | |`tiab` | title OR body (combo) | a first broad pass before narrowing | Not every corpus has real sections/infobox — a flat (non-Wikipedia-structured) document is just title + body, so`[section]`/`[infobox]` 0-hit there on EVERY doc; if one 0-hits immediately, fall back to`[body]`/`[tiab]` rather than re-trying it on a different entity. Atoms: a bare term matches anywhere in the scoped field. Several bare words parse as one exact adjacent PHRASE — reliably 0-hits unless truly contiguous (an album title).`word*` widens to any token starting with it.`term[f1,f2]` matches if EITHER field has it. Combine:`A OR B` (either),`A AND B` (both — use sparingly; 3+ clauses usually over-specify and 0-hit),`A NOT B`. Parentheses group as expected. ## Fetch — reading the slice you found `search` lists each doc's section names as`§[History·Career·Legacy]` and infobox keys as`ib[Born·Spouse]`.`fetch` takes`[rank, section]` pairs against that numbering: ``` "specs": [[1, "infobox"]] ``` - Fetch the ONE slice the fact lives in — the section names already told you where:`infobox` for relational facts, an early section for what/who it is. - If that slice truncates or lacks the fact, fetch a DIFFERENT named section that would hold it (biography / career / legacy / discography), not the same intro again — an unopened named section is a lead; never abandon a retrieved doc or fill the gap from memory. -`section` is a name from that doc's`§[...]` list (or`infobox`), NEVER a doc id, the question's wording, or a name you only hope exists — the`rank` already picks the doc. ## Hops — chaining across searches Each hop is its own search + fetch, not a bigger query. The fetched slice names the next entity — search THAT. No doc of its own? Flip direction: search it as `[tiab]`/`[infobox]` instead of`[title]` — the fact usually sits on the page that mentions it. 0 hits means your SURFACE is wrong, not that the doc is absent — recover in ONE move: drop a long name to its 1–2 most distinctive words, try `word*`, or move`[title]` to`[tiab]`. Two loosenings of the SAME entity both 0-hit? PIVOT to a different entity the question names; never answer from memory. Before you stop: check the fact is the ASKED-FOR TYPE, not just the next entity in the chain. Once a slice shows a fact of the right type, ANSWER — don't re-search to confirm. The answer is the shortest span COPIED VERBATIM from the slice — exact spelling and accents, and just the asked-for unit, not a compound (the state alone, not "City, State"). ## Worked examples -`harbor[title]` — the doc about the place; fetch its`infobox` for a relational fact. -`festival[title] AND film[body]` — which same-named hit is the film (a work), not the event. -`studio[body]` — nothing is titled for it; find the pages that mention it (reverse link). -`munoz[title] OR "muñoz"[title]` — accent/spelling variants in one search. - fetch`"specs": [[1, "infobox"]]` — read result 1's facts, then chain or answer. ## Common mistakes - A comma or "and" meant loosely — write real`AND`/`OR`;`AND` requires ALL clauses. -`A AND B` to CONNECT two entities from different hops (a person`AND` their team's founder) — they never share ONE document, so it 0-hits. Hop instead: search A, fetch, then search what you found. A tight`AND` is for ONE entity's own distinctive words (`telescope AND 1893`). - Searching the question's framing words (described, mentioned) instead of an entity NAME. - Fetching section after section — the listing already named which slice to open. - Re-searching to confirm a fact a slice already shows, or hunting a title equal to the answer — just answer from the slice you already have. - Answering the intermediate entity, or a compound, instead of the TYPE actually asked for. - Swapping in a more familiar entity that merely sounds like the question's name — search the LITERAL name bare first; only widen if that 0-hits. 17 B.2.3 Condition-Specific Instructions SIEVE on BCP-S. The BrowseComp Search–Fetch manual (bql_browsecomp.md) retains the same two-step workflow and query guidance as the Wikipedia manual but substitutes corpus-specific metadata. It addsauthor anddate, omitssectionandinfoboxfrom its field ta- ble, and advises falling back tobodywhen an author is unavailable. It also describes each result as a single body rather than documenting the available section names. Sec- tion B.2.4 examines this stale description separately. Whole-document Boolean controls.The BQL-filtered whole-document conditions use control manuals whose source filenames arebql_doc_v2.mdand bql_browsecomp_v2.md. Relative to the corresponding Search–Fetch manual, they add two instructions: temporal clues should be expressed as typed date ranges, and a zero-hit conjunction returns constraint-coverage feedback identifying which clauses were unmatched. The remaining query strategy and corpus field descriptions are unchanged. Thus, the whole-document comparison with SIEVE changes not only the reading action but also date guidance and zero-hit feedback; we treat it as a system-level control rather than an isolated section-fetch ablation. Appendix-only Indri comparison. Indri uses a dis- tinct query language and therefore receives its own man- ual (indri_doc.md). It describes Indri’s proximity, syn- onym, weighted-combination, field, and date operators rather than BQL syntax. Unlike the BQL instructions, it is not customized by collection. This comparison is included only to situate BQL against an established struc- tured retrieval system. B.2.4 Instruction and Index Mismatches BrowseComp understates section access. The BrowseComp Search–Fetch manual tells the agent that the collection has no addressable section structure. Specifically, it states thatsectionandinfoboxare not fields, that every document is a flat slice, and that scoping to either field always produces zero hits. This description came from an earlier unsegmented build and was not updated after the corpus was sectioned. In the evaluated collection,fetchcan address the generated sections individually;94.9%of a20,000-document audit sample is multi-section (Appendix A). The stale instruction therefore discourages a capability that SIEVE actually has and cannot explain a benefit from section-level reading. The worked interaction in Appendix B.3.2 makes the mismatch concrete: a body request fails, the tool lists the available sections, and the agent succeeds after selecting one of them. Wikipedia overstates infobox access. The Wikipedia Search–Fetch and whole-document control manuals ad- vertiseinfoboxas a searchable field. A post-hoc audit found that this field was not indexed as advertised. This error is the converse of the BrowseComp mismatch: it promises a search-time capability that is absent, whereas the BrowseComp manual discourages a section capability that is present. We report both cases because instruction– index mismatches can affect which query operators the agent attempts. B.3 BQL Queries and Worked Interaction To make the workflow concrete, this appendix reproduces a sample of issued BQL queries and one complete SIEVE interaction. The query strings and observations come from experiment logs for Tongyi-DeepResearch- 30B-A3B on BCP-S, HOTPOTQA-STRUCTURED (HotpotQA-S),andMUSIQUE-STRUCTURED (MuSiQue-S). Appendix B.1 gives the full gram- mar. Instance identifiers abbreviate their dataset prefix (e.g.browsecomp_plus_structured__772is shown as __772). B.3.1 Sample of Issued Queries Table 5 lists 12 queries the agent actually issued, chosen to cover the grammar’s main constructs. Hits is the num- ber of documents the query matched; “0 (fallback)” marks a query with zero exact Boolean matches, for which the executor returned a soft BM25-ranked list and advised the agent to verify, loosen, or replace the query (§3). One query is shortened for space, with the elision marked “. . . ”; every other query is reproduced exactly as issued. B.3.2 A Worked Interaction We tracebrowsecomp_plus_structured__500in full: a correct, four-step interaction (three tool calls plus the final answer) that shows the complete search→in- spect→fetch cycle, including a fetch error and its cor- rection. The question is: Identify the English name of structure originally con- structed during the 16th century. It was located in a capital city of a country that was under foreign rule for centuries. The structure faced destruction three years af- ter its initial completion due to an attack led by a country 18 Table 5: Examples of BQL expressions issued by SIEVE. Instance identifies the collection and question; Hits is the number of exact matches. “0 (fallback)” indicates that no exact match was found and the ranked fallback was returned. “ti” and “tiab” denote title and title-or-body fields, respectively. ConstructQuery (verbatim)InstanceHits Plain term EUMuSiQue-S 4hop2__9988 _158279_70784_79935 277 Quoted phrase "Night Shade Books"BCP-S __8701 Field-scoped Club[ti]HotpotQA-S 5ab52996 5542990594ba9d1e 133 Implicit AND (unquoted natural language) township established in the 1960s to accommodate migrant workers streets were named . . . renamed late 2010s BCP-S __7721 Boolean AND FDA AND antibioticMuSiQue-S 2hop__35686 _58556 3 Boolean OR "Hampshire" OR "Hampden"HotpotQA-S 5a838944 5542996488c2e450 991 Negation (NOT) Splendor NOT American[tiab]HotpotQA-S 5a77ca39 55429967ab1052a3 33 Wildcard WNP*HotpotQA-S 5a8dcbc0 554299068b959df4 4 Date range "glassmaker"[body] OR "stained glass artist"[body] AND "died 1880"[date] BCP-S __80230 Multi-constraint "Harry Potter"[title] OR "Harry Potter"[body] AND "graffiti"[body] AND date[2011-01-01] BCP-S __79024 Zero-exact→ fallback (negation) Iraq[title] AND NOT "Iraq War"[title]MuSiQue-S 4hop2__9988 _261673_70784_61381 0 (fallback) Zero-exact→ fallback (date range) Kwesi Arthur debut album[title] AND 2018..2023[date]BCP-S __7870 (fallback) on the same continent. Rebuilt within the same century it was initially constructed, it was eventually damaged again in the mid 17th century. Step 1 (search).The agent issues"Fort Santiago"[title] OR "Fort Santiago"[body], which compiles toIN(title, "Fort Santiago") OR IN(body, "Fort Santiago")and returns 5 matches. The top result card reads (abridged): 1 42282 ’Fort Santiago - Wikipedia’ §[Naming and role·Origins and construction·British occupation. . . ] matched: title,body . . . with four further cards for documents 86640, 24089, 18850, and 35629 (a Manila city page). Step 2 (fetch, fails). The agent requests thebody section of the first, third, and fifth ranked cards (doc- uments 42282, 24089, and 35629):fetch specs = [[1,"body"],[3,"body"],[5,"body"]]. All three calls error, because these are structured records with named sections rather than a generic body field: [42282 §body] ERROR: no section ’body’ on 42282. Available: (intro)·Naming and role·Origins and construction·British occupation. . . (and likewise for 24089 and 35629). Step 3 (fetch, succeeds).The agent corrects the request to the sections the error message ad- vertised:fetch specs = [[1,"Origins and construction"],[3,"(intro)"]]. This returns the ac- tual section text, including: “The fort was destroyed in 1574 during the Chinese attack led by Limahong. The stone fort was built between 1589 and 1592 and was re- paired and extended after being damaged by the 1645 earthquake” (from document 24089’s introduction), and a longer passage from document 42282’s “Origins and construction” section describing the 1571 founding, the 1574 Limahong raid, and the 1590–1593 stone rebuild. Step 4 (answer). Before answering, the model checks all four constraints against the fetched text: 1571 con- struction (16th century); Manila, capital of the Philippines under Spanish rule for centuries; the 1574 Limahong at- tack, three years after 1571; the 1589–1592 stone rebuild in the same century; and the 1645 earthquake damage, in the mid-17th century. It then emits<answer>Fort Santiago</answer> . The gold answer is Fort Santiago; the answer is scored exact-match correct. 19 C Evaluation and Baselines This appendix records the common generation and budget settings, the evaluation procedure, and implementation details for baselines and auxiliary retrieval controls. C.1 Decoding, Serving, and Budgets All agent backbones use temperature0.6, seed42, lo- cal vLLM serving (Kwon et al., 2023), and the released ReAct scaffold (Yao et al., 2023). The loop format, sys- tem prompt, and termination contract are fixed across conditions. The access-and-reading setup is not the only varying factor, however; Appendix C.2 describes the re- maining asymmetries. Context window and serving concurrency. The pri- mary backbone is served at a131,072-token context window, the model’s vLLM–max-model-len. Qwen- AgentWorld and OpenResearcher use262,144tokens. Each backbone keeps the same context window when comparing Search–Visit with SIEVE. We introduced an early-stop rule part-way through the project. Once a run reaches90%of its context window, the rule asks for a fi- nal answer instead of waiting for the step cap to overflow the window. Later cells use this rule, whereas earlier cells do not. Each run’s configuration file records whether it was active. Serving concurrency ranges from two to eight vLLM workers. We use fewer workers for long-context datasets to prevent throughput degradation. Because runs are in- dependent, concurrency changes scheduling rather than generation or scoring. Context early stopping and con- currency are not matched by construction; the released analysis records any differences within a reported pair. Step budgets. Every search call returns at most five result cards (k=5), and every iterative condition has a maximum budget of100agent steps. These values are fixed in the run configuration rather than inferred from ob- served trajectories; runs may stop earlier after producing a final answer or reaching the context-window threshold. Single-call retrieve-then-read conditions have no iterative step budget. Budget comparability.Because the cap is uniform, the reported comparisons are not confounded by different nominal step budgets. They can still differ in realized trajectory length: an agent may answer early, trigger the context-window stop, or use the complete budget. C.2 Evaluation and Answer Recovery Recovering missing final answers.Some agents reach the step limit while still using tools and never produce a scorable final answer. Because the frequency of these empty runs differs across conditions, we separately evalu- ate whether a terminal answer can be recovered from the completed trajectory. We apply a deterministic offline recovery procedure to empty runs. It replays the terminal transcript with the assistant response already opened by<answer>, which permits only an answer continuation and no further tool use. The procedure recovers about93%of the runs to which it is applied. It writes a separate overlay rather than modifying the original rows, and it runs before judged comparisons because recovered answers can change sys- tem rankings. Recovery coverage is unfortunately incomplete. All BCP-S cells and the two Wikipedia Search–Visit base- lines have recovery overlays. The Wikipedia SIEVE arms and other Search–Fetch conditions do not. This asymme- try limits comparisons across those groups. Matching token budgets.For retrieve-then-read base- lines, we enforce the budget after assembling and tokeniz- ing the complete prompt, including the chat template. A fit loop removes content until the prompt fits the model context window. For agentic conditions, whole-document visit and section-level fetch share a12,000-token ceiling per docu- ment. Their comparison therefore changes what can be read, not the maximum amount available from a docu- ment. All iterative conditions also use the same maximum budget of100agent steps, and every search call returns at most five results. A post-hoc audit identified two re- maining asymmetries: tool documentation and result-list rendering. We give the direction of each below and repro- duce the condition-specific instructions in Appendix B.2. Validating engine reimplementations. We compare reference retrieval components with their production en- gines on identical inputs before interpreting an experi- mental difference. Appendix C.4 reports the divergence we found rather than treating the implementations as equivalent. C.3 DCI Reimplementation Our DCI condition adapts Li et al. (2026b) to our evalua- tion harness (§4.1.1). The agent receives onlybashand readtools and searches the raw corpus directly, without 20 a retriever. Where the paper leaves an implementation detail unspecified, we follow its stated intent. Two delib- erate differences remain. First, we omit the original five-step “SEARCH STRAT- EGY (follow exactly)” prompt. This makes DCI consis- tent with our other conditions that do not expose a query language, but likely disadvantages it relative to the pub- lished implementation. Query-language conditions do receive a tool manual, so prompt support is not fully matched across the experiment (Appendix C.2). Second, our DCI agent receives at most100steps on every collection (Appendix C.1). The original paper uses 300turns for its main results and reports that DCI needs more tool calls than a retrieval agent to locate an initial anchor document. Our smaller budget may therefore understate DCI’s performance. The BM25-bounded DCI control follows the central RISE design (Zhuang et al., 2026): BM25 first retrieves ten documents for the original question, after whichbash andreadoperate only on a flat-file staging area contain- ing those documents. It uses the same BM25 implementa- tion as the Search–Visit baseline and the same shell tools as DCI. The bound is enforced by the staged filesystem rather than by prompt instruction. C.4Retrieval Engine Validation and Indri Con- trol The zero-hit fallback uses a dependency-free BM25 ap- proximation. On identical queries and corpora, its top- 5 Jaccard overlap with Lucene BM25 is approximately 0.546on BCP-S, indicating substantial ranking diver- gence. The approximation still ranks the fallback list whenever a BQL search call has no exact match. Such fallbacks account for36.8–53.7%of SIEVE’s search calls. The reported results therefore use Lucene for Boolean filtering and ordinary sparse ranking, but the approximate scorer for zero-hit fallback lists; they should not be read as a pure Lucene evaluation (§4.1). Comparison with an established structured executor. Table 6 compares SIEVE with an Indri-style executor while holding the result cards, section-fetch behavior, result-pool size, and reading budget fixed. This compari- son places the proposed executor against an established structured-retrieval alternative; it is not part of the com- prehensive system comparison in Table 1. DAdditional Analyses and Full Results This appendix collects the controls and diagnostic anal- yses referenced from the main paper, followed by the complete per-dataset result tables. D.1 Workflow and Agent-Backbone Controls Table 7 tests two boundaries of the main result: whether SIEVE remains effective without ranked fallback, and whether exposing the structured corpus changes a base- line that cannot use its fields. Table 7: Controls for zero-hit fallback, snippets, and field exposure on BCP-S. The top block modifies SIEVE; the bottom block compares Search–Visit over the structured and flat twins. Bold marks the best value in each column. ConditionJudge%EM%Tok.Calls SIEVE37.234.546k62.2 Strict Boolean (no fallback)30.829.346k73.6 Without snippets30.428.349k66.1 Search–Visit (structured)34.731.168k64.1 Search–Visit (flat)33.129.869k64.1 Agent-backbone transfer.Table 8 gives the complete comparison summarized in §6. For each backbone and collection, it pairs BM25 Search–Visit with SIEVE under the same serving configuration. Table 8: Agent-backbone transfer. Each cell shows BM25 Search–Visit→SIEVE. Accuracy is the judge verdict on BCP-S and exact match elsewhere; tokens are distinct tokens per question. Full model identifiers appear in §4.1. BackboneCollectionAccuracyTokens Tongyi-DeepResearch BCP-S 34.7→37.2 68.1→46.0k HotpotQA 43.7→45.3 19.9→13.9k MuSiQue 26.1→29.2 43.0→21.3k Qwen-AgentWorld BCP-S 23.3→41.1 64.7→53.6k HotpotQA 40.3→40.1 13.7→14.0k MuSiQue 25.7→29.9 27.5→25.6k OpenResearcher BCP-S 18.7→25.7 88.6→55.7k HotpotQA 35.6→35.0 55.8→25.8k MuSiQue 20.2→20.8 76.6→31.8k Query-focused snippets.Table 9 in §D.4 gives the full accuracy and cost measurements for the matched snippet comparison summarized in Figure 4. The only difference is whether the result card includes the25-token query- focused snippet. 21 Table 6: Structured-retrieval executor comparison on BCP-S. Effectiveness, context use, and model calls are reported together. Column definitions follow Table 12; bold marks the best value in each column. ConditionJudge%EM%Recall%Tok./instAcc. tok./instCalls Indri30.628.046.947k1660k69.5 Indri + dense belief32.330.148.948k1671k68.5 SIEVE37.234.556.646k1593k62.2 D.2 Efficiency–Effectiveness Comparison Figure 8 places all primary-backbone BCP-S configu- rations on a common accuracy–context plane, including the retriever-sensitivity and structured-executor controls reported outside the comprehensive main table. 2k10k50k150k Distinct tokens per question (log scale) 0 10 20 30 40 Judge accuracy (%) +2.5 accuracy -32.4% tokens Other configs. (18)Search-VisitSieve Figure 8: Judge accuracy versus distinct tokens for the primary-backbone BCP-S configurations. Open circles denote other configurations, the square marks BM25 Search–Visit, and the star marks SIEVE; the arrow con- nects the latter two. D.3 Hand-Traced Failure Examples We manually inspect five incorrect (EM=0) SIEVE runs from BCP-S to check the boundaries used by the au- tomatic failure decomposition in Section 6. These are diagnostic examples rather than a representative sample. Retrieval failures.Instances__775,__770, and__774 have the gold answers Boston, Laura Lojo-Rodriguez, and Georgia Hirst, respectively; the model instead answers Santiago, Muhammad Faruque, and 1845. No gold docu- ment identifier appears in any search observation. These runs are therefore labeled retrieval failures irrespective of which result the agent later chooses or how it reasons over that result. Selection failure. For__788, the gold answer is Taj- ul-Masajid, while the model returns Faisal Mosque. The result list contains three of the four gold document iden- tifiers, so the necessary evidence is surfaced. Both sub- sequent fetches, however, target sections from a “largest mosque list” page rather than any of those gold docu- ments. The evidence is retrieved but never selected for reading, matching the selection-failure definition. Synthesis failure. For__773, the gold answer is Red, but the model answers white. Here the agent opens a gold document containing the answer before responding. Retrieval and selection have therefore succeeded; the remaining error lies in extracting or reasoning to the final answer. The traces support the operational distinctions used in Figure 7: retrieval asks whether gold evidence ever ap- pears, selection asks whether surfaced evidence is opened, and synthesis covers errors after a gold document is opened. D.4 Complete Result Tables We first report the complete accuracy and cost measure- ments for the query-focused snippet ablation summarized in Figure 4. The remaining tables expand each collection column in Table 1, adding trace-based gold-document exposure, the accumulated (step-summed) token total, and the number of model calls. They follow the main-table collection order: HotpotQA, MuSiQue, and BCP-S. These tables expand results summarized in the main paper; they do not introduce additional experiments. 22 Table 9: Matched snippet ablation. Acc. is the judge verdict on BCP-S and exact match on HotpotQA and MuSiQue; cost columns follow §4.1. Bold marks the better value. HotpotQAMuSiQueBCP-S ConditionAcc.Tok.Acc. tok.CallsAcc.Tok.Acc. tok.CallsAcc.Tok.Acc. tok.Calls SIEVE without snippets42.413k228k25.024.919k391k35.730.449k1592k66.1 SIEVE45.314k224k20.929.221k428k32.637.246k1593k62.2 Table 10: Full HotpotQA results for the systems in Table 1. Recall and the token columns follow Table 12. * marks a significant exact-match difference from BM25 Search–Visit. Bold marks the best value in each column, with costs compared among iterative systems. ConditionEM%Recall%Tok/instAcc. tok/instCalls One-shot retrieve-then-read BM2529.9*86.91k28k1.0 Dense30.3*90.11k15k1.0 Iterative Search–AutoRead BM2542.4*91.072k3226k36.8 Dense39.9*85.862k2980k35.8 Direct corpus interaction DCI (no retriever)42.894.335k861k21.8 BM25-bounded DCI (RISE-style)42.6*95.321k431k22.1 Iterative Search–Visit (whole-document reading) BM2543.795.220k295k15.9 Dense43.093.321k563k25.9 BM25+Dense40.2*85.921k643k35.4 Iterative Search–Fetch (section-level reading) BM2541.0*94.913k350k31.1 Dense40.7*93.514k381k33.2 BM25+Dense40.5*95.414k370k32.6 SIEVE (BQL-filtered BM25)44.595.215k389k27.9 SIEVE (BQL-filtered Dense)45.8*95.515k394k27.9 SIEVE (BQL-filtered BM25+Dense)45.3*94.814k224k20.9 23 Table 11: Full MuSiQue results for the systems in Table 1. Column definitions, significance marks, and bolding follow Table 10. ConditionEM%Recall%Tok/instAcc. tok/instCalls One-shot retrieve-then-read BM257.8*66.02k54k1.0 Dense11.0*82.61k32k1.0 Iterative Search–AutoRead BM2520.9*86.7108k6508k78.3 Dense20.5*79.495k5593k71.2 Direct corpus interaction DCI (no retriever)26.993.263k2071k39.4 BM25-bounded DCI (RISE-style)26.395.147k1328k39.6 Iterative Search–Visit (whole-document reading) BM2526.195.243k816k28.7 Dense25.593.342k1436k47.6 BM25+Dense21.8*84.439k1363k56.3 Iterative Search–Fetch (section-level reading) BM2524.594.622k725k50.3 Dense23.4*93.423k770k53.9 BM25+Dense24.695.723k764k53.0 SIEVE (BQL-filtered BM25)27.9*95.624k789k47.6 SIEVE (BQL-filtered Dense)28.2*95.824k809k48.0 SIEVE (BQL-filtered BM25+Dense)29.2*95.421k428k32.6 24 Table 12: Full BCP-S results for the systems in Table 1. Judge and EM are judge accuracy and strict exact match; Recall records whether a gold document was surfaced. For one-shot systems, recall instead uses the retrieved set. Tok/inst counts tokens without recounting prior context, while Acc. tok/inst recounts the growing prompt at each call. * marks a significant EM difference from BM25 Search–Visit. Bold marks the best value in each column, with costs compared among iterative systems. ConditionJudge%EM%Recall%Tok/instAcc. tok/instCalls One-shot retrieve-then-read BM252.21.1*3.02k119k1.0 Dense6.95.5*9.02k21k1.0 Iterative Search–AutoRead BM2513.612.2*20.0142k6716k85.4 Dense13.012.3*24.1122k6179k76.3 Direct corpus interaction DCI (no retriever)22.220.2*40.2107k3453k53.6 BM25-bounded DCI (RISE-style)33.430.655.275k2640k64.0 Iterative Search–Visit (whole-document reading) BM2534.731.153.168k2387k64.1 Dense36.533.957.758k1915k65.7 BM25+Dense33.730.852.353k1802k68.5 Iterative Search–Fetch (section-level reading) BM2530.628.252.940k1450k76.6 Dense30.127.852.937k1362k78.6 BM25+Dense34.932.762.935k1234k73.6 SIEVE (BQL-filtered BM25)33.631.753.049k1643k62.0 SIEVE (BQL-filtered Dense)34.632.552.048k1667k61.5 SIEVE (BQL-filtered BM25+Dense)37.234.556.646k1593k62.2 25