---
title: "Drex searches. Agents reason."
description: "Drex for Search unifies retrieval and judgment at each search step. Recursive Drex calls navigate the workspace to locate evidence, so agents can focus on reasoning from it."
canonical: "https://nace.ai/research/drex-searches-agents-reason"
updated: 2026-11-01
---

# Drex searches. Agents reason.

> Drex for Search unifies retrieval and judgment at each search step. Recursive Drex calls navigate the workspace to locate evidence, so agents can focus on reasoning from it.

Research · Nov 1, 2026 · Nace.AI

## TL;DR

An agent searching a filesystem can spend a surprising amount of its work deciding where to look. List the files. Search for a phrase. Read a match. Discover the wrong document or version. Search again. Each step asks the reasoning model to make another navigation decision, and each tool result eats up its context.

For instance, the answer to a query may hide in three rows of a table, on one page of a PDF, several folders deep. Locating those rows can take far more agent turns than reading them.

To solve this, we’re releasing **Drex for Search**. [Drex](https://nace.ai/drex) is Nace’s System 1 decision LLM, built for lightning-fast, accurate decisions at high frequency. It is among the top performers on the [Artificial Analysis Decision Index](https://artificialanalysis.ai/evaluations/artificial-analysis-decision-index).

**Drex for Search unifies retrieval and judgment into a single step.** We delegate workspace navigation to Drex: organize the workspace as a tree, then use recursive Drex calls to judge which branches matter and locate evidence within them. This replaces the agent’s loop of `ls`, `grep`, and exploratory reads with precise pointers, so the agent can make surgical reads of the source.

In our evaluations on OfficeQA Pro and CUAD, Drex for Search reduced main-agent model calls by about **53% and 58%**, respectively, compared with raw harnesses, and main-agent input tokens by about **57% and 43%**. Mean answer scores were higher on both datasets. We also evaluated the same harness/model configurations with a third-party hybrid-search extension: Drex for Search used fewer main-agent iterations in every completed comparison. These workload figures cover the main agent’s work, excluding Drex inference.

## How Drex for Search navigates a workspace

Drex for Search works over a Nace Document Intelligence (NDI) workspace. Files are ingested before search, making their internal structure available for navigation. A PDF exposes sections and source pages; an Excel workbook exposes named sheets, readable content, and queryable tables. Every location stays connected to its source.

*The structure inside your files (illustrative workspace).*

- reports/annual_2023.pdf (PDF document). Logical sections, each a card linked to its source pages: Management discussion (Business performance, trends, and the drivers behind the reported results.); Income statement (Revenue, expenses, and earnings for the reporting period.); Notes (Accounting policies and supporting disclosures for the financial statements.)
- ledgers/gl_2023.xlsx (Excel workbook). Named sheets, each a table card queried by column: GL (Date, Account, Amount); Trial balance (Account, Debit, Credit); Revenue by month (Period, Revenue)

The structure of the ingested NDI workspace is crucial to Drex for Search: it gives Drex a map to navigate recursively, narrowing from files to the evidence the agent needs.

### A cascade of small decisions

Now consider a workspace containing annual reports, contracts, and a ledger. Take the query **“What was total revenue for fiscal 2023?”** as an example. Drex for Search then works as shown below.

*Inside the search, a scripted example with illustrative scores. Question: “What was total revenue for fiscal 2023?”*

| Stage | What happens | Scope | Drex calls (total) |
| --- | --- | --- | --- |
| 00 Workspace | See the entire search space. Folders contain files; documents fan out into sections and pages; workbooks fan out into tabs and columns. Each call sees: Cards built from ingestion metadata: names, dates, summaries, headings, and table profiles. Grey squares are pages. Outlined squares are columns. The 58 extra archive files are collapsed; the rest of the hierarchy is visible. | 67 files · 9 representatives shown | 0 (0) |
| 01 Partition | Put related files into groups. The reports folder becomes three year groups. Contracts and ledgers remain separate branches. Each call sees: No model judgment at this step. Existing structure and metadata define the groups. Group cards summarize their members. The next step can judge an entire branch without opening every file inside it. | 67 files → 5 groups | 0 (0) |
| 02 Groups | One Drex call judges each group. Keep the promising branches. The archive and contracts close here; their contents never reach the later stages. Each call sees: The question plus one group’s dates, titles, file kinds, catalog facts, and sample filenames. The example’s keep line is 0.40. The following report year is retained separately for comparisons. A parallel population check asks whether all matching files are needed. | 5 groups → 3 retained | 6 (6) |
| 03 Files | Judge files only inside the kept groups. The three 2023 reports get independent judgments. Singleton groups pass their one file through without another call. Each call sees: One file card: name, issue date, summary, section briefs, and catalog facts, together with the question. The Q1 report falls below the illustrated keep line. The annual report and Q3 report survive. Separate scores let multiple useful editions remain in play. | 5 candidate files → 4 retained | 3 (9) |
| 04 Sections | One call ranks the sections of each kept document. Now the retained documents expand. Each black bracket is one Drex call over a sibling set, with “none” as an option. Each call sees: The parent file and its section cards: summaries, keywords, page spans, and table titles. Keep useful sections within each document. The notes drop out. The workbook follows a separate table path, shown later. | 8 sections → 6 retained | 3 (12) |
| 05 Pages | Rank page cards before reading page text. Six retained sections fan out into 49 page cards. Their scores and the leaf budget select 40 pages for the next stage. Each call sees: The parent section plus each page’s number, headings, table titles, periods, and short preview. Solid green marks the strongest survivors; pale green fills the remaining budget. The nine empty squares are outside the 40-page budget. | 49 page cards → 40 text candidates | 6 (18) |
| 06 Page text | Drex reads the 40 surviving page candidates. The search reaches source text. Each outlined page square is one judgment; the strongest pages become evidence locations. Each call sees: Bounded text from one page, with its document and section context, plus the question. Twelve pages are located. Four receive opening excerpts, marked with an amber outline; the others receive compact previews or pointers. The agent can read the referenced source precisely. | 40 text candidates → 12 page locations | 40 (58) |
| 07 Tables | Follow the workbook down to useful columns. Three ledger tabs are judged. The wide GL tab gets 14 column judgments; narrow tabs expose their columns directly. Each call sees: A table card has its schema, row count, summary, and samples. A column judgment sees its name, type, statistics, and sample values. Only the kept ledger is expanded; fees.xlsx stays closed. The table path can run alongside the document path—it is shown separately here for clarity. | 3 tables · 14 columns surfaced | 17 (75) |

*Adapted from the original cascade walkthrough. Nine file representatives stand for 67 files; 58 archive files stay collapsed. Scores, thresholds, and survivors are scripted to explain the mechanism. The 75 logical calls are this illustration’s accounting, not benchmark usage or sequential network rounds.*

At each level, Drex judges what is relevant and where to look next. Repeating this process through the workspace makes the search recursive, leading to precise page, line, or table references the agent can use. Each stage narrows where to look next, keeping detailed inspection focused on promising branches. Independent decisions can run concurrently, so the main agent does not need a separate reasoning turn for every candidate considered.

The agent receives focused evidence and precise source references. It can then make surgical reads, reason over what it finds, and produce an answer grounded in the source.

## More efficient search on real documents

We measured main-agent workload and answer quality on OfficeQA Pro (financial reports) and CUAD (commercial contracts). The charts compare the same harness, model, and reasoning effort on the same questions, with three ways to access the documents:

- **Raw harness:** the agent used its ordinary file tools over the text published by the datasets—OfficeQA’s official parsed text and CUAD’s full-contract text files.
- **Raw harness + hybrid search:** the agent kept those file tools and gained [pi-knowledge-search](https://github.com/samfoy/pi-knowledge-search), a third-party search extension, over the **same parsed corpus**. We integrated the exact same extension across all six harnesses: pi loads it directly, while Claude Code, Codex, Hermes, OpenCode, and Gemini CLI access its unchanged search and file-read tools through an MCP adapter, using the same corpus index. We used version 1.3.8, with `text-embedding-3-small` embeddings at 512 dimensions, BM25 keyword search, and reciprocal rank fusion. Each agent chose when to use the extension.
- **Drex for Search:** the corpus was already ingested into our Nace Document Intelligence (NDI) workspace. Drex supplied evidence locations for the agent to read or query.

For each dataset, we created and ingested the NDI workspace **once**, before evaluation, and reused it across all question-answering runs. The hybrid-search index was also built once and reused. Workspace ingestion and index construction are outside the reported per-query measurements. The raw arm likewise starts with the published text already available.

An **iteration** is one request to the main agent’s model. **Input tokens** count everything sent to that model across its requests, including cached and repeated context. Workload reductions compare the sums of the per-configuration means within each dataset.

### OfficeQA Pro

[OfficeQA Pro](https://github.com/databricks/officeqa) asks questions over 697 U.S. Treasury Bulletin documents spanning 1939–2025. For the Drex for Search arm, the scanned PDFs were ingested into the NDI workspace before evaluation. The hybrid-search runs use the same web-enabled setting as the original raw runs.

Against the raw harnesses, across six harnesses and ten harness/model/effort configurations, Drex for Search reduced recorded main-agent iterations by **53%** and input tokens by **57%**. Both measures fell in every configuration. Accuracy rose in eight configurations and fell in two; mean accuracy moved from **59.3% to 61.9%**.

All ten hybrid-search configurations have finished. Drex for Search used fewer main-agent iterations and input tokens than hybrid search in all ten, with higher accuracy in seven and lower accuracy in three.

### CUAD

[CUAD, the Contract Understanding Atticus Dataset](https://huggingface.co/datasets/theatticusproject/cuad), is a public collection of commercial contracts annotated for contract review. Our evaluation asks contract-clause questions over **200 contracts**, using six harness/model configurations. Answer scores exclude failed runs.

We retain the original raw and Drex for Search results, replacing only raw Gemini CLI with Gemini 3.1 Pro with the new control run, which scores **88.7**. The hybrid-search runs use the same questions, on a different harness build from the original evaluation.

Against the raw harnesses, Drex for Search reduced main-agent iterations by about **58%** and input tokens by about **43%**, calculated from the report’s rounded per-configuration means. Both measures fell in all six configurations. Answer scores improved in five configurations and fell slightly in one; the mean rose from **87.9 to 90.3 out of 100**.

Compared with the hybrid-search arm, Drex for Search used fewer iterations in all six configurations and had higher answer scores in five. The agents could still use ordinary file tools, and the extension was used selectively; this evaluates access to a hybrid retriever within an agent loop.

**OfficeQA Pro** (10 configurations). Raw harness / hybrid search / Drex for Search, per question.

| Harness | Model | Effort | Accuracy (%) | Main-agent iterations | Main-agent input tokens (k) |
| --- | --- | --- | --- | --- | --- |
| pi | Opus 5.5 | medium | 65.4 / 67.7 / 68.4 | 7.7 / 7.2 / 3.7 | 191 / 107 / 72 |
| pi | Qwen3.8-27B | medium | 43.6 / 48.9 / 45.9 | 24.3 / 17.0 / 11.1 | 1,292 / 758 / 506 |
| Codex | GPT-6 sol | max | 66.2 / 63.2 / 70.7 | 14.3 / 15.4 / 8.6 | 710 / 733 / 377 |
| Codex | GPT-6 luna | max | 54.9 / 55.6 / 53.4 | 16.8 / 15.9 / 11.3 | 932 / 873 / 580 |
| Claude Code | Opus 5.5 | max | 66.5 / 67.7 / 69.9 | 18.5 / 17.8 / 9.1 | 906 / 871 / 475 |
| Claude Code | Sonnet 5.5 | max | 69.2 / 68.4 / 66.9 | 29.8 / 25.5 / 13.3 | 2,362 / 2,035 / 939 |
| Hermes Agent | Opus 5.5 | medium | 64.3 / 66.9 / 68.4 | 8.5 / 8.0 / 3.7 | 217 / 176 / 110 |
| Hermes Agent | Qwen3.8-27B | medium | 56.4 / 55.6 / 60.2 | 20.1 / 14.8 / 6.5 | 1,202 / 782 / 364 |
| OpenCode | Qwen3.8-27B | medium | 51.1 / 45.9 / 53.4 | 23.7 / 23.0 / 10.0 | 1,823 / 1,745 / 706 |
| Gemini CLI | Gemini 3.1 Pro | medium | 54.9 / 52.6 / 61.7 | 22.9 / 19.6 / 10.4 | 951 / 954 / 417 |

*The original raw and Drex for Search results are retained. Hybrid search was evaluated on the same questions with web tools on, as in the raw runs, using a different harness build.*

**CUAD** (6 configurations). Raw harness / hybrid search / Drex for Search, per question.

| Harness | Model | Effort | Answer score / 100 | Main-agent iterations | Main-agent input tokens (k) |
| --- | --- | --- | --- | --- | --- |
| pi | DeepSeek V4.1 Flash 1017 | medium | 90.0 / 90.7 / 89.3 | 11.8 / 6.6 / 3.3 | 209 / 118 / 38 |
| Codex | GPT-6.1 terra | medium | 91.7 / 92.0 / 93.0 | 4.6 / 5.5 / 2.3 | 83 / 72 / 40 |
| Claude Code | Sonnet 5.5 | medium | 87.3 / 88.3 / 90.2 | 5.5 / 4.1 / 1.6 | 66 / 45 / 27 |
| Gemini CLI | Gemini 3.1 Pro | medium | 88.7 / 88.0 / 89.7 | 4.3 / 4.4 / 2.8 | 83 / 83 / 51 |
| OpenCode | Qwen 3.8 27B | medium | 83.0 / 84.0 / 89.3 | 7.3 / 4.4 / 2.3 | 109 / 66 / 30 |
| Hermes | MiniMax M3.1 Flash | medium | 86.7 / 87.3 / 90.0 | 12.6 / 9.2 / 7.0 | 456 / 173 / 388 |

*The original raw and Drex for Search results are retained, with raw Gemini CLI replaced by the new control run. Hybrid search was evaluated on the same questions using a different harness build. Scores exclude failed runs.*

## From grep and RAG to Drex recursive decisions

Grep is a workhorse of agentic file search because it finds matching text quickly and predictably, especially for known identifiers and phrases. Hybrid retrieval adds another useful route: embedding search can find passages with different wording, while keyword search preserves exact matches.

With either grep or a RAG retriever, search in an agent system still follows a two-step process: the main agent writes a bash command or a retrieval request, then reasons over the results. Choosing what to search for and writing that command or request takes a model iteration.

When the results return, the agent reads them, judges what matters, and decides what to open or search next in a subsequent model iteration. If a match belongs to the wrong document, version, or period, the cycle repeats. Retrieval and judgment remain separate steps, coordinated by the main agent. A better retriever can improve the candidates; the agent still carries the query-and-inspection loop in its turns and context.

**Agent-led exploration.** With file tools or a RAG retriever.

1. Write a grep command or retrieval query
2. Read and judge the returned candidates
3. Choose what to open or search next
4. Read, calculate, and answer

**With Drex for Search.** Navigation runs in the decision layer. Drex: Groups → files → sections → pages.

1. Read located evidence
2. Calculate, reconcile, and answer

*Conceptual workflows. Each line is an action, not a measured model turn. The main agent receives the output of the cascade without carrying every navigation decision in its history.*

Some questions also leave the agent to discover how the source expresses the answer. A contract might describe renewal terms using different wording from the question. In OfficeQA Pro, a matching table can still belong to the wrong issue or reporting period. Finding a string and choosing the right evidence are different decisions.

**Drex for Search unifies retrieval and judgment into a single step.** At each level, Drex uses the question and the workspace’s structure to find and judge candidates together. Recursive Drex calls repeat that combined step through the workspace, replacing the main agent’s cycle of writing search commands and inspecting intermediate results. The agent can then focus on surgical reads, interpreting the evidence, reconciling figures, and answering the question.

We believe that combining retrieval and judgment within search—and moving navigation out of the main agent’s loop—helps explain the efficiency improvements we observe with Drex for Search on OfficeQA Pro and CUAD.

## Drex searches - Agents reason

In a typical agentic search loop, grep or a retriever returns candidates, then the agent reads them and judges what to pursue. **Drex for Search merges retrieval and judgment into a single step.** Fast, inexpensive Drex calls repeat that combined step through the workspace, leading the agent to precise source references for surgical reads.

This is a promising direction for file search and filesystem agents: decision models find where to read; reasoning models turn that evidence into answers. **Drex searches. Agents reason.**

## For agents

- [Drex API guide](https://nace.ai/drex.md): the decision model: request shape, question types, benchmarks and deployment, as markdown
- [Decision endpoint](https://console.nace.ai/v1/systemone): POST with model "drex-latest", a state string and typed questions (choice, noul, score); https://console.nace.ai/v1/models lists checkpoints
- [Document endpoints](https://console.nace.ai/v1/documents/{parse|split|classify|extract|ground}): POST a source (a public URL, an uploaded workspace file or a finished parse job) and poll GET https://console.nace.ai/v1/documents/jobs/{id}; the same key and credit as decisions
- [Console](https://console.nace.ai): API keys, the playground, usage and billing; send `Authorization: Bearer $NACE_API_KEY` on every request
- [Console docs](https://console.nace.ai/docs): quickstart, question types, the document routes, errors, limits and pricing
- [Nace Document Intelligence](https://nace.ai/perception.md): the Perception series: parse, split, classify, extract and ground any file type with a location on every value
- [Drex for Search](https://nace.ai/drex/search.md): Drex for Search: decision-powered retrieval for agents, Drex finds the page, cited search through the CLI, SDKs, MCP and REST, and the public benchmark ranks
- [Use cases](https://nace.ai/use-cases.md): every Drex use case with its proof figures: browser use and search for developers, enterprise finance teams and professional firms
- [Developers](https://nace.ai/developers.md): The execution layer for agents: Perception, Decision and Search behind one key, the Drex Max frontier, install steps, a scripted agent session and the four deployment boundaries
- [Site index](https://nace.ai/llms.txt): every page on nace.ai; append `.md` to any page URL or send `Accept: text/markdown` for the markdown version