Authors: Adi Elbaz, Eran Goldstein, Tamar Levy Loboda, Niv Granot, Yuval Belfer
In brief
DeepResearch Bench II (DRB II) is a benchmark that scores deep research agents against 9,430 expert-written rubrics across 132 tasks. We reached #1 with a TotalScore of 64.38 – +3.2 over the previous best reported result. It takes the outputs of weaker agents (leaderboard ranks 7–13, none scored above 45) and merges them.
Figure 1: The DRB II leaderboard on June 24, 2026, with our entry (AI21) at #1, TotalScore 64.38.
A 20 point climb in 6 months: What changed?
Roughly six months ago, the best deep research agent on DRB II scored around 45. Since then, the field did what fields do: it built better agents. Better orchestration, search, decomposition, better models underneath. Every gain came from making a single agent stronger.
We wanted to ask a different question: not “how do we build a better agent?” but “how much more could we extract from the ones that already exist?”
It’s worth asking because of what deep research is. Given a real task (“assess the benefits and risks of investing in EV charging infrastructure,” say), an agent works for minutes, searches the web, and composes a long report. The hard part isn’t the writing. It’s Information Recall: surfacing the specific, verifiable facts the answer depends on, without missing the ones that matter. And Information Recall has a property that writing doesn’t: two mediocre reports rarely miss the same facts. Where one came up short, another likely filled the gap. The facts already exist, scattered across the reports out there; nobody had simply put them together.
So we did. By merging the outputs of agents nobody would call state-of-the-art, we reached the top of the leaderboard without creating a single new agent.
A quick note on the obvious objection that “topping the leaderboard” sounds like “gaming the benchmark”. Here, it’s the opposite: this is boosting, a general ensembling technique, and DRB II is just where we show it. The method only requires several diverse attempts at the task, which can just as easily be your own.
Understanding the task before building anything
Before writing any code, we spent our first effort on analyzing what doing well actually requires.
DRB II measures a research report along three dimensions, each scored as a pass rate over fine-grained rubrics:
Every rubric evaluates the same dimensions, so the mix of rubrics tells you which capability the score mostly reflects (this holds for any metric built from many equally-weighted checks, not just this one). Here, Information Recall mattered most.
Conveniently, the reports we needed were already public. Agents at ranks 7–13 published their full outputs on Hugging Face. We downloaded them, reimplemented the metrics, and confirmed against the leaderboard that we reproduced each agent’s exact scores. We started not from a blank page but from seven complete reports per task, none above 45 overall, the best of them 16 points behind the previous leader’s 61.
Oracle experiments: How much is already there?
We then ran oracle experiments: idealized procedures with ground-truth access that measure how much relevant information these seven weak reports collectively contain, before committing any compute. We tried two. An oracle selector picks, for each task, the single best of the seven reports. An oracle merger combines several reports into one.
Figure 3: Rather than selecting the best single report (0.56), Oracle Merger combines the best rubric-level contributions across multiple reports, achieving a score of 0.70.
The results are startlingly clear: Selecting a single winner per task means you’ll still fall short of current SOTA.
But the merger clears SOTA comfortably, demonstrating that the seven reports collectively hold far more than any one alone. And it’s not just a longer list of facts: because different reports cover different ground, merging them increases Information Recall, supports deeper analysis, and even reads more cleanly.
We also found that these gains scale smoothly: merging only the best 4 reports already clears the leaderboard SOTA, and quality keeps climbing as you add more, creating a dial between cost and quality.
One subtlety makes merging even more powerful. Information Recall is capped (you can’t exceed the facts that exist across all inputs) but analysis isn’t: fusing reports that each saw part of the picture can surface cross-source insight none of the originals contained, and even where facts overlap, different reports reasoned about them differently, so combining their perspectives can sharpen the analysis on its own. The information was there all along, just scattered; it was the act of bringing it together that upped the score.
Figure 4: Oracle-merge quality rises with the number of candidates merged (k). Merging just the best 4 of 7 reports (0.646) already passes the 0.61 leaderboard SOTA, with returns diminishing toward the full-oracle ceiling of 0.70.
The method: Agglomerative pairwise merging
The oracle showed the headroom was real; the question was how to capture it without ground-truth access. Our answer is agglomerative merging: rather than pick or rewrite, we repeatedly fuse pairs of reports into one until a single report remains, inheriting the facts of all of them. We go pairwise because merging fewer at a time preserves the most facts, as we’ll see.
The method has two stages: generate candidate reports, then merge them. Most of the attempts are focused on optimizing the first stage – generating new and improved reports; But for the second stage, any agents producing diverse, reasonable attempts will do, which is why we could source it from public outputs.
For each task, we take the seven reports and run an agglomerative merge, repeatedly combining candidates into one until a single report remains. Each merge is performed by Gemini 3.1 Pro with a deliberately simple prompt: preserve every fact from both inputs, and reconcile conflicts. The output is 132 merged reports, one per task.
This is why aggregation beats hardening a single agent. A single agent commits to one decomposition up front, and everything downstream inherits it: miss a thread and you miss it everywhere. Merging the rollouts of several independent agents sharply raises the odds that some rollout covered each part of the answer. No one agent is good enough, but together they cover the space.
The main lever is how many candidates we combine per step, a clean speed-versus-quality knob. For example, two at a time produces the best Information Recall (with only two reports in context, the model drops almost nothing) but is the slowest, taking six steps to reach a single report. You can reduce steps by adding more candidates (three candidates takes four steps; all seven at once, just one), but accuracy suffers as reports crowd the context. Larger steps lift Presentation but sink Information Recall and TotalScore, and Presentation is too low-weight to compensate.
Since Information Recall carries the score and the task isn’t latency-sensitive, we shipped pairwise, but the knobs are there to be turned: a latency-sensitive deployment could take larger steps and give up only a couple of points for far fewer sequential merges.
Figure 5: More candidates per merge step means fewer steps but lower accuracy: Information Recall and TotalScore fall while Presentation rises. We shipped pairwise (two per step). Scores here are from the merge-step ablation; the final reported result is 64.38.
(One lever we didn’t yet pull but is a promising next direction: Merge order, which uses a trivial similarity function. Merging the most dissimilar reports first could minimize overlap per step.)
Results
Our pipeline scores 64.38: #1 on DRB II, +3.2 over the previous SOTA – built on agents ranked 7th–13th, merging reports that individually scored in the range of between 38 and 45.
What’s next
Building a decent agent keeps getting cheaper. With tools like Claude Code or Cursor, setting up a research agent that produces a reasonable report is close to a commodity, and the number of such agents is only going to grow. The bottleneck is no longer “can you build one good agent?” but “what can you get out of the many you already have?”
The answer is: a lot more than any one of them delivers alone. When success means covering the facts, and the facts are spread across independent attempts, we show that merging agents beats hardening a single agent – even without any frontier model of your own. The number of attempts you merge is a dial: we reached first starting from the cheapest, oldest reports on the board, so beginning from stronger agents, a couple might be enough.
