An LLM-maintained wiki to preserve what research teams forget

Every research project accumulates a kind of knowledge that almost never survives: the failed experiments, the discarded hypotheses and the claims that were walked back along the way. Publications and shared code systematically exclude them, and the consequence is paid in time: future collaborators re-attempt the same dead ends because no record exists that someone already went down that path. A paper published today, July 30, 2026, on arXiv under the identifier arXiv:2607.24759, proposes to attack that problem with a wiki maintained by LLM agents that sits between the raw sources and the agent itself.

The authors start from two limitations that anyone working with coding agents will recognize instantly. First: LLM agents are now regular participants in research projects and knowledge work, but they hold no persistent memory across sessions; every conversation starts from zero. Second: retrieval-augmented generation (RAG) over raw sources does not compound value over time. Retrieving fragments of the original documents again and again does not build a shared understanding of the project, it only partially reconstructs it on every query.

The llm-wiki pattern, turned into a template

The paper's answer builds on the llm-wiki pattern, which the authors attribute to work by Karpathy and the tonbi project, both from 2026. The idea is to insert an interlinked wiki, maintained by the LLM itself, between the original sources and the agent that consumes them. Instead of consulting papers, code and scattered notes, the agent reads and writes wiki pages that distill findings, decisions and reasoning.

The work's concrete contribution is llm-wiki-memory-template, a reusable, agent-aware instantiation of that pattern. The authors defend it as a substrate for heterogeneous collaborative knowledge work along three axes: multiple humans, multiple AI agents and multiple domains at once. According to the paper, each axis is supported by a distinct architectural element of the template, detailed in its section 4.

Append-only: preserving what did not work

The most interesting design decision is that the wiki is append-only by convention: entries accumulate instead of being edited to reflect only the current truth. That preserves what did not work alongside what did, and tackles head-on what the authors call the negative-result loss problem. A walked-back hypothesis does not disappear; it remains visible next to its correction, so the next collaborator, human or agent, knows that path was already explored and why it was abandoned.

The nuance is worth underlining: by convention means nothing enforces it technically. The template proposes the discipline but does not guarantee it, and much of the real friction will live there once several teams and several agents write at the same time.

Who this is useful for

The approach will feel familiar to any team using Claude Code or other coding agents across long sessions. Many already improvise something similar: CLAUDE.md files, memory directories, session notes the agent reads on startup. The difference is that those solutions tend to be personal, with no common structure and no links between entries. A shared template, designed from the start to be read and written by both people and agents, formalizes that practice and makes it transferable across projects.

The natural candidates are research groups with member rotation, educational projects where each cohort inherits the previous one's work, and engineering teams that already delegate tasks to agents and lose context every time a session closes.

It remains to be seen how the template behaves with large volumes of entries and with agents that write under different criteria. The paper is largely an architecture proposal and a position argument, not an extensive empirical evaluation, and it should be read with that expectation.

At ElephantPink we have spent months maintaining hand-curated memory for our agents, and the paper's diagnosis strikes us as accurate: what gets lost between sessions is not the successes, which end up in the code, but the discards. A common template does not solve on its own the discipline it demands, but it is a considerably more serious starting point than improvised notes.