Search Agents Since May 2026: Structured Memory, Early Commitment, and How Much They Actually Search
This summer I read search-agent papers in fragments, mostly between rebuttals. After ACL, and after using Deep Research products in my own work for a while, several questions I had filed under implementation details started to look central.
Early search agents were ReAct plus a search API, whereas current systems look more like a multi-turn control process that decides what to query, what to keep in context, when to branch, and how to stop treating parametric memory as evidence. Most academic work from the last four months, together with a handful of industry notes, argues about these four decisions.
Three recurring threads
Search as a trained policy
Search behaves as a multi-turn policy to be trained, and a single retriever call cannot capture its decisions.
MemSearcher (ACL 2026 Findings) gives the clearest statement of the training-side problem. Concatenating the full trajectory makes the context grow without bound, while a compact memory turns every turn into a different optimization context. Their multi-context GRPO assigns the trajectory-level advantage to every turn, so the memory writer and the search policy train jointly. The underlying issue matches the credit-assignment problem I keep meeting in multi-turn agents: when the reward lands only on the final answer, the model cannot tell whether a mid-trajectory search contributed information or only added cost.
ITER (Aug 2026) and the earlier LRAT line reach the corresponding conclusion on the retriever side, namely that human click logs are the wrong supervision for agent retrieval. The query an agent issues at step t is conditioned on the original question and on the previous sub-queries. Training a dense retriever on such trajectories, with previously useful documents as redundancy negatives, lifts InfoSeek-Eval and BrowseComp-Plus by 7 to 13% across several agent backbones. I used to think better retrieval mostly meant a stronger embedding model, but these results point to the querying agent and its context as the main factor.
Among training-free methods, HypoSearch (Sep 2026) is the paper I recommend most often these days. Single-trajectory agents commit too early: they reach a fork, pick a branch, and spend most later tool calls gathering support for it. HypoSearch writes a set of lightweight hypotheses, explores them in a bounded number of independent branches, and compares the evidence before answering. On BC-small, Qwen3.5-122B improves from 46.7 to 60.0 while using fewer tool calls than five independent rollouts. The intuition matches tree grafting in multi-turn policy optimization, since both prevent the first plausible path from filling the context.
IGPO (EMNLP 2026 Industry Track, deployed since May) addresses a deployment problem. Product catalogs change continuously, so a search policy cannot be frozen into model weights. The authors separate policy guidelines from inventory facts and report a 3.17% CTR lift in a 14-day A/B test. Academic papers rarely discuss this setting, since many lab search agents assume a static Wikipedia dump while production search runs over continuously updated data.
Structured memory with provenance
Memory is becoming structured because raw trajectories mix unverified content with claims that later evidence has refuted.
ReTree (Aug 2026) organizes search as an evidence tree in which each node stores a bounded summary, source-linked evidence, and a revision history. When new evidence contradicts an earlier claim, ReTree returns to the node that introduced the claim, rewrites it, and prunes the branches built on it. Full-trajectory ReAct uses 1.27 to 1.51 times more per-step context and loses up to 25.6 points of accuracy. The interesting part is less the compression than the observation that compression without provenance can only forget content and cannot repair downstream reasoning.
SearchAtlas (Sep 2026) approaches the same problem as a diagnostic tool. It parses trajectories into evidential query graphs, and the process failures it detects correlate with wrong answers more strongly than the verdicts of an LLM judge reading the raw log. These failures include fragmented support, question constraints that fail to reach the final answer, and unverified parametric knowledge entering the reasoning. Scoring only the final answer string trains agents that use search to confirm answers they already have rather than to gather evidence.
Anthropic's note on dynamic filtering (with Sonnet and Opus 4.6) reaches the same conclusion from industry. Code filters search results before they enter the context window, which raises the average score on BrowseComp and DeepsearchQA by 11% and cuts input tokens by 24%. The bottleneck therefore lies in what the model is allowed to see, and browsing more pages does little to remove it.
Parametric knowledge in search evaluation
Much of what looks like search is the model checking answers it already knows.
LiveBrowseComp (May 2026) is the paper that made me distrust BrowseComp numbers. The authors call the phenomenon Intrinsic Knowledge Dependence: agents answer up to 44.5% of BrowseComp without tools, more than half of their queries come from internal hypotheses rather than retrieved leads, and with the supporting evidence removed they fall below a closed-book baseline. On 335 questions whose answers depend on facts from the previous 90 days, closed-book accuracy falls below 2%, search-augmented scores drop by 25 to 40 points, and the model rankings flip.
The finding concerns evaluation methodology rather than a particular leaderboard. When the training set and the evaluation set cover knowledge already stored in the parameters, the reward favors verification over search, so I would no longer train a search policy on BrowseComp alone.
Benchmarks I would use
I would split evaluation into four separate jobs and report each one instead of a single aggregate number.
| Job | Benchmark | Reason |
|---|---|---|
| Hard multi-hop questions on the live web | BrowseComp / BrowseComp-ZH | Still the default stress test, but contaminated by parametric knowledge |
| Separating retriever and reasoner contributions | BrowseComp-Plus (ACL 2026) | Fixed corpus of about 100K documents. BM25 + Search-R1 reaches 3.86%, GPT-5 55.9%, and GPT-5 + Qwen3-Embedding-8B 70.1% |
| Checking whether the agent actually searches | LiveBrowseComp | 335 questions on facts from the previous 90 days, which removes the parametric-memory shortcut |
| Deep research close to real use | DeepResearch Bench, DR-Arena, LMSYS Search Arena | Long reports and pairwise preferences; DR-Arena builds live information trees and reaches a Spearman correlation of 0.94 with Search Arena |
GAIA, WebWalkerQA, HLE, xbench-DeepSearch, and InfoSeek-Eval remain useful as low-cost regression suites, but I would not select a method based on one of them alone.
BrowseComp-Plus is the benchmark I most want RL papers to adopt. On live-web APIs, a claim such as “we beat Search-R1 by 4 points” is nearly uninterpretable, whereas a fixed corpus separates gains from the retriever, from the policy, and from a luckier SERP.
Open questions I keep returning to
Outcome-only GRPO is underspecified on search trajectories, and Search-R1++ (Feb 2026) already reported GRPO as the least stable optimizer in this setting, with F1 rewards collapsing into answer avoidance unless action-level penalties are added. MemSearcher's multi-context GRPO moves credit back onto turns, and I think that direction is right. I have yet to see a convincing token-level or span-level credit method that can state that the answer is correct because a specific retrieved sentence was read.
Early commitment shows up as a search-specific failure mode, but its cause is general. HypoSearch's fork analysis describes a policy that fails to explore: once the first query is slightly off, the rest of the trajectory mostly gathers support for that query. Branch-then-compare is a harness technique today, and it could equally be trained into the policy itself.
The retriever and the agent should be trained together, and ITER's ablations support this view: the original question plus the previous sub-queries form the most robust query representation, and previously useful documents make the strongest negatives. The problem concerns the interface between retriever and agent as much as either model on its own.
Evaluation has become part of the method: if LiveBrowseComp rankings disagree with BrowseComp rankings, then “SOTA on BrowseComp” measures parametric memory combined with search rather than search itself. I would rather report a pair of numbers, one from the static and decomposable BrowseComp-Plus and one from the live, time-bounded LiveBrowseComp or DR-Arena.
I am not sure the field has settled whether a search agent is a reasoner that sometimes retrieves or a retriever that sometimes reasons. The papers from the last four months lean toward the second view while still evaluating with metrics designed for the first, and this mismatch is the question I keep returning to.
2026.09.12