Librarian agents: training a model to organize the corpus before anyone asks

Most retrieval systems I have shipped share one quiet inefficiency: every query starts from zero. The agent searches, reads, cross-references, and throws the work away. The next question about the same corpus pays the full price again.

Librarian Agents: Training LLMs to Curate Long-Context Workspaces that Anticipate Future Queries, from Anikait Singh, Teresa Zhang, Yoonho Lee and colleagues at Stanford and CMU (with Aviral Kumar and Chelsea Finn), goes after that inefficiency directly. They train a builder agent to reorganize a corpus into a hierarchical filesystem before any query arrives, and they reward it only by how well a separate, frozen answering agent performs on questions the builder never sees.

The asymmetry they exploit

The paper's starting observation is one I agree with from production experience. Agents in harnesses like Claude Code are good at navigating an existing filesystem: ls, read, follow a path, read again. They are rarely trained to build one for someone else. Reactive RAG redoes cross-document reasoning on every query. Precomputed structures like knowledge graphs commit early to rigid abstractions such as named entities, which helps only when future queries line up with the index.

Librarian Agents sits between the two. The builder's output is not an embedding index or a graph schema. It is a set of synthetic files and directories, with reference links back to the original documents, that an off-the-shelf filesystem-navigating agent can use without modification.

How the builder is trained

The builder's work is framed as a finite-horizon MDP. The state is the current filesystem. The action space is deliberately small:

• CreateFile: consolidate raw documents and/or existing synthetic files into a new file that links to its sources.
• MergeFiles: roll related synthetic files into a higher-level artifact, which is what introduces hierarchy.
• Delete: remove unhelpful synthetic files. Raw documents can never be deleted, so a fallback path always exists.
• Stop: return the workspace.

The objective is downstream answering accuracy, optionally penalized by navigation cost and build cost. A purely terminal reward over a long sequence of edits gives poor credit assignment, so the authors densify it. Every eight turns they probe the answering agent on a hidden minibatch of training queries and reward the change in answerability. Because the per-step deltas telescope back to the terminal objective, this is potential-based reward shaping in the Ng et al. sense: denser signal, same optimum. The policy is trained with GRPO, and in the primary runs the cost penalties are switched off, so the builder optimizes accuracy alone.

The point I like most is that structure is a learned decision rather than a schema someone wrote down. The builder decides which timelines, indexes and summaries are worth materializing, judged entirely by whether a later reader gets the answer right.

What the numbers say

On BrowseComp-Plus (680 training tasks, 50 held-out), with frozen answering agents:

• Qwen3.5-4B answerer: 0.75 accuracy, against 0.42 for embedding retrieval and 0.44 with a reranker.
• Gemini 3.1 Flash Lite answerer: 0.77, against 0.30 and 0.42.
• The same builder without RL reaches only 0.28. The base model does not know how to curate for someone else; RL is what teaches it.

Construction cost is reported in tokens: about 179K for Librarian Agents, 128K for the untrained builder, 12K for GraphRAG (0.36 accuracy), and 502K for an autocompaction baseline that scored 0.04. Spending tokens is not the same as spending them well.

The amortization study is the part that matters for production. Across 443 synthetic queries over 50 document sets, the trained workspaces score 0.64 against 0.24 for the base builder. Answer-time reads rise to about 9.3K tokens per query, compared with roughly 1.2K for the base builder, because the answering agent now has a richer tree to explore. Normalized by accuracy, the paper reports 33.8% fewer tokens per expected correct answer at ten questions per corpus (paired-bootstrap 95% CI on the ratio: 0.504 to 0.836).

Zero-shot transfer to BRIGHT, with a builder trained only on BrowseComp-Plus, gives an average pass@1 of 52.0% across AoPS, Biology and Stack Overflow. The strongest baseline, dense retrieval, gets 20.8%. The gain is uneven, though. Stack Overflow jumps from 11.5% to 85.5%, while AoPS moves only from 33.0% (hybrid) to 36.0%. A structured workspace helps most where the answer depends on assembling scattered evidence, and much less on competition math, where the bottleneck is reasoning rather than finding.

Structure matters, and so does where things go

Two findings change how I think about this kind of system.

First, the trained builder produces much richer trees: on BRIGHT, an average of 53.4 active synthetic files in 45.4 clusters with 8.0 merges, against 4.8 files for the base builder. Second, the filesystem ablation separates two effects. Flattening the hierarchy keeps accuracy roughly the same but raises navigation cost. Shuffling where content sits lowers accuracy without saving any navigation. So hierarchy buys efficiency, and semantic placement buys correctness. Anyone designing a hand-built knowledge layout for an agent should take that distinction seriously.

The provenance links also earn their keep. The paper shows a case where the synthetic layer had dropped a needed detail, and the answering agent followed a reference link back to the raw file instead of failing.

My read

I see this as the indexing step of agentic retrieval made learnable, and I think that is the right direction. In enterprise settings the same corpus answers thousands of questions, so a one-time build cost is easy to justify when it improves accuracy per correct answer.

There are caveats I would want resolved before deploying it:

• Static corpora only. The authors say plainly that keeping the workspace current as documents change is an open problem. Real knowledge bases change daily, so incremental rebuilds are the deciding feature.
• Small evaluation set. 50 held-out BrowseComp-Plus tasks is enough to show a direction, not enough to pin down the effect size.
• Per-query latency goes up. Close to 8x more answer-time tokens is fine for analyst workflows and painful for interactive ones.
• The builder sees a large file context, which limits scale. The authors suggest pairing it with clustering or retrieval.
• Knowing when to bypass the synthetic layer is still unsolved, and it is exactly where compression-induced errors will hide.

The extension the authors propose, a filesystem that updates from its own traffic and treats each answered query as evidence of what the next reader needs, is the version I would want to build. Code is linked from the project site and the GitHub repository.