Recent deep research agents primarily improve performance by scaling reasoning depth, but this leads to high inference cost and latency in search-intensive scenarios. Moreover, generalization across heterogeneous research settings remains challenging. In this work, we propose \emph{Search More, Think Less} (SMTL), a framework for long-horizon agentic search that targets both efficiency and generalization. SMTL replaces sequential reasoning with parallel evidence acquisition, enabling efficient context management under constrained context budgets. To support generalization across task types, we further introduce a unified data synthesis pipeline that constructs search tasks spanning both deterministic question answering and open-ended research scenarios with task appropriate evaluation metrics. We train an end-to-end agent using supervised fine-tuning and reinforcement learning, achieving strong and often state of the art performance across benchmarks including BrowseComp (48.6\%), GAIA (75.7\%), Xbench (82.0\%), and DeepResearch Bench (45.9\%). Compared to Mirothinker-v1.0, SMTL with maximum 100 interaction steps reduces the average number of reasoning steps on BrowseComp by 70.7\%, while improving accuracy.
Alex: Welcome to another episode of ResearchPod. Sam, what are we looking at today?
Sam: Today we're discussing a paper from the OPPO AI Agent Team called "Search More, Think Less: Rethinking Long-Horizon Agentic Search for Efficiency and Generalization." It tackles a key issue in AI systems designed for tough search tasks.
Sam: These systems, often called deep research agents, try to get better by doing more step-by-step thinking and tool use—like web searches. But that makes them slow and expensive because each step takes time and computing power. The paper proposes a new way that gathers information faster by working on several things at once. This cuts down the steps needed while keeping or improving results.
Alex: So this is basically about making AI search agents quicker for complicated questions without losing accuracy? Like, instead of one slow path, spreading out the work?
Sam: Yes, exactly. Current agents rely on long chains of single-file reasoning. For tasks needing dozens of facts pieced together, this hits speed walls—like queries taking 150 steps or more. Their approach, called SMTL, shifts to parallel evidence gathering. Think of it like sending out multiple scouts at once instead of one explorer going step by step.
Alex: That efficiency jump sounds meaningful. But why is sequential thinking such a bottleneck for these long searches?
Sam: Imagine tackling a tricky puzzle where you need facts from different corners of the internet—like finding a historical figure who emigrated, lost a child, and requested flowers at a grave. Sequential agents plod through one clue at a time. They often hit context limits in their memory. Parallel workflows break it into side-by-side subtasks. They run searches together, then sync findings. This packs more info per turn and avoids those drags. The paper shows this leads to state-of-the-art results on a benchmark called BrowseComp.
Alex: That puzzle example really shows the drag of going one-by-one. So how did they build the training data to make this parallel approach work across different kinds of searches?
Sam: They start with a big collection of real web pages from various topics, like history or sports. These come from paths where one page links to facts on another—think of it as a web of connected clues. From there, they build a map linking key people, places, or ideas with their relationships. They pull in nearby details to make clusters of info. It's basically a neighborhood map showing who's connected to whom and why.
Alex: Okay, a map of connections makes sense for multi-step facts. But how do they turn that into actual practice questions for the AI?
Sam: They pick a central fact as the target. Then they grab a small connected chunk around it—like scouting the block around your house. They use a step-by-step neighbor search called breadth-first search, which just means checking close connections first. This creates puzzle pieces where you need several links to reach the answer. For precise questions with one right answer, they layer queries from outer edges inward. This verifies no shortcuts leak the solution—like building a riddle that needs all clues. For broader research, they make open questions needing a full summary across the chunk.
Alex: So the data forces parallel checking because the facts are intertwined in these chunks. What about training—did they just feed it these trajectories?
Sam: First, supervised fine-tuning uses teacher AI paths on this data. It caps lengths and favors efficient ones with multiple tool uses per step. Then reinforcement learning rewards correct final answers. It punishes format errors using a method that filters bad runs for stable updates. This builds habits for parallel info grabs under memory limits.
Alex: And for those memory squeezes in long runs?
Sam: When context fills up, it resets by refreshing the plan from recent history. It drops old details but keeps the structure—like summarizing notes before starting a new page. This lets it handle longer tasks in fixed space.
Alex: Okay, so that reset keeps things manageable for really long searches. But how does all this parallel work actually show up—like, does it really cut down the total effort without dropping quality?
Sam: The paper compares it directly on BrowseComp. Their main model reaches higher accuracy using roughly one-third the steps of a baseline like MiroThinker. This comes from packing more tool calls into each step—gathering evidence across subtasks at once.
Alex: One-third the steps but higher scores—that's a clear win on efficiency. What makes the parallel subtasks so much quicker at finding the key info?
Sam: They break the query into several possible side paths right away—like splitting a treasure hunt into teams checking different maps simultaneously. Each team runs its own searches or page checks. Then they share notes periodically to update the main plan and drop dead ends.
Alex: So it's not deeper thinking per step, but broader searching that speeds convergence. Does this hold up across different benchmarks?
Sam: It generalizes well. Their larger model leads or ties top scores across deep search and research tests—like on GAIA—without task-specific tweaks.
Alex: Interesting—broader evidence seems to help both types. What if you give it more steps to work with?
Sam: Ablations show success on hard tasks plateaus early. Extra budget mainly helps explore more paths on tough cases via re-planning. Wider web results per query also lift performance by packing denser info per action.
Alex: Huh, so scaling search width beats just adding length. That ties back to the whole "search more" idea. But to pull off that wider search in parallel, they must have specific tools—what are those?
Sam: The agent uses just two main tools. One queries a search engine for top results—like typing into Google and getting the first few links with short previews. They call this web_search. The other visits a specific page and pulls out a summary tailored to the question—like telling a note-taker to only jot facts about a certain topic. It's named crawl_page.
Alex: So web_search scouts leads broadly, and crawl_page dives deep but stays on track. That setup lets multiple subtasks run without overlap waste?
Sam: Yes. In parallel steps, it fires off several at once, gathering snippets and summaries from different angles before merging.
Alex: Makes sense for speed. Earlier you mentioned data from connected web chunks—how do they ensure those chunks have solid, factual info for training?
Sam: For deep search data, they extract details tied to key people or things strictly from text evidence—like pulling traits that appear word-for-word. No guessing allowed. Then they score descriptions for fact strength: high if packed with numbers, dates, or places. From that, they craft layered questions needing multi-step verification.
Alex: Huh, so fact filters keep training realistic, mimicking tough web hunts. Overall, it's a tight loop from data to tools to efficient runs. But how does the agent actually get instructed to break tasks into those parallel subtasks?
Sam: Detailed system prompts guide every step. First, it splits the overall question into a few clear goals—say, three to five independent pieces that can be tackled side by side. It lists them out right away, like assigning jobs to different team members. Then, in each round, it picks tools for multiple goals at once. It explains why, runs the searches, and notes findings. Periodically, it recaps progress—which goals are done or stuck—and updates the list.
Alex: So it's like a team huddle after scouts report back, adjusting the plan on the fly.
Sam: Yes. For exact answers, the prompt stresses a tight cycle: plan once up front, refine as needed, verify everything. Broader research builds toward a full report with sources cited inline, like a structured essay.
Alex: Huh, so the prompts enforce that team-like sync, turning broad searches into traceable reports. One clear efficiency edge there. So overall, this SMTL approach delivers fewer steps and better results across benchmarks. But no method's perfect; what are the main limits?
Sam: A key reliance is on external tools like the Serper search API and Jina reader service. Performance ties closely to settings like how many top results per search. Since training uses synthetic data from web chunks, it might falter on rare real-world cases not captured there. The paper notes these sensitivities.
Alex: Fair points—tool dependence and data gaps make sense as watch-outs. Practically, could this speed up tools like browser assistants for everyday deep dives?
Sam: Yes, it points toward real-time agents in browsers or workplaces. The step reductions make scalable help feasible without huge costs.
Alex: A meaningful step forward, then, with eyes on those limits. Thanks, Sam—that's a clear picture of efficient search agents.
Sam: My pleasure, Alex. Thanks for listening to ResearchPod.