Merging Weak Agents Into A State Of The Art Deep Researcher

Tipping the scales: Merging weak agents into a state-of-the-art deep researcher | AI21

Skip to Main Menu

Skip to Main Content

Skip to Footer

Back to Blog

-->

Back to Blog

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:

Figure 2: DRB II grades each report on three dimensions. Information Recall dominates the rubric count (52.9 per task vs. 12.8 for Analysis and 5.7 for Presentation), so it drives most of the score.

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: Four reference points on the same seven reports. Even an oracle selector that picks the best report per task with perfect foresight (0.56) falls short of the 0.61 leaderboard SOTA; only merging (0.70) clears it.

The results are startlingly clear: Selecting a single winner per task means you’ll still fall short of current SOTA.

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.

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.

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...