Designing Search for AI Agents: How They Query and What to Return (2026)

Search for AI agents is not a “just add a vector database” problem. Agents query and read results differently from humans.

You need to design how they search (function calls / commands / code generation) and what you return (chunks / raw corpus / bounded workspaces) as one system.

Who this is for

• Engineers building RAG or agent platforms
• Operators running search/IR infrastructure
• Product owners who expose documentation or corpora to agents

Independent evidence comes from Hornet, Mintlify, Perplexity Research, arXiv, and VentureBeat. Speaker Deck / Hatena are discovery signals only—not grounds for architecture choices.

---

What you will learn

nn

---

Human and agent search behavior are not the same

Even on the same engine and index, agent query mix differs from human traffic. Capacity planning is a mix plan, not only a volume plan.

Query length and operators

Independent measurements from Hornet (Jo Kristian Bergum, 2026-06-03) compare human and agent query shapes on the same class of engine workload.

• Human (AOL-style): median about two terms
• Agent (BrowseComp-style GPT-5): median about ten terms—beyond the human p99
• Operators: agents also use denser phrase and site: operators

---

Serving-capacity swing

On 100M documents with the same BM25 top-10 setup, serving capacity swings sharply:

• Human (AOL): about 3236 QPS at p99 ≤ 500ms
• Agent (BrowseComp): about 384 QPS under the same budget
• Ratio: roughly 8.4×

---

How results are read

Reading style matters too.

• Humans skim from the top, skip irrelevance, and keep position bias
• Agents often pull every returned document into context
• Irrelevant hits can crush accuracy and increase lost-in-the-middle failures

---

Capacity-planning implications

Implication: “agents grew, so double QPS” is incomplete.

• Prefer contracts that tolerate long queries, operators, and multi-step search
• Observe per-query cost and tool-call counts
• Related operational framing: AI agent loops and harness design

Source: Hornet — Agentic query workloads change retrieval cost (as of June 2026)

---

How agents search — MCP, command exploration, Search as Code

There are at least three interface families. Ease of adoption trades off against control granularity.

Throw a query (function calling / MCP)

Expose search as a tool and return fixed-pipeline top-k. This is the lightest path, but control stays inside tool arguments. Top-k results stack into context on every turn, which often pollutes long-running tasks.

---

Explore with commands (grep / ls / cat / find)

Treat the corpus like a codebase.

Source

---

Mintlify virtual filesystem

Mintlify (Dens Sumesh, 2026-03-24) replaced chunk-only RAG limits (cross-page reasoning, exact syntax) with ChromaFs: a virtual filesystem over Chroma exposing UNIX vocabulary via just-bash.

---

Reported operating points

• p90 session boot: about 46s (sandbox clone paths) → about 100ms (ChromaFs)
• Near-zero marginal compute by reusing the existing DB
• Grep path: coarse filter → prefetch → in-memory fine filter
• Read-only mounts and path-tree pruning for RBAC

---

Limits and evaluation caveats

Limits remain. Relevance is weak; vocabulary mismatch misses.

arXiv:2605.15184 (Sen et al.) found:

• Grep was often more accurate than vector retrieval in their agent-loop comparisons
• Final scores still depended heavily on harness and tool-result presentation (inline vs file-based)

---

Assemble pipelines in code — Search as Code (SaC)

Perplexity Research (2026-06-01) proposes exposing retrieve/rank/filter/fan-out/aggregate primitives as an SDK so agents generate task-specific pipelines in a sandbox.

---

Why monolithic contracts struggle

Monolithic query→pipeline→resultset contracts struggle when a single task issues hundreds to thousands of retrievals:

• Coarse context
• Unused domain knowledge
• Context pollution

---

What moves out of model context

With Search as Code, intermediate state stays in the execution environment; only distilled results enter the model context. The tradeoff is operational cost:

• SDK boundaries
• Sandbox audit
• Operator education

Decide in one line: Is MCP top-k enough, is exact-string exploration primary, or do you need code-assembled pipelines?

---

Sources (2026)

• Mintlify
• Perplexity SaC
• arXiv:2605.15184

---

What to return — chunks, DCI, bounded workspaces

Return shape is the unit of reading and the visible boundary. Top-k chunks are predictable, but early filtering is irreversible. This is the same class of problem as moving beyond naive RAG for knowledge operations (related: Agent Search beyond RAG limits).

Return chunks (classic RAG)

Inject only the engine’s top-k chunks. Token load is predictable; the visible world freezes at chunk time. Exact strings, sparse clue combinations, and multi-step hypothesis revision are brittle—the core DCI critique.

---

Hand over the corpus — DCI (Direct Corpus Interaction)

arXiv:2605.05242 (Li et al., 2026-05-03) defines DCI: agents explore a raw corpus with grep/file reads/shell without embeddings, vector indexes, or retrieval APIs.

• Claim: early top-k discards evidence agents cannot recover
• Reported strength: BRIGHT/BEIR and BrowseComp-Plus-style multi-hop settings

---

Field write-up (VentureBeat)

VentureBeat (Ben Dickson, 2026-05-22) describes a BrowseComp-Plus case moving from semantic retrieval to DCI:

• Accuracy example: 69%→80%, with lower API cost
• Scale fragility: 100k→400k docs (accuracy drop, more tool calls)
• Near-term production pattern: hybrid semantic recall + DCI precision

---

Hand over a context boundary — Dr-DCI / RISE

---

Dr-DCI

Dr-DCI (arXiv:2606.14885, Lu et al.) treats retrieval as a workspace-expansion action, then runs DCI only inside the local workspace.

• BrowseComp-Plus peaks of 71.2–73.3%
• Lower tool/time/cost than raw DCI
• Stability from 100K–10M where raw DCI becomes unstable

---

RISE

RISE (arXiv:2606.06880, Zhuang et al.) reframes retrieval as building a bounded interaction space, not only top-k for the LLM window. BM25-built spaces plus shell-style navigation:

• BrowseComp-Plus: roughly matches pure DCI (~78%) at about 1/4 cost in one reported setting
• At 1M docs: RISE-BM25 reaches 81% while unrestricted DCI degrades

---

Symmetric constraints

Constraints are symmetric.

• Raw DCI: tends toward whole-corpus scans and latency/timeout risk at scale
• Bounded spaces: never recover documents missed by the first boundary
• Ceiling: boundary quality

Three selection questions: Do you need exact match? Will the corpus exceed ~100k and keep growing? Can you accept irreversible boundary misses?

Sources (2026):

• arXiv:2605.05242
• VentureBeat
• arXiv:2606.14885
• arXiv:2606.06880

---

Comparison matrix (2026): choosing how agents search × what they receive

There is no universal winner. Pick one cell under your constraints. Because agent query mix can swing serving capacity (Hornet ~8.4×), changing how/what also changes per-query cost and tool-call volume, not only QPS.

How agents search — MCP and commands

Axis	Best when	Strength	Weakness / caution	Main independent basis
MCP / function top-k	Fastest ship; reuse engine ranking	Ranking/paraphrase stay in the engine; lightest build	Weak control beyond args; top-k pollutes context	Monolithic contract critique (Perplexity SaC)
Command exploration (grep/VFS)	Exact strings; stepwise docs-as-code navigation	Familiar vocabulary; agent controls read volume; Mintlify boot/cost wins	Weak relevance; vocab miss; harness-sensitive	Mintlify; arXiv grep vs vector

---

How agents search — Search as Code

Axis	Best when	Strength	Weakness / caution	Main independent basis
Search as Code	Task-specific pipelines; keep intermediates out of context	Strategy as code; sandbox-side intermediate work	Highest SDK/sandbox ops and education cost	Perplexity SaC

---

What to return — chunks and raw DCI

Axis	Best when	Strength	Weakness / caution	Main independent basis
Return: chunk RAG	Predictable injection; huge corpora	Scale and cost forecasting	Irreversible early filter; brittle exact match	VentureBeat / DCI framing
Return: raw DCI	Small–mid corpora; citation and re-scan required	No offline index lag; strong verify/compare	Latency/instability/timeouts at scale	arXiv DCI; VentureBeat scale fragility

---

What to return — bounded workspaces

Axis	Best when	Strength	Weakness / caution	Main independent basis
Return: bounded WS (Dr-DCI/RISE)	Large corpora still need raw ops	Two-stage recall+precision; reported cost/stability	Boundary misses are final; more workspace ops	arXiv Dr-DCI; RISE

Sources: corresponding Hornet / Mintlify / Perplexity / arXiv / VentureBeat rows (2026)

---

Short decision rules

1. Literal/error-code search dominates → prefer command or DCI-class paths
2. Corpus will scale hard → avoid raw DCI alone; prefer bounded or hybrid
3. Team cannot run sandbox/SDK ops → defer SaC; start MCP + staged commands
4. Evaluate with harness fixed (grep vs vector can flip with presentation mode)

You can combine these with context-reduction tooling such as codebase-memory-mcp. In all cases, what enters context still dominates quality and cost (related: context design over prompt tricks).

---

Adoption checklist and next actions

Translate architecture choice into work you can finish this week. Do not freeze production design on bookmark counts or a single English benchmark score.

Signals you should strengthen retrieval interfaces

• Multi-page or exact-syntax tasks fall out of top-k chunks
• Agents search dozens of times per task and pollute context
• Corpus churn makes offline index freshness the bottleneck
• Human QPS plans break when agent load lands on the same stack

---

Suggested staged order

1. Freeze 5–10 representative tasks with outcome-level success criteria
2. Classify current top-k RAG/MCP failures (early drop / pollution / vocab miss / cost)
3. If literals dominate, PoC command or DCI on a narrow corpus
4. If corpus >100k and growing, put Dr-DCI/RISE-style bounded workspaces on the design board
5. Hybrid: semantic recall → grep/read precision inside the boundary
6. Dashboard query length, operators, p99, tool calls, tokens (mix plan)
7. Only then consider SaC—after SDK boundaries and sandbox audit exist

---

Same-day checklist

• ✓ Split tasks into “exact match required” vs “semantic recall is enough”
• ✓ Write expected searches/task and token/latency budgets as numbers
• ✓ Declare whether returns are chunks-only or allow raw reads
• ✓ Estimate corpus size now and in 12 months
• ✓ Answer Yes/No: can failures re-explore outside primary retrieval?
• ✓ Fix harness and tool-result presentation (inline vs file) before scoring
• ✓ Pick one metric that separates human vs agent query mix
• ✓ Confirm security: read-only, path prune/RBAC, sandbox exfil boundaries

---

What not to do

• Decide architecture from Hatena popularity or a slide deck retelling alone
• Freeze production mode from one English benchmark score
• “Just double QPS for agents” without measuring mix and per-query cost

---

Author Perspective

From an operations lens, the first priority is not “grow the index because agents arrived,” but making query mix and return contracts measurable.

• MCP top-k is the shortest path, yet long tasks often pay later in context pollution
• If exact strings dominate, evaluate command/VFS or DCI on a narrow scope
• If the corpus will grow, put bounded workspaces into the design early

Public benches and single field write-ups are directional—overwrite them with your own outcome success rate and tool-call budgets.

---

FAQ

Q1. Is a vector database enough for agent search?

• Often no
• Dense retrieval is strong for semantic recall, but exact strings, sparse clues, and multi-step hypotheses can bottleneck on early top-k (DCI / VentureBeat)
• Consider hybrid designs

---

Q2. Is grep enough?

• It depends
• Some studies report higher accuracy for grep than vector in agent loops, but scores still hinge on harness and result presentation (arXiv:2605.15184)
• Vocabulary mismatch remains a failure mode

---

Q3. How do DCI and bounded workspaces differ?

• DCI explores the raw corpus directly
• Bounded designs (Dr-DCI/RISE) first build a workspace, then run precise ops inside it
• At scale, bounded spaces are often more stable and cheaper—but boundary misses are unrecoverable

---

Q4. When should we consider Search as Code?

• When fixed top-k contracts pollute context with intermediates and you need task-specific fan-out/aggregation
• When your team can absorb SDK + sandbox operations (Perplexity)

---

Q5. What should we measure first?

• Outcome success on fixed tasks
• Searches per task, p99, tokens
• Exact-match recall
• On infra, split human vs agent query-mix QPS

---

Q6. Can we decide from Hatena or Speaker Deck alone?

• Use them as discovery signals
• Ground numbers, procedures, and limits in independent non-Hatena sources such as Hornet, Mintlify, Perplexity, arXiv, and VentureBeat

---

Related articles:

• 13549
• 13550
• 13580

Summary

• Agent search differs in query mix and reading style; both serving cost and accuracy move.
• The core design choice is the combination of how agents search and what you return.
• MCP is light but pollution-prone; command/VFS favors exact exploration; SaC maximizes flexibility and ops cost.
• Return shapes trade predictability (chunks), recoverability (DCI), and scale stability (bounded workspaces).
• Next actions: classify tasks → measure failure modes → narrow PoC → hybrid/boundary design → mix observability. Keep popularity as discovery only; decide with independent numbers and your own eval harness.