Karpathys LLM Wiki: Das Second-Brain-Pattern und der Enterprise-Realitätscheck 2026
Anfang April 2026 hat Andrej Karpathy auf X beschrieben, wie ein LLM-Agent für ihn ein persistentes Wiki kompiliert und pflegt. Sechs Wochen später läuft die Enterprise-Debatte heiß: Was am Pattern als Personal-Werkzeug funktioniert, an welchen Governance-Anforderungen es scheitert und welche Schritte deutsche Unternehmen jetzt sinnvoll gehen.
Andrej Karpathy, Mitgründer von OpenAI und ehemaliger AI-Director bei Tesla, hat am 3. April 2026 ein Architekturmuster veröffentlicht, das die Diskussion um Enterprise-Wissensmanagement neu sortiert. Statt bei jeder Frage Quellen neu zu retrieven, kompiliert ein LLM-Agent ein persistentes Markdown-Wiki aus rohen Quellen, mit klarer Trennung von Raw, Wiki und Schema. Sein Beispiel-Wiki zu einem Forschungsthema umfasst rund 100 Artikel und 400.000 Wörter, jeder Ingest aktualisiert 10 bis 15 Wiki-Seiten. Mehrere Enterprise-Architekten haben zwischen April und Mai 2026 publiziert, warum das Pattern als persönliche Waffe funktioniert und als Unternehmensplattform scheitert: keine Role-Based Access Control, keine ACID-Transaktionen, kein compliance-fähiges Audit-Log, Skalierungsgrenzen bei wenigen hundert Seiten. Y Combinator nennt das fehlende Primitive in den Spring 2026 Requests for Startups company brain. Deutsche Anbieter wie EconLab AI haben mit AuditBrain bereits gemanagte DSGVO-Varianten auf Hetzner DE für ab 4.900 Euro Setup lanciert.
Was Karpathy ausgelöst hat
Am 3. April 2026 hat Andrej Karpathy auf X einen Workflow beschrieben, der seine eigene Nutzung großer Sprachmodelle verschoben hat. Statt LLMs hauptsächlich zur Code-Generierung einzusetzen, schiebt er seit Wochen den größten Teil seiner Token in den Aufbau persönlicher Wissensdatenbanken. Sein Beispiel: ein einziges Forschungs-Wiki zu einem Thema ist auf rund 100 Artikel mit 400.000 Wörtern angewachsen, geschrieben und gepflegt von einem LLM-Agenten, der rohe Quellen ingestiert und die strukturierte Wiki-Ebene verwaltet.
- Karpathy ist Mitgründer von OpenAI und ehemaliger AI-Director bei Tesla, seine technischen Aussagen werden im AI-Engineering überdurchschnittlich gelesen und kopiert
- Am 4. April 2026 hat er die komplette Architektur als GitHub Gist veröffentlicht, kopierbar als Spec für eigene Agenten
- Innerhalb von zwei Wochen erschienen rund zwei Dutzend deutsche und englische How-To-Artikel und Implementierungen
- Anders als bei seinen früheren Releases wie nanoGPT oder nanochat liefert Karpathy keinen Code, sondern eine Konvention; das Pattern ist absichtlich abstrakt
Karpathys Beitrag ist kein Tool, sondern eine Konvention. Die Wirkung kommt nicht aus dem Code, sondern aus der klaren Trennung von Verantwortlichkeiten zwischen Mensch und LLM-Agent.
Das Architekturmuster: Drei Schichten und drei Operationen
Karpathys Spec trennt drei Ebenen strikt voneinander, mit klaren Verantwortlichkeiten zwischen Mensch und LLM-Agent. Das ist die eigentliche Designentscheidung, nicht die Tool-Wahl.
-
Raw-Sources
Ordner
/raw. Unveränderliche Originaldokumente, Artikel, Papers, Bilder. Der Agent liest, ändert nichts. Dies ist die Quelle der Wahrheit. -
Wiki
Ordner
/wiki. Vom LLM erzeugte und gepflegte Markdown-Seiten. Entity-Seiten, Konzept-Seiten, Synthese-Seiten. Hier schreibt nur der Agent, der Mensch sourct und liest. -
Schema
Eine einzelne Datei, analog zu
CLAUDE.md. Definiert Struktur, Konventionen und Workflows. Der Agent benimmt sich wie ein disziplinierter Wiki-Pfleger.
Auf diesen Schichten laufen drei Operationen, die das System lebendig halten.
- Ingest: Neue Quelle wird gelesen, eine Zusammenfassungsseite entsteht, der Index wird aktualisiert, 10 bis 15 bestehende Wiki-Seiten werden im selben Lauf touchiert
- Query: Antworten zu Fragen werden als neue Seiten zurück ins Wiki gefiled; aus jeder Frage wächst das System
- Lint: Periodische Gesundheitschecks finden Widersprüche, veraltete Aussagen, verwaiste Seiten und Lücken
Zwei Hilfsdateien halten das System einsehbar: eine
index.md
mit Ein-Zeilen-Zusammenfassungen aller Seiten, die in ein Context Window passt und vom Agenten zuerst gelesen wird, und eine
log.md
als append-only Chronik aller Ingests, Queries und Lints, parsebar mit grep.
Warum das Pattern RAG angreift
Klassisches Retrieval-Augmented Generation lässt das LLM bei jeder Frage neu in einem Vektorindex suchen und aus den Treffern eine Antwort bauen. Das funktioniert, hat aber konzeptionelle Schwächen, die Karpathys Pattern adressieren will.
Das ist keine inkrementelle Verbesserung, sondern eine andere Architekturentscheidung. RAG-Anbieter werden nicht verschwinden, aber sie konkurrieren ab jetzt mit einem Pattern, das die teure Arbeit nach vorn verlagert und Wissen als wachsendes Artefakt behandelt.
Der Enterprise-Realitätscheck
Sobald das Pattern aus Karpathys persönlichem Vault in ein Unternehmen wandert, kollabieren mehrere Eigenschaften, die er nie versprochen hat. Mehrere Enterprise-Architekten haben zwischen April und Mai 2026 publiziert, warum das Pattern als Personal Knowledge Weapon funktioniert und als Unternehmensplattform scheitert.
Keine RBAC
Dateisystem-Rechte reichen nicht für Konzern-Governance. Wer darf welche Seite lesen, welche Quelle nicht sehen, welche Synthese erzeugen?
Keine ACID-Transaktionen
Mehrere Agenten oder Nutzer, die parallel ingesten, erzeugen Schreibkonflikte. Git-Versionierung mildert das, löst es nicht.
Audit-Logs sind keine Audit-Logs
Ein Git-Verlauf zeigt, wer was geändert hat, aber er ist kein compliance-fähiges Protokoll für Finanzen, Pharma oder Energieversorgung.
Skalierung schlägt zurück
Ab ein paar hundert Seiten kommen Retrieval, Ranking, Reranking und Chunking zurück. Karpathys 100-Seiten-Vault ist kein Beweis für Millionen Dokumente.
Hinzu kommt eine weitere Schwäche, die in der ersten Begeisterung untergeht: Halluzinationen kompoundieren. Schreibt der Agent einen falschen Fakt ins Wiki, ist die Wahrscheinlichkeit hoch, dass spätere Ingests darauf aufbauen. Ein menschliches Review für kritische Seiten wird zur Pflicht, sobald das System mehr ist als ein Forschungsspielplatz.
Y Combinator hat in den Spring 2026 Requests for Startups die fehlende Primitive direkt benannt:
If we want every company to run on AI automation, we need a new primitive: a company brain.
Deutsche und EU-Perspektive
Für deutsche Unternehmen überlagert sich das Pattern direkt mit DSGVO, EU AI Act und IT-Sicherheitsanforderungen. Der lokale Charakter des Original-Setups ist hier Vorteil und Falle zugleich.
- Lokal gehaltene Markdown-Dateien sind DSGVO-freundlicher als Cloud-RAG bei US-Anbietern, weil sich Datenhoheit leichter argumentieren lässt
- Sobald LLM-Aufrufe an US-Modelle gehen, wird der Daten-Transfer wieder zum Thema, unabhängig davon wo die Dateien liegen
- EU-konforme Backends wie Azure OpenAI EU oder europäische Inferenz-Anbieter sind die naheliegende Antwort, kosten aber Geld und Tempo
- Anbieter wie EconLab AI haben mit AuditBrain bereits eine gemanagte Variante als Docker-Container auf deutschen Hetzner-Servern lanciert, mit Setup-Paketen ab 4.900 Euro
- Der EU AI Act trifft das Pattern nicht direkt, aber sobald das Wiki Personenbezug enthält oder Entscheidungen unterstützt, greifen Transparenz- und Dokumentationspflichten
- Anonymisierung von Quellen vor dem Ingest wird zur Pflichtübung, weil sich aus den Synthese-Seiten Personenbezug rekonstruieren lässt, der in der Quelle nur implizit war
Praxisnah lesen: Unsere Einordnung der Obsidian-Claude-Integration beschreibt, wie sich Karpathys Pattern in deutschen Setups konkret betreiben lässt, von MCP-Sicherheitsfragen bis zu Token-Limits in größeren Vaults.
Was Unternehmen jetzt tun sollten
Das Pattern verdient eine ernsthafte Prüfung, aber nicht als großes Plattform-Projekt. Der Einstieg ist klein, der Aufwand bleibt überschaubar, und der Lerneffekt ist hoch.
-
Klein anfangen
Startet mit einem persönlichen oder Team-Setup zu einem konkreten Forschungsthema wie Markt-Scan, regulatorische Beobachtung oder technische Recherche. Nicht mit der Konzern-Wissensbasis.
-
Drei Schichten sauber trennen
Quellen, Wiki und Schema strikt voneinander entkoppeln. Die Drei-Schichten-Disziplin ist der wichtigste Lernpunkt aus Karpathys Spec.
-
Provenance auf Aussage-Ebene
Jede Wiki-Aussage sollte rückführbar auf ein bestimmtes Quellen-Segment sein, nicht nur auf eine Quelle insgesamt. Sonst lässt sich Wahrheit nicht von Halluzination trennen.
-
Approval-Workflows für kritische Seiten
Baut Freigaben ein, statt den Agenten autonom schreiben zu lassen. Ein Pull-Request-Modell mit menschlicher Freigabe ist hier ein gutes Vorbild.
-
Governance mit der Wiki-Größe mitwachsen lassen
Ab dem Punkt, wo das Wiki nicht mehr in ein Context Window passt, braucht es Retrieval. Damit kommen die alten Probleme zurück, nur in anderer Reihenfolge.
-
Backend-Frage früh entscheiden
EU-konforme Inferenz, lokale Modelle oder akzeptiertes Restrisiko bei US-Anbietern. Jede Variante hat einen Preis, jede ist begründbar, aber nicht alle sind beliebig austauschbar.
Wer bereits ein Glean-, Confluence- oder Notion-Setup hat, sollte das LLM Wiki nicht als Ersatz, sondern als ergänzendes Forschungs-Pattern denken. Die Stärke liegt im Compoundieren von Recherche, nicht im Ablösen der Dokumenten-Verwaltung.
Herausforderungen und Risiken
Wer das Pattern produktiv einsetzt, trägt das Risiko mit, das Karpathy als Forscher selbst kaum hat. Fünf Risiken stechen heraus.
- Halluzinations-Kompoundierung: Ein falscher Fakt im Wiki wird von späteren Ingests als gegeben behandelt und in Synthese-Seiten zementiert.
- Token-Kosten skalieren mit der Wiki-Größe: Jeder Ingest, der 10 bis 15 Seiten touchiert, kostet messbar. Bei produktivem Einsatz wird das ein eigener Haushaltsposten.
- Lock-in beim LLM-Anbieter: Das Pattern ist herstellerneutral, aber die Qualität der Wiki-Pflege hängt am Modell. Ein Wechsel ist nicht trivial.
- Schatten-Wissen: Mitarbeitende könnten parallele private Wikis bauen, was die zentrale Governance unterläuft.
- Halbwertszeit der Wahrheit: In schnellen Domänen veralten Synthese-Seiten früher als die Quellen, und der Lint-Lauf erkennt das nicht zuverlässig.
Weiterführende Informationen
Häufig gestellte Fragen
Andrej Karpathys LLM Wiki ist ein Architekturmuster, bei dem ein LLM-Agent aus rohen Quellen ein persistentes, vernetztes Markdown-Wiki kompiliert und kontinuierlich pflegt. Karpathy hat es am 3. April 2026 auf X beschrieben und einen Tag später als GitHub Gist veröffentlicht. Sein eigenes Wiki zu einem einzigen Thema umfasst rund 100 Artikel und 400.000 Wörter, vollständig vom Agenten geschrieben.
RAG entdeckt bei jeder Abfrage Wissen neu, indem es in einem Vektorindex sucht und aus Chunks eine Antwort baut. Das LLM Wiki kompiliert Synthese einmal beim Ingest und hält sie persistent. Cross-Referenzen stehen schon, Widersprüche werden in Lint-Läufen markiert, der Index ist immer aktuell. Das ist keine inkrementelle Verbesserung, sondern eine andere Architekturentscheidung.
Als persönliche oder Team-Wissensbasis ja, als Konzernplattform nein. Es fehlen Role-Based Access Control, ACID-Transaktionen, Multi-User-Concurrency und compliance-fähige Audit-Logs. Ein Git-Verlauf ist kein Audit-Log für regulierte Branchen. Y Combinator hat in den Spring 2026 Requests for Startups das fehlende Primitive explizit benannt: ein company brain mit Enterprise-Governance.
Die lokalen Markdown-Dateien selbst sind DSGVO-freundlicher als Cloud-RAG. Sobald aber LLM-Aufrufe an US-Modelle gehen, wird der Datentransfer wieder zum Thema. EU-konforme Backends wie Azure OpenAI EU oder europäische Inferenzanbieter sind die naheliegende Antwort. Anbieter wie EconLab AI haben bereits gemanagte DSGVO-Varianten als Docker-Container auf Hetzner DE lanciert. Personenbezogene Quellen müssen vor dem Ingest anonymisiert werden.
Sein Forschungs-Wiki zu einem einzelnen Thema ist auf rund 100 Artikel mit etwa 400.000 Wörtern angewachsen. Jeder Ingest einer neuen Quelle aktualisiert 10 bis 15 bestehende Wiki-Seiten. Das ist beeindruckend für ein Personal-Setup, aber kein Beweis für Skalierung auf Millionen Dokumente, ab denen Retrieval, Ranking und Chunking wieder zurückkommen.
Klein anfangen mit einem konkreten Forschungsthema wie Markt-Scan oder regulatorische Beobachtung, nicht mit der gesamten Konzern-Wissensbasis. Quellen, Wiki und Schema sauber trennen. Provenance auf Aussage-Ebene implementieren. Approval-Workflows für kritische Seiten einrichten statt autonomes Schreiben. Backend-Frage früh entscheiden, EU-konforme Inferenz oder lokale Modelle. Ehrlich mit Glean, Confluence mit AI oder Notion vergleichen.