When an LLM agent searches a document corpus, the tools it may use, how the corpus is pre-organized, and how the prompt teaches it to use those tools together form the "search interface." Today's interfaces are hand-designed and shared across corpora—for example DCI gives the agent a shell and lets it grep/cat raw documents. Korea University and KAIST's SearchWeaver has another coding agent (Claude Code + Claude Opus 5.5) design that interface automatically: it reads the search agent's full execution log and per-question scores, finds failure causes, then edits three things at once—pre-generated index files, executable search scripts, and the search agent's usage instructions—reruns, scores, and loops for 10 rounds. With GPT-5.4-nano as the search agent, BrowseComp-Plus accuracy rises from DCI's 71.6% to 78.4%, and mean nDCG@10 on four BRIGHT subsets from 45.7 to 55.0; the optimized interface handed unchanged to Gemini 3.5 Flash-Lite also beats DCI.
1. One interface does not fit every corpus
Recent agentic retrieval methods all work on a fixed interface: RAG returns retriever passages; DCI lets the agent shell through raw docs; DR-DCI first vector-retrieves docs into a workspace then browses; RISE bounds a restricted workspace and adds model-generated tables of contents. Paper Table 1 shows relative ranking flips by corpus: DR-DCI beats DCI on BrowseComp-Plus (73.1% vs 71.6%) but loses on BRIGHT (42.1 vs 45.7). The authors conclude the interface should be designed for the specific corpus and model.
2. Method: let a coding agent iteratively edit the interface
2.1 What an interface contains
A candidate interface has three parts:
- Pre-generated files: one-time processing of the whole corpus before any question arrives—for example a title→path index reused by every question.
- Executable tools: Python scripts that may call provided BM25 and vector retrieval, restrict search to a subdirectory, or merge the agent's document judgments with retrieval ranks.
- Usage instructions: instructions for the search agent on when to use which tool and how to verify clues.
Candidates may also replace the search agent's base system prompt and context-management policy. The search agent's model weights stay fixed.
2.2 Optimization loop
The designer is Claude Code (Claude Opus 5.5). Each round it inspects the corpus and all prior candidates, writes a new interface; the new interface runs on the optimization questions and returns per-question scores plus full execution logs (commands, tool returns, final answer). Gold document IDs for optimization questions are also given to the designer to separate "not found" from "found but not recognized." Every candidate's outcome is kept for later reference regardless of quality. After 10 rounds, the interface with the best mean optimization-set score is evaluated on held-out test questions that never enter the designer's feedback.
3. Experiments
Setup. BrowseComp-Plus (BCP) answers multi-clue questions over a fixed web corpus, judged by GPT-4.1: 30 optimization / 800 test questions. BRIGHT is reasoning-heavy document retrieval on biology, earth science, economics, and robotics: 213 optimization / 210 test questions, scored by nDCG@10. Each corpus gets its own optimized interface. Retrieval resources for the designer: BM25 + Qwen3-Embedding-4B on BCP; BM25 + ReasonEmbed-Qwen3-8B rankings on BRIGHT.
3.1 Main results
This checks whether corpus-optimized interfaces beat fixed interfaces on both benchmarks and every subset:
Optimized strategies differ by corpus: biology restricts retrieval to a topic directory; earth science calls retrieval only when building the final ranking; economics and robotics fold the agent's document judgments into ranking—via document order for the former and relevance grades for the latter.
3.2 Tool time
Per-question tool time (excluding model inference) also falls versus DCI: BCP from 42.4 s to 32.9 s, BRIGHT from 63.2 s to 36.6 s. From the figure, RISE and DR-DCI use even less tool time; SearchWeaver spends more tool time for higher scores, and the authors place it on the Pareto front among evaluated methods.
3.3 Is prompt-only enough?
This checks whether gains come from generated files and tools, not only better prompts. Two variants: the same loop but only prompts may change (Prompt Optimization); and SearchWeaver's final interface with generated files, tools, and matching instructions removed, without re-optimizing.
Prompt-only also gains clearly and even beats SearchWeaver on the economics subset (41.8 vs 38.3). Overall, adding files and tools is better; removing them falls back near DCI.
3.4 Does it transfer across models?
This checks whether the interface reuses across models. The GPT-5.4-nano-optimized interface is handed unchanged to Gemini 3.5 Flash-Lite: BCP accuracy 73.9% (DCI 60.9%), BRIGHT mean nDCG@10 58.8 (DCI 50.7), and BRIGHT per-question tool time from 23.1 s to 15.5 s. It works without re-optimization, so a substantial part of what was optimized belongs to the corpus itself, not only to model-specific tricks.
4. Limitations
Experiments use a static corpus. Whether pre-generated indexes and dependent tools must be refreshed after document adds/deletes, and whether updates can be incremental, is explicitly unstudied. BCP optimizes on only 30 questions; overfitting to those 30 is not analyzed. Each optimization round has the designer (Claude Opus 5.5) read full execution logs and the search agent rerun the optimization set—that cost is unreported.
5. Takeaways
For teams building internal knowledge-base QA agents, this gives an operable loop: take a small set of questions with gold answers and let a coding agent generate index files and retrieval scripts from execution logs, rather than only tuning prompts. The ablation where prompt-only raises BCP from 71.6% to 75.6% is also useful—when resources are limited, start with cheap prompt optimization. If the corpus changes often, design your own index maintenance.