The Agent Wiki Becomes the Retrieval Spine
The May 2026 arXiv paper Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki, by Haoliang Ming, Feifei Li, Xiaoqing Wu, and Wenhui Que, asks a governance-grade infrastructure question: what if retrieval is not a hidden lookup step, but part of the agent's reasoning surface?
Lookup Is Not Memory
The ordinary retrieval-augmented generation story treats external knowledge as a supply of passages. A query enters the system, a retriever ranks chunks, the model receives a fixed bundle of context, and the answer is judged as if retrieval were plumbing. That works for many local fact questions. It becomes brittle when an agent has to follow relations, compare entities, or collect evidence across several documents.
The LLM-Wiki paper names this difference clearly. It argues that agents need retrieval to behave less like one-shot lookup and more like a reasoning process: search, read, follow links, notice missing evidence, search again, and stop only when the evidence is sufficient. The agent needs a knowledge surface it can traverse, not merely a pile of semantically similar fragments.
That makes the paper useful for Spiralist purposes. It moves memory out of the mystique of "more context" and into the visible architecture of pages, links, source references, validation failures, and repair rules. The agent wiki becomes the retrieval spine because it is the structure through which the agent decides what it knows next.
What the Paper Builds
The paper, arXiv:2605.25480, was submitted on May 25, 2026 and revised on May 26, 2026. It proposes LLM-Wiki, an agent-native retrieval system that compiles raw documents into structured wiki pages rather than splitting them only into flat chunks. The pages include metadata, aliases, tags, facts, source references, and bidirectional links. The system exposes those pages through tool-style search and read operations, so the agent can inspect candidate pages and follow connections during the run.
This changes the contract between model and memory. A vector database can retrieve material without giving the agent a durable map of why one item leads to another. A compiled wiki is still machine-built and fallible, but it gives reviewers pages, links, references, and paths that can be checked.
The authors describe the system around three principles: compilability, composability, and evolvability. In practical terms, the documents are transformed into linked units; the agent composes search and read actions across those units; and the structure is repaired over time instead of being treated as a static index.
The Error Book
The most governance-relevant feature is the Error Book. The paper does not pretend that LLM-compiled knowledge is clean. It names recurring construction failures: dangling links, incomplete pages, malformed references, unseen overwrites, index inconsistencies, unsupported facts, and cross-page contradictions. In the reported error analysis, dangling links account for 29.1-63.8% of detected errors across corpora, while malformed references account for 18.9-28.5%.
The Error Book persists those problems as structured records. It attributes root causes, converts them into reusable constraints, injects those constraints into future compilation, and runs deterministic fixes for structural problems plus LLM-based fixes for semantic issues. The paper reports that disabling the Error Book reduced F1 scores by 3.4-4.0 points in its ablation table.
This matters because institutional retrieval systems often hide their decay. A connector is added, a document changes, a policy page moves, an embedding index gets stale, a summary drops a caveat, and the assistant keeps sounding fluent. LLM-Wiki's Error Book treats memory maintenance as an operational record.
What the Results Mean
The paper evaluates LLM-Wiki on HotpotQA, MuSiQue, 2WikiMultiHopQA, and AuthTrace. It compares against seven baselines, including closed-book generation, BM25 and dense RAG, RAPTOR, GraphRAG, LightRAG, and HippoRAG 2. The authors report the strongest overall results on the three public multi-hop QA benchmarks, with gains over the strongest baseline ranging from 2.0 to 8.1 F1 points.
The ablations are more interesting than the headline. Removing the wiki structure dropped reported F1 by 6.1-7.0 points. Removing progressive traversal dropped it by 11.7-13.8 points. That says the value was not just a new storage format. The benefit came from a maintained structure plus an agent allowed to use that structure step by step.
Read the result with caution. The paper's evaluation is still a benchmark setting, and the authors note limitations: compilation cost, scaling problems as the wiki grows to tens of thousands of pages, directory maintenance, stale-fact handling, and the need for larger dynamic corpora. This is not an automatic replacement for retrieval governance. It is a sharper object for thinking about it.
Governance Reading
For AI governance, the central question is not whether every organization should build an LLM-Wiki. The question is what kind of memory an agent should be allowed to act from. If an agent can file tickets, draft emails, update records, search case files, or recommend decisions, then its knowledge base is not passive storage. It is part of the action surface.
A hidden index makes contestation hard. If the answer came from "retrieval," an auditor still needs to know which source entered the index, which chunk was retrieved, which fact was transformed, what evidence was skipped, and whether the system had a chance to repair known errors. A wiki-style substrate does not automatically answer those questions, but it gives them a place to live.
The deeper lesson is that agent memory should have shape. It should not be only bigger context, more files, or more embeddings. It should have named pages, provenance, broken-link detection, contradiction handling, update rules, retention rules, and an audit trail for when memory changes. Otherwise the organization has built a machine that can act on records no one can reconstruct.
What to Demand
Before adopting agentic retrieval in consequential settings, ask for the retrieval spine. What are the durable knowledge units? How are source references preserved? Can reviewers inspect why the agent followed a path? Are stale facts detected? Are unsupported facts logged? Does the system distinguish structural errors from semantic errors? Can a user appeal an answer by pointing to a source, a missing source, or a broken link?
Those questions connect this paper to AI agents, agent observability, agent logs, and agent incident review. The agent wiki is not interesting because it resembles old web culture. It is interesting because it makes machine memory less formless. A governable agent needs memory that can be inspected, corrected, and survived.
Sources
- Haoliang Ming, Feifei Li, Xiaoqing Wu, and Wenhui Que, Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki, arXiv:2605.25480 [cs.CL], submitted May 25, 2026 and revised May 26, 2026.
- arXiv experimental HTML for Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki, reviewed June 24, 2026.
- Related pages: Retrieval-Augmented Generation, Vector Databases, AI Agents, AI Agent Observability, AI Audit Trails, The Context Window Becomes the Failure Archive, The Agent Log Becomes the Receipt, and Agent Audit and Incident Review.