The State of Agent Wikis

## Der Aufstieg der Agenten-Wikis: Wie KI unser Wissen neu organisiert

Im April 2026 veröffentlichte Andrej Karpathy einen GitHub Gist, der ein Muster beschrieb, das er als „LLM Wiki“ bezeichnete. Sein Kernargument: Sprachmodelle sollten Wissen nicht bei jeder Abfrage neu entdecken, sondern einmal kompilieren und pflegen. Was damals wie eine Vision klang, ist heute eine wachsende Kategorie. In den Monaten seither haben vier verschiedene Teams – Cognition, Factory AI, LangChain und Garry Tan – unabhängig voneinander die gleiche Idee realisiert. Sie alle liefern dieselbe Architektur aus: das Agenten-Wiki.

Diese Systeme lesen eine Vielzahl von Quellen, fassen sie in einem Satz von Markdown-Seiten zusammen und halten diese Seiten aktuell, wenn sich die Quellen ändern. Agenten lesen dann diese vorbereiteten Seiten, anstatt bei jeder Frage alles aus dem Rohmaterial neu abzuleiten. Diese Konvergenz unterschiedlicher Unternehmen und Nutzer auf eine einzige Architektur ist ein starkes Zeichen dafür, dass hier ein fundamentaler Wandel in der Wissensorganisation durch KI stattfindet.

### Die Idee: Kompilieren beim Erfassen, nicht bei der Abfrage

Um das Agenten-Wiki zu verstehen, müssen wir zunächst das zugrunde liegende Problem betrachten. Die gängige Methode, einem Modell Wissen bereitzustellen, ist das Retrieval Augmented Generation (RAG). Dokumente werden hochgeladen, zerlegt und eingebettet. Bei einer Abfrage werden die relevanten Fragmente abgerufen und zur Beantwortung genutzt. Das funktioniert, hat aber einen strukturellen Fehler: Nichts akkumuliert sich. Jede Frage beginnt mit rohen Fragmenten, sodass das Modell immer wieder dasselbe Verständnis neu ableitet. Die zehnte Frage zu einer Codebasis ist weder günstiger noch besser informiert als die erste.

Das LLM Wiki kehrt diesen Prozess um. Anstatt Wissen zur Abfragezeit aus rohen Teilen zusammenzusetzen, kompiliert ein LLM es einmal bei der Erfassung in dauerhafte Seiten und pflegt diese anschließend. Wenn eine neue Quelle eintrifft, liest das Modell sie, aktualisiert die betroffenen Entitätsseiten, überarbeitet Zusammenfassungen und markiert Widersprüche zu bereits Geschriebenem. RAG leitet Wissen bei jeder Frage neu ab. Ein Wiki leitet es einmal ab und hält es dann aktuell. Beide Ansätze sind legitim; sie unterscheiden sich darin, wann die Synthesekosten anfallen und ob das Ergebnis überdauert.

Die Architektur ist dabei konsistent dreischichtig:
1. **Rohquellen** sind unveränderlich (Artikel, Papiere, Repositories, Daten). Das Modell liest sie, ändert sie aber nie.
2. **Das Wiki** besteht aus vom LLM generiertem Markdown, das das Modell vollständig besitzt (Zusammenfassungen, Entitätsseiten, Konzeptseiten, Querverweise).
3. **Das Schema** ist eine Konfigurationsdatei (z.B. CLAUDE.md, AGENTS.md), die dem Modell vorschreibt, wie das Wiki organisiert ist und welche Workflows ausgeführt werden sollen. Dies macht es zu einem disziplinierten Pfleger und nicht zu einem Chatbot mit Dateizugriff.

Drei Hauptoperationen laufen auf dieser Struktur ab:
* **Ingest:** Eine Quelle erfassen und auf den betroffenen Seiten ablegen.
* **Query:** Das Wiki abfragen (und optional gute Antworten als neue Seiten ablegen, um die Exploration zu erweitern).
* **Lint:** Ein periodischer Durchlauf, der Widersprüche, veraltete Behauptungen und verwaiste Seiten aufspürt.

### Warum es funktioniert: Der Engpass war nie das Schreiben

Menschliche Wikis verfallen, und der Grund ist spezifisch. Das Schwierigste war nie das Lesen der Quellen oder die Erkenntnis. Es war die Buchführung: Querverweise aktualisieren, Zusammenfassungen auf dem neuesten Stand halten, ein neues Dokument mit vierzig bestehenden Seiten abgleichen. Diese Arbeit ist unbegrenzt, undankbar und das Erste, was ein vielbeschäftigtes Team fallen lässt. So verfällt das Wiki, die Leute hören auf, ihm zu vertrauen, und es stirbt.

Dies erinnert an die Erkenntnis, dass Unternehmens-Wissensdatenbanken oft nicht an mangelndem Bedarf scheitern, sondern an der Herausforderung, unstrukturierte Unternehmensinformationen in starre Formate zu pressen und aktuell zu halten. Hier setzt das LLM Wiki an. Genau diese Arbeit macht einem Sprachmodell nichts aus. Es wird nicht gelangweilt, vergisst nicht, einen Querverweis zu aktualisieren, und kann fünfzehn Dateien in einem Durchlauf bearbeiten. Das LLM Wiki funktioniert, weil es die Wartungskosten eliminiert, die jedes Wiki zuvor getötet haben. Die Idee ist älter als die Tools: Vannevar Bush beschrieb 1945 das Memex, einen kuratierten persönlichen Dokumentenspeicher mit assoziativen Pfaden. Bushs ungelöstes Problem war, wer die Pfade pflegt. Die Antwort, achtzig Jahre später, ist das Modell.

### Die Realität der Implementierung

Die letzten Monate haben gezeigt, wie sich Karpathys Idee in der Praxis manifestiert:

* **Cognition: DeepWiki – Das Wiki als öffentlicher Dienst.** Cognition Labs hat das Muster auf öffentliche GitHub-Repositories angewendet. Jedes öffentliche Repo kann über deepwiki.com als generiertes, navigierbares Wiki (Architekturübersicht, Dateiverzeichnis, Abhängigkeitsgraph) eingesehen werden. Bemerkenswert ist die Skalierung (über 50.000 Repositories) und die Rolle als Retrieval-Infrastruktur für Agenten wie Devin, die DeepWiki nutzen, um relevanten Kontext in einer Codebasis zu finden.
* **Factory: AutoWiki – Dokumentation als Build-Artefakt.** Factory AI betrachtet Dokumentation als Build-Artefakt, nicht als Nebenprojekt. Sie wird aus der Quelle erstellt, ist um die Funktionsweise der Codebasis herum organisiert und wird bei Änderungen im Repository aktualisiert. Die Generierung erfolgt über eine Zwei-Phasen-Analyse (strukturell, semantisch) durch spezialisierte Agenten. Die Aktualität wird durch CI-Workflows sichergestellt, die das Wiki bei jedem Push regenerieren.
* **LangChain: OpenWiki – Vom Code zu allem.** LangChain hat OpenWiki als CLI veröffentlicht, das Agenten-Dokumentation für Codebasen erstellt und pflegt. Es wurde dann zu „OpenWiki Brains“ erweitert, mit einem „Code Brain“ für Repositories und einem „Personal Brain“, das ein Wiki aus persönlichen Quellen (Gmail, Notion, Git, X, Hacker News, Web-Suche) erstellt. Dieser Schritt erweitert die Kategorie von „mein Repo dokumentieren“ zu „mein Arbeitsleben kompilieren“.
* **GBrain: Die persönliche Open-Source-Version.** Garry Tans GBrain wendet dasselbe Muster auf eine persönliche Wissensbasis an: Markdown in einem Git-Repository, eine Schemadatei und ein automatisch gepflegter Graph von Entitäts-Querverweisen. Es demonstriert die Substrat-Einfachheit des Musters: keine Vektordatenbank, kein Dienst, nur Dateien, die ein Modell pflegt und ein Mensch lesen kann.

Ein wichtiges Design-Detail, auf das sich alle Teams geeinigt haben: Der Output ist nicht für Menschen optimierte Prosa, sondern strukturiertes Markdown, das für den LLM-Kontext optimiert ist – mit Überschriften, Querverweisen und Zusammenfassungen, die einem Agenten helfen, relevanten Kontext schnell zu finden. Das Wiki ist für den Leser geschrieben, der es tatsächlich lesen wird: ein Modell.

### Wo das Muster an seine Grenzen stößt

So gut das Muster auch ist, es hat ehrliche Grenzen:
* **Skalierung:** Karpathy selbst nennt es: Index-First ohne Embeddings ist eine Technik für moderate Skalierung (etwa hundert Quellen, ein paar hundert Seiten). Darüber hinaus empfiehlt er das Hinzufügen von Suchfunktionen wie hybriden BM25- und Vektorsuchen.
* **Fidelity:** Das Kompilieren bei der Erfassung bedeutet, dass eine frühe Zusammenfassung stillschweigend ein Detail aus der Quelle verlieren kann, und jede spätere Antwort diesen Verlust erbt. Retrieval gegen rohe Fragmente hat diesen Fehlermodus nicht. Man tauscht Neuableitungskosten gegen Kompressionsrisiko.
* **Veralterung:** Eine kompilierte Seite ist nur so wahr wie die letzte Aktualisierung. Ein veraltetes Wiki ist schlimmer als gar keines, weil es in einem autoritär wirkenden Format selbstbewusst falsch ist. Hier spielt die CI-Integration von Factory eine entscheidende Rolle.
* **Kompilierungskosten:** Es fallen erhebliche Token-Kosten upfront an, um Seiten zu erstellen, die möglicherweise nie abgefragt werden, oder um Seiten neu zu linten, an denen sich nichts geändert hat.

### Ein Wiki ist kein Gedächtnis

Eine wichtige Unterscheidung ist hier noch zu treffen, da die Terminologie in diesem Bereich oft ungenau ist. Diese Systeme werden zunehmend als Gedächtnis beschrieben. LangChain nennt OpenWiki eine Wiki-Gedächtnisschicht für KI-Agenten. Das Wort „Gedächtnis“ trägt hier jedoch viel Gewicht und deckt zwei unterschiedliche Dinge ab:

1. **Korpuswissen:** Was ein Satz von Dokumenten, ein Repository oder Ihr Gmail-Archiv aussagt. Es beantwortet die Frage „Was enthält dieses Material?“ Ein Wiki ist hier exzellent.
2. **Benutzer- und Erfahrungsgedächtnis:** Was eine bestimmte Person bevorzugt, was sie letzte Woche entschieden hat, welcher Ansatz ihr Team bereits abgelehnt hat, was ein Agent gestern in einer anderen Anwendung versucht hat und wie es ausgegangen ist. Es ist auf eine Identität zugeschnitten, akkumuliert sich aus Interaktionen und muss Widersprüche, Veralterung, Herkunft und Löschung pro Benutzer handhaben.

Ein Wiki ist hervorragend im ersten Punkt und versucht den zweiten nicht. Ihr Gmail in Seiten zu kompilieren, sagt einem Agenten, was in Ihrem Gmail ist. Es sagt dem Agenten nicht, dass Sie Ihre Meinung über eine Anbieterentscheidung in einem Gespräch am letzten Dienstag geändert haben oder dass ein vorgeschlagener Ansatz für Sie bereits einmal gescheitert ist. Das zweite ist der Zweck einer dedizierten Gedächtnisschicht, wie sie beispielsweise Mem0 bietet: Gedächtnis, das an eine `user_id` gebunden ist, sodass es einer Person über Sitzungen, Anwendungen und Agenten hinweg folgt und bei Faktenänderungen an Ort und Stelle aktualisiert wird. Die beiden sind komplementär, und der Fehler besteht nicht darin, ein Wiki zu wählen. Der Fehler besteht darin, zu glauben, man habe das Gedächtnisproblem gelöst, nur weil man einen Korpus kompiliert hat.

### Fazit

Das LLM Wiki ist ein echtes Muster mit einer entscheidenden Erkenntnis: Wissen sollte einmal kompiliert und gepflegt werden, nicht bei jeder Frage neu abgeleitet, und die Wartung, die menschliche Wikis getötet hat, ist genau die Arbeit, die ein Modell kostenlos erledigt. Die Tatsache, dass vier Teams innerhalb weniger Monate dieselbe Architektur implementiert haben, ist der stärkste Beweis für ihre Richtigkeit.

Nehmen Sie drei Dinge mit:
1. Kompilieren Sie Ihre Dokumente in gepflegte Seiten, wenn der Korpus stabil ist und oft neu gelesen wird.
2. Fügen Sie eine echte Retrieval-Funktion hinzu, wenn der Korpus über die persönliche Skala hinauswächst, wie es die ursprüngliche Formulierung empfiehlt.
3. Halten Sie die Unterscheidung zwischen dem Kompilieren eines Korpus und dem Erinnern an einen Benutzer aufrecht, denn ein Wiki bietet Ihnen das Erste, aber nicht das Zweite. Das ist viel wert, aber es ist nicht dasselbe.

**Quelle:** mem0 (@mem0ai) vom 21. Juli 2026. Original X-Beitrag: https://x.com/mem0ai/status/2079585032587694582?s=52

Credit: mem0 (@mem0ai)