Evidence at a glance

830 , Approx. 10BrowseComp-Plus
92.05% ,12.61 use /BrowseComp-Plus
87.32%,8.93 use /BrowseComp-Plus
133 ; Outcome 9OfficeQA Pro
9 8 ,1OfficeQA Pro
62% , 56% token, 2.3xNace

The mechanism in one line

InputReduce the input to a workable scale

Compress the visual or contextual input before the main reasoning path.

MechanismSpend compute where it matters

Route or verify the expensive step instead of repeating the full path.

OutcomeEnd with a measurable workflow result

Translate the mechanism into a bounded deployment or evaluation check.

Retrieval Starts Making Choices for the Agent

Nace AI has released Drex for Search, a document retrieval layer intended to help AI agents find evidence in files. It can be connected through a CLI, SDKs, MCP, or REST, and paired with answering models such as GPT-5, Gemini 3.5 Flash, and Qwen 27B. Nace says it is designed for workspaces containing more than a million files and can handle materials including spreadsheets, scans, and audio or video.

The architectural change worth examining is where retrieval's responsibilities end. Traditional RAG is often described as chunk, embed, and retrieve the top results, leaving the model to decide what matters. Drex aims to classify the search first and then narrow down to evidence. Retrieval is no longer just preparing candidate text for a model. It also takes on some of the planning and filtering that would otherwise fall to the agent.

From Question Routing to Pages and Tables

According to Nace, Drex first decides whether a question calls for a quick lookup or for an agent to read documents or query a table. It then narrows the search through folders, files, sections, and pages. In a spreadsheet, it can continue down to a specific table and column. Only the selected pages or tables are passed to the answering model, and the answer includes references such as the file and page.

This approach targets cases where fixed-size chunk retrieval can lose document structure: the answer may be in a scanned PDF, in a table on a particular page, or spread across multiple files. Nace also says ingestion includes OCR and layout processing, preserves spreadsheet structure, and uses a knowledge graph to connect information across files. If those steps work on the target corpus, an agent may need fewer broad searches followed by context-heavy interpretation. But these are vendor-described design choices, and the available materials do not provide an independent audit of performance across document types.

What the Benchmark Numbers Show—and Leave Open

On BrowseComp-Plus, Nace reports 92.05% accuracy for Drex paired with GPT-5, with an average of 12.61 search calls per question. The result ranks second among 86 entries. The benchmark contains 830 multi-hop questions over a fixed collection of about 100,000 web documents. The top entry scores 95.18% accuracy at 209.27 calls per question. Nace also reports 87.32% accuracy with 8.93 calls for its single-pass result, which it says is the best among entries using fewer than ten calls.

The comparison suggests a specific trade-off: accuracy close to the leading result with substantially fewer search calls. It does not, by itself, establish lower end-to-end cost or latency. The public materials do not define how a search call is counted or provide enough evaluation detail to independently reproduce the full configuration and results. Nace also reports a 77.5% R@1 score on VisDocAgentBench and lists it as first. These figures are useful starting points for validation, not guarantees of performance on other corpora.

Fewer Steps Do Not Mean Every Answer Is Better

OfficeQA Pro offers a closer comparison with agent workflows. It contains 133 questions, and Nace's results table lists nine agent-and-model configurations. With Drex, all nine show fewer agent turns, while accuracy rises in eight and falls in one. For example, Gemini CLI with Gemini 3.1 Pro improves from 54.9% to 61.7% accuracy while turns fall from 22.9 to 10.4. Codex with GPT-6 luna moves in the other direction on accuracy, from 54.9% to 53.4%, even as turns drop from 16.8 to 11.3.

The evidence therefore supports reduced agent back-and-forth more clearly than a claim that every configuration gets more answers right. There is also an unresolved discrepancy: Nace's FAQ says it tested ten agent setups and reports a 57% reduction in input tokens, while the results table lists nine configurations. The page does not explain the difference. Evaluations should track accuracy, agent steps, tokens, and end-to-end latency together, with each metric tied to its exact configuration rather than applying an aggregate improvement claim to every model pairing.

Deployment Choices Come with Evidence Boundaries

For engineering teams, Drex's appeal is not only its retrieval method but its attempt to package document navigation as a service an agent can call. Nace offers managed cloud, dedicated cloud, deployment in a customer's AWS or Azure account, and on-premises or air-gapped options. Workspaces can use uploaded files or the customer's S3 or Azure Blob storage. The system also says it isolates each workspace's index and knowledge graph and returns citations to files, pages, rows, or timestamps.

That makes leaderboard scores only one part of the evaluation. Technical leads should test real workspaces containing scans, spreadsheets, and cross-file questions, verify that citations lead back to the source evidence, and compare accuracy, call counts, and total latency with the same answering model. They should also confirm that data residency, zero-retention options, and deployment modes fit their governance requirements. If the main pain is repeated agent searches and context consumption, Drex merits a parallel trial. If the requirement is a reproducible accuracy gain, the public evidence is not enough to skip an in-house benchmark.