Deep-Search Agents Score Just 33/100 on Enterprise Data

Enterprise deep search is a single agent answering multi-step questions over many connected data sources at once. Not one clean document store, but the whole sprawl: docs, chat, code, email, transcripts, wikis, and the open web, each behind its own connector. The promise is that you stop searching five systems by hand and instead ask one question that the agent decomposes, researches across sources, and answers with citations.

This is a genuinely different problem from the RAG most teams have shipped. Single-hop retrieval over a homogeneous corpus is close to solved: well-tuned systems answer "what does this document say about X" correctly the large majority of the time. Enterprise deep search breaks that comfort in three ways at once. The corpus is heterogeneous, so one embedding and chunking strategy cannot serve a Slack thread and a scanned PDF equally. The questions are multi-hop, so the evidence for a single answer is scattered across several sources. And access is permission-scoped, so the "right" answer depends on who is asking. Any one of those is manageable. Together they are where accuracy falls off a cliff.

If your mental model of RAG is the single-store version, our primer on agentic RAG and agent-controlled retrieval covers the shift from a fixed retrieve-then-read pipeline to an agent that plans and issues its own searches. Enterprise deep search is that pattern pushed to its hardest setting.

The headline result deserves to be stated precisely, because the precision is the point. On a retrieval pool of 39,190 enterprise artifacts drawn from documents, meeting transcripts, Slack messages, GitHub, and URLs, the best agentic RAG method averaged 32.96 out of 100. Not the worst method. The best one.

Set that against the baseline everyone carries in their head. Single-hop RAG over a clean corpus is the setting where the "RAG is basically solved" narrative comes from, and on standard single-document question answering, strong systems routinely score high. Moving to a heterogeneous, multi-hop enterprise pool cuts the best method to roughly a third of the available points. That is not a tuning gap you close with a better prompt. It is a structural gap between the problem people benchmarked and the problem they actually have.

Two things make the 32.96 figure trustworthy rather than alarmist. First, it is the ceiling across the methods tested, so it is not a strawman weak baseline. Second, the corpus size and source mix are realistic: 39,190 artifacts across five distinct source types is a plausible mid-size company's knowledge sprawl, not a toy set. When the best available approach clears only a third of the bar on a realistic corpus, the honest read is that the category is early, and the vendor demos are running on far friendlier data than yours.

The most useful sentence in the benchmark is the diagnosis: retrieval is the main bottleneck. The agents are not failing because they reason poorly over the passages they receive. They are failing because they never receive the full evidence set in the first place, then reason perfectly well over an incomplete one and produce a confident, wrong-in-part answer.

This distinction changes where you spend. Picture the pipeline as two stages: find the evidence, then reason over it. If the failure is concentrated in stage one, upgrading stage two is spending on the part that already works. A more capable generator writes better prose over the same missing facts. It does not conjure the Slack message the retriever never surfaced. Across the enterprise RAG systems we have built and audited, this is the single most common misdiagnosis: teams see wrong answers, assume the model is too weak, and upgrade the generator, when the trace shows the right chunks were never retrieved.

There is a measurement trap hiding here too. If you only score final answers, retrieval failures and reasoning failures look identical from the outside: both produce a bad answer. You cannot tell whether the agent lacked the evidence or fumbled it. That is why the fix starts with instrumentation, not model selection. Measure retrieval recall (did the supporting evidence make it into context at all) as a separate metric from answer quality (what the model did with that context). Our guide to RAG evaluation and retrieval-accuracy testing lays out how to score those two stages independently, which is the prerequisite for knowing whether your problem is even a model problem.

One benchmark is a data point. Two independent benchmarks pointing the same direction is a pattern. Alongside the Salesforce work, ServiceNow published DRBench, a deep-research benchmark built around 100 tasks across 10 domains, including sales, cybersecurity, and compliance, with evidence spread across productivity software, cloud file systems, emails, chat conversations, and the open web (arXiv 2510.00172).

DRBench is constructed to stress exactly the capability that the 32.96 result says is missing: integrating private company knowledge with public web sources across multi-step queries, then scoring on whether the agent recalled the relevant insights, kept its facts straight, and produced a coherent report. The design choices matter. It is deliberately multi-source, deliberately multi-hop, and deliberately spread across business domains rather than a single clean vertical. That is the same structural difficulty the Salesforce pool captured, reproduced with a different team, different tasks, and different scoring.

The two benchmarks together let you separate signal from noise. If only one lab reported a low score, you might blame their particular corpus or metric. When two independent 2026 benchmarks, built differently, both land on "heterogeneous enterprise retrieval is hard and current methods do not solve it," the conclusion is about the problem, not the measurement. Enterprise deep search is genuinely unsolved at the retrieval layer, and any vendor claiming otherwise is either running on easier data or scoring only the answers.

"Retrieval is the bottleneck" is the diagnosis. Here is the mechanism, because you cannot fix what you cannot name. Four failure modes compound on enterprise corpora.

Source heterogeneity defeats a single embedding strategy. A meeting transcript is long and conversational, a GitHub issue is short and code-dense, a policy doc is structured, a Slack thread is fragmented across dozens of short messages. One chunking and embedding configuration tuned for prose will under-retrieve on code and shred conversations mid-thought. The more source types you connect, the more any single strategy is wrong for most of them.

Multi-hop evidence exceeds single-query retrieval. Real questions rarely have their answer sitting in one chunk. "Why did we miss the Q2 target for account X" might require a forecast doc, a Slack decision thread, and a support ticket. A single embedding query optimizes for similarity to the question, not for assembling a chain of complementary evidence, so it tends to return five near-duplicates of the most obvious source and miss the two others entirely.

Permissions fragment the corpus per user. The correct answer depends on what the asker is allowed to see, so retrieval has to be permission-aware at query time. Bolt access control on after retrieval and you either leak restricted content or silently drop evidence the user was entitled to, which reads as the agent "missing" the answer.

There is no clean ground-truth for recall. On a single curated dataset you know which document is relevant. On a live enterprise pool, "all the evidence a good answer needs" is itself fuzzy and spread across systems, which is why recall is both the thing that breaks and the thing that is hard to measure. This is also why numeric-heavy questions often belong in a different pipeline entirely: when the answer is a calculation over structured records, retrieval-by-similarity is the wrong tool, and our analysis of text-to-SQL accuracy in production covers when to route to SQL instead of embeddings.

These are not model deficiencies. They are properties of the data topology, and they are why single-store RAG numbers do not transfer.

The benchmarks give you a buyer's discipline: do not evaluate a deep-search agent on a demo, and do not evaluate it on final answers alone. Here is the procedure we run before recommending any enterprise search or deep-research platform.

The pattern across these steps is the same one we apply to every retrieval build: treat recall as a first-class, separately measured metric, and refuse to let answer fluency hide a retrieval hole. For the connected decisions on indexing, chunking, and reranking that determine that recall in the first place, our RAG systems pillar guide maps how the pieces fit, and our work on GraphRAG for enterprise data platforms covers one of the few approaches that meaningfully helps with multi-hop evidence by making relationships between sources explicit rather than hoping similarity search stitches them together.

Two independent 2026 benchmarks agree on the finding, so treat it as settled: enterprise deep search fails at retrieval, not reasoning. The best agentic RAG method scores 32.96 out of 100 on a realistic 39,190-artifact corpus, DRBench reproduces the difficulty across 100 tasks in 10 domains, and both point at the same cause. The category is early, and the confident demos are running on data far friendlier than yours.

That makes the action list short and unambiguous. Do instrument retrieval recall as a metric separate from answer quality, because you cannot fix what you cannot see. Do build a multi-hop, permission-aware eval on your own corpus and let it, not a vendor demo, make the buying call. Do scope your sources deliberately instead of connecting everything and hoping. Do invest in the retrieval layer, multi-source indexing, query planning, reranking, and relationship-aware structure, before you reach for a bigger model. And do not upgrade the generator to fix a retrieval problem, because you will pay more to reason beautifully over the same missing evidence.

Deep search over your company's knowledge is a real and valuable capability, and it is coming. But the score that matters is not the one in the demo, it is retrieval recall on your own multi-source corpus, and today that is where these systems live or die. When we build enterprise retrieval for clients, that recall eval is the first thing we stand up and the last authority we defer to, precisely so the decision rests on what the agent can actually find rather than on how well it writes about what it found.