Skip to content

Research

Towards Retrieving Interaction Spaces for Agentic Search

Search for agents still returns what it returned for humans: a ranked list of passages. Our paper argues it should return something an agent can work in: a bounded slice of the corpus, with tools to explore it.

Two ways to give an agent a corpus, and why both stall

Most search agents still run on the retrieval contract built for non-agentic systems. A retriever ranks the corpus, returns a handful of snippets, and the model answers from whatever fits in its context window. This works when the answer sits in the top few passages. It fails when the evidence is buried deep in a long document, or when the agent needs to look twice. The snippets are all it will ever see.

The recent alternative goes to the other extreme. Direct corpus interaction drops the retriever and hands the agent shell tools over the raw corpus: grep everything, read what looks promising. This restores resolution, since the agent can read any line of any file, but it does not scale. Every broad grep is a scan over the whole corpus. In that line of work's own scaling study, doubling the corpus from 100k to 200k documents more than doubled tool calls and cost and cut accuracy by 13.6 points. The agent ends up spending its budget triaging shell output instead of answering.

The two failures point in opposite directions, but they share an assumption: that retrieval's job is to decide what the agent reads next.

Retrieval should build an interaction space

We think retrieval has a different job when the reader is an agent: to construct an interaction space, a bounded subset of the corpus that the agent explores with tools, outside the context window. Two design consequences follow.

  1. The space needs a boundary, and retrieval supplies it. Not the whole corpus, which is too big to scan. Not the context window, which is too small to hold the evidence. Not a ranked list the agent can only page through. A persistent set of files the agent can grep, read, and search again as often as it needs.
  2. The objects inside the space should be processed for interaction. Raw text forces a full read for any fact. Chunks decide in advance what the agent may see. Summaries lose the verbatim text needed to verify a claim. What helps is in-place structure: metadata that lets tools jump to the right span while the original text stays intact.
Search imports files into a bounded workspace. The agent works inside it with terminal tools, and searches again when it needs more of the corpus.

RISE: a proof of concept

RISE (Retrieving Interaction SpacE) implements both consequences with deliberately simple parts.

The boundary is BM25. The agent's search tool takes one or more natural-language sub-queries. Each pulls the top 1,000 documents from a corpus-wide BM25 index, and the union is hard-linked into a per-query working directory. The model sees a ten-result preview per sub-query, but the whole set is on disk, so search acts as a high-recall import rather than a snippet reader. The directory only grows: every later search adds to it. Inside it, the agent uses bash (rg, grep, cat and friends) and read (line-numbered slices of a file) to inspect and verify.

The processing is a table of contents. Offline, once per document, a small model proposes section titles and verbatim anchor strings. A deterministic step validates every anchor by exact match, inserts the validated headings in place, and prepends a line-numbered table of contents. Nothing in the body is summarized, deleted, or rewritten. At about $0.0014 per document it is a one-time cost. At query time the agent reads the table of contents first and jumps to the lines it needs.

A raw transcript has to be read end to end. The processed copy carries a line-numbered table of contents, so the agent jumps straight to the section it needs.

What we measured

We evaluated on BrowseComp-Plus, a fixed-corpus benchmark of hard browsing questions, using 100 queries over the 100k-document corpus and three agent models: OpenAI's gpt-5.4-mini and gpt-5.4-nano, and Xiaomi's mimo-v2.5-pro. The baseline is the default search agent that ships with the benchmark: BM25 search returning five snippets, plus a tool that fetches a full document.

gpt-5.4-nano 60% 70% 80% $0 $0.05 $0.10 RISE default search agent gpt-5.4-mini $0 $0.20 $0.40 $0.60 RISE default search agent mimo-v2.5-pro $0 $0.20 $0.40 $0.60 RISE default search agent accuracy on 100 BrowseComp-Plus queries vs. cost per query · 100k documents · each panel has its own cost axis
Accuracy and cost per query on 100 BrowseComp-Plus questions over 100k documents. Each panel has its own cost axis.

With every model, RISE is more accurate, and with the two larger models it is also cheaper per query: 78% against 68% at $0.28 against $0.46 on gpt-5.4-mini, and 78% against 73% at $0.38 against $0.61 on mimo-v2.5-pro. The interesting part is why. The default agent has similar BM25 recall; it finds the right documents about as often as RISE does. Its problem is exposure. It can only show the agent five snippets at a time, and fetching whole documents into context is expensive. RISE shows the agent nothing by default and lets it look.

search bash read gpt-5.4-nano RISE 23 default search agent 16 gpt-5.4-mini RISE 29 default search agent 39 mimo-v2.5-pro RISE 29 default search agent 33 mean tool calls per query · 100k documents
Mean tool calls per query. The default agent searches over and over; RISE searches less and spends the rest of its calls inspecting the workspace.

The tool-call profile makes the difference concrete. The default agent issues thirty or more searches per query and does little else. RISE issues ten to sixteen searches, then spends its remaining calls on rg and line-range reads inside the workspace: verifying rather than re-querying.

Two more results from the paper are worth knowing. Removing the table of contents, keeping only the BM25 boundary, costs one to four points of accuracy. Most of the gain comes from the bounded workspace itself, and the processing adds on top. And when we expanded the corpus tenfold to one million documents by adding 900,000 distractors, the bounded-workspace configuration held steady at 81% on gpt-5.4-mini. The agent's shell commands stay confined to the retrieved files, so the corpus can grow without the interaction growing with it. The paper also compares against the pure-shell agent over the full corpus: RISE matches its accuracy on gpt-5.4-mini at roughly a quarter of the per-query cost.

What this means if you are building an agent

The practical lesson is about what a search call should return.

  • Return a set, not a page. Let the agent keep every candidate on disk and come back to it. A ranked list the agent can only scroll is a weaker interface than a directory it can grep.
  • Keep the whole document, add structure. A table of contents with line numbers is cheap to make, and it turns a 14,000-word transcript into something an agent can navigate in two reads.
  • Let search be recall-oriented. When the agent has tools to inspect what came back, a search that imports a thousand candidates is more useful than one that carefully ranks five.

For prediction agents this matters in an everyday way. Earnings calls, filings, and long news reports carry their evidence deep in the body: the guidance sentence, the risk-factor paragraph, the one table. An agent that can search, land in a workspace, and jump to the right lines will find that evidence. An agent fed five snippets often will not.

This is also how we think about our own search API: return documents an agent can work over, not a page of snippets.

The full method, prompts, and ablations are in the paper: arXiv:2606.06880.