Memory that compounds

The problem session-amnesic AI creates for research

Every ChatGPT and Claude session starts from zero. Nothing about a previous conversation is available to the current one; the tools have no memory across sessions. Retrieval-augmented generation over your group's documents partly addresses this: at query time, a retriever fetches chunks from the corpus, and the LLM composes an answer over the retrieved context. RAG works. It does not compound. Every query pays the same rediscovery cost. Nothing accumulates as a durable, growing artifact.

A related failure sits at the publication layer. Journals reward the corrected result and treat the abandoned path as noise. Pre-prints get superseded by camera-ready versions that delete the qualifications. Metascience has a name for this: the file-drawer effect (Rosenthal, 1979). The parts of project history most useful to a future collaborator, the dead ends and the audited-down numbers, are structurally excluded from the record. Every group has a student who repeated a failed method because no one told them.

The wiki-grounded research agent addresses both at once. It gives the agent a durable, structured memory that grows across sessions (the memory-that-compounds side), and it preserves the trajectory of claims including the ones that turned out to be wrong (the failure-path-preservation side). Both properties fall out of the same substrate: an append-only wiki with typed edges, maintained by the agent as it works.

What a wiki page actually looks like

Every wiki page is a Markdown file with YAML frontmatter that declares what the page is and what it relates to. Here is the frontmatter of a real page: the Experiment-11-Productionization page from the web_forager wiki, the page at the center of our case study:

---
type: synthesis
up: "[[Experiment-10-Vocabulary-Alignment]]"
tags: [experiment, demo-branch, navy-lunch, claude-cli, haiku-regression, sonnet-validated]
related: "[[Experiment-8-Second-Entity]]"
extends: "[[Experiment-7-Question-Deepen]]"
supports: "[[Working-Hypothesis]]"
---

The page body underneath is prose, tables, and cross-references. The frontmatter is what makes the wiki queryable as structure and not just as text. up: gives every page a parent, so the wiki has a hierarchy. extends:, supports:, related: declare semantic relationships to other pages. A reviewer who follows those edges is not reading arbitrary linked pages; they are traversing a graph the wiki maintains explicitly.

Typed edges are interface operations, not decoration

Different edge types license different reasoning by the agent that reads them. The web_forager wiki's schema page documents this table explicitly, under the heading Edges as Interface Operations:

This is what "typed edges are not decoration" means in practice. When a reviewer finds a bug on a page carrying extends: [[Experiment-7]], the edge tells them go check whether Experiment 7 inherited the same bug. When a bug page carries criticizes: [[Experiment-11]], the edge tells them go audit Experiment 11's conclusions. The wiki structure carries the semantic burden the reviewer would otherwise have to reconstruct from memory.

Neither example is hypothetical. Both are in the case study: an extends: edge propagated an audit from a demo branch back through two prior experiments, and a criticizes: edge on a screenshot-resolution bug page surfaced its downstream implications three weeks later. Same pattern, different edge type.

How new content gets into the wiki

The template ships four operations the agent can run against the wiki. Each is a documented procedure with a skill file the agent loads at session start:

Off the shelf, ingest handles papers, PDFs, notes, and tables. For sources with more complex structure (databases, APIs, structured figures), lightweight schema-driven connectors bring them into the wiki through the same ingest path. The point is that content comes in and lands as first-class wiki pages, not as chunks in a hidden retrieval index. The wiki is the memory, not an interface to it.

What accumulation looks like at scale

The clearest empirical demonstration of the wiki growing across time comes from the first-published case in Beyond Memory (Saboia Moreira et al., 2026), section 5.1: a solo research project called Project R (retrieval research). Over a 22-day window of intensive single-author use, the wiki grew to 48 cross-linked pages, with 907 body cross-references and 237 typed-edge frontmatter declarations among them. That is a wiki that operationally is a graph, not a folder.

The paper's contribution beyond the raw numbers is what the accumulation captured. Project R's research trajectory in the wiki is a sequence of five architectural iterations, each with a page or page-cluster: problem statement, attempt, result, and cross-references to the next iteration. The eventual best-performing iteration is the fifth. The third was a strongly-claimed alternative architecture that later work walked back by name.

That walked-back claim is still in the wiki. The original page carrying the strong position was not deleted; a new page was filed alongside it with a cross-reference back, and a Status note was added to the original pointing forward. A collaborator arriving at Project R a year later encounters the trajectory, not just the final answer. That is what compounding memory means in practice: the wiki captures the shape of the research, not only the punchline.

Failure-path preservation

Case A demonstrates the property; the mechanism that supports it is worth naming explicitly. The wiki is append-only by convention. Pages are added and amended, never deleted. When a claim turns out to be wrong, the discipline is:

1. File a successor page with the corrected claim.
2. Add a cross-reference from the successor back to the original.
3. Add a Status note to the original pointing forward to the successor.

The verification gate (one of the four operations above) makes this a hard rule at commit time: new claims must be filed alongside the ones they qualify, not on top of them. A collaborator or agent that would overwrite a walked-back claim is stopped by the gate.

The result is that the wiki accumulates trajectory, not just current state. This differs from most other AI-with-memory tools that have looked at the same problem. A concurrent extension of the llm-wiki pattern, LLM Wiki v2, added explicit supersession of stale claims by higher-confidence successors. Beyond Memory §6.1 argues the opposite move deliberately:

Supersession optimizes for the current reader's clarity. Preservation optimizes for the next reader's ability to learn from the trajectory.

Journals treat abandoned paths as noise. Pre-prints get superseded by camera-ready versions that delete the qualifications. The wiki does the opposite by design.

Why this compounds when RAG does not

Retrieval-augmented generation retrieves chunks from the same raw corpus on every query. The corpus does not change unless the underlying documents change. The retrieval index and the LLM's context together are the only structure the system has, and that structure gets rebuilt every query.

The wiki-grounded pattern (Karpathy, 2026; Saboia Moreira et al., 2026) inserts a durable layer between the raw sources and the agent. That layer is authored by the agent itself under a documented schema, and it grows with the project. Three properties fall out that RAG structurally cannot deliver:

• Content compounds. Ingesting the tenth paper does not just add a tenth chunk to the retrieval index. It creates typed-edge cross-references to the nine already in the wiki, updates the index, and if it contradicts prior claims, files a criticizing page rather than shadowing them. The graph gets denser as the project matures.
• Reasoning about the graph is possible. Because the edges carry semantics (extends:, criticizes:, supports:), an agent asked "what does this bug undermine?" can traverse the graph in a way a similarity-based retriever cannot. The case study is the empirical example.
• Trajectory survives. The append-only convention and the verification gate mean walked-back claims stay in place. A RAG index carries whatever is in the source documents right now; a wiki carries what the project once thought was true, alongside what it thinks now.

The claim in one paragraph

The wiki-grounded research agent gives your project a memory that grows, not a memory that gets rediscovered per query. Every ingest extends a graph with typed edges an agent can reason about. Every walked-back claim stays in place with a forward-pointer to its correction. Every session begins where the last one ended. The RAG comparison is not "wiki works better." It is "the wiki is doing a categorically different thing, and it is the thing research groups actually need."