Wie ich ein Zweites Gehirn gebaut habe, das sich selbst erinnert

Es gibt diesen Moment, in dem man merkt dass man das gleiche Problem zum dritten Mal löst — und die Lösung von letztem Mal nirgendwo mehr findet.

Bei mir war es eine Docker-Konfiguration. Ich hatte sie im Oktober angepasst und die Erkenntnisse in einem langen Chat mit einer KI durchgearbeitet — welche Ports, welche Volumes, warum diese Reihenfolge. Dann habe ich das Fenster geschlossen. Sechs Monate später stand ich vor dem gleichen Problem: gleicher Server, gleicher Fehler, und null Erinnerung an die Lösung.

Das Wissen war da gewesen — in einer Chat-Session, die ich geschlossen hatte. Damit war es weg.

Wenn du regelmäßig mit KI arbeitest, kennst du das wahrscheinlich. Man führt großartige Gespräche: tiefe technische Diskussionen, durchdachte Architektur-Entscheidungen, echte Aha-Momente. Und am Ende der Session ist alles weg, weil der nächste Chat bei Null anfängt. Die KI weiß nicht was gestern war, und du weißt es theoretisch — findest es aber nicht mehr.

Irgendwann habe ich verstanden, dass mein Problem nicht ein fehlendes Notizbuch ist. Ich brauche kein besseres Tool zum Aufschreiben. Ich brauche ein System, das sich von alleine erinnert.

Die drei Vorbilder

Was ich am Ende gebaut habe, ist keine Eigenerfindung — es steht auf den Schultern von drei Leuten, die jeweils ein Stück beigetragen haben. Bevor ich erkläre was ich konkret gemacht habe, lohnt es sich kurz zu verstehen woher die Ideen kommen, denn das erklärt warum das System so funktioniert wie es funktioniert.

Andrej Karpathy: Das LLM Wiki

Im Frühjahr 2026 veröffentlichte Andrej Karpathy — ehemaliger KI-Chef bei Tesla, Mitgründer von OpenAI und einer der einflussreichsten KI-Köpfe überhaupt — ein unscheinbares Gist auf GitHub. Kein Framework, kein Tool — einfach ein Textdokument mit dem Titel „LLM Wiki“.

Um die Kernidee zu verstehen, muss man kurz ausholen: Wenn heute die meisten Leute ihre KI mit eigenen Dokumenten füttern wollen, nutzen sie sogenanntes RAG (Retrieval-Augmented Generation). Das bedeutet: Man wirft Dokumente in eine Datenbank, und bei jeder Frage sucht die KI von vorn nach passenden Textfragmenten. Das funktioniert — aber es baut sich nichts auf. Wenn du eine Frage stellst die fünf verschiedene Dokumente erfordert, muss die KI jedes Mal die Puzzlestücke neu zusammensetzen. Es gibt keine Akkumulation, kein wachsendes Verständnis.

Karpathys Gegenvorschlag ist elegant: Statt jedes Mal von vorn zu suchen, baut und pflegt die KI eine persistente Wiki — ein lebendes Dokument, das mit jeder neuen Quelle wächst. Wenn du etwas Neues hinzufügst, liest die KI es, extrahiert die Schlüsselinformationen und integriert sie in die bestehende Wiki. Sie aktualisiert Seiten, notiert Widersprüche und stärkt oder hinterfragt bestehende Synthesen.

Sein System hat drei Schichten, die aufeinander aufbauen: 1. Raw Sources — deine unveränderlichen Quelldokumente (Bücher, Artikel, Gesprächsprotokolle) 2. Die Wiki — von der KI geschriebene Markdown-Seiten mit Querverweisen zwischen den Themen 3. Das Schema — eine Konfigurationsdatei die der KI sagt, wie die Wiki strukturiert sein soll

Karpathy selbst beschreibt seine Arbeitsweise so: „Obsidian auf der einen Seite, LLM auf der anderen. Das LLM schreibt, ich browse.“

Das hat bei mir sofort geklickt — nicht weil es revolutionär klingt, sondern weil es genau das Problem löst das ich jeden Tag hatte: Wissen geht verloren, weil niemand es zusammenführt.

Cole Medin: Die automatische Implementierung

Karpathys Gist war ein brillantes Konzeptpapier — aber eben nur ein Konzept, keine Zeile Code. Cole Medin, ein Entwickler der sich auf Claude Code spezialisiert hat (sein YouTube-Kanal ist eine Goldgrube für Claude-Code-Nutzer), nahm dieses Konzept und baute eine funktionierende Implementierung: den claude-memory-compiler (Video-Erklärung).

Seine zentrale Idee verändert die Perspektive: Nicht Webseiten oder PDFs sind die Quellen für die Wiki — sondern deine eigenen KI-Konversationen. Jedes Gespräch das du mit der KI führst wird automatisch abgefangen, die wichtigen Teile werden extrahiert und in einem täglichen Protokoll gespeichert. Und abends kompiliert ein separater Prozess diese Protokolle zu strukturierten Wissensartikeln, die beim nächsten Start wieder in den Kontext der KI fließen.

Session endet
  → Hook fängt Konversation ab
  → flush.py extrahiert Entscheidungen, Learnings, Erkenntnisse
  → Daily Log wird befüllt
  → compile.py baut daraus Konzept-Artikel
  → Nächste Session startet mit injiziertem Wissens-Index

Das Spannende daran: Es braucht keine Vektordatenbank und kein RAG. Nur Markdown-Dateien und ein Index, den die KI beim Start liest. Karpathys Erkenntnis bestätigt sich hier in der Praxis: Bei persönlichem Maßstab — sagen wir 50 bis 500 Artikel — schlägt ein strukturierter Index die Vektor-Suche, weil die KI versteht was du wirklich fragst, während Cosine Similarity nur ähnliche Wörter findet.

Coles System war allerdings als eigenständiges Tool gebaut — ein eigenes Projektverzeichnis, eigene Ordner, komplett unabhängig von jeder bestehenden Notiz-Infrastruktur. Es funktioniert gut, aber es lebt neben dem Vault, nicht darin. Und genau das war der Punkt, an dem der dritte Baustein ins Spiel kam.

Julian Ivanov: Das Obsidian-Setup

Den dritten Baustein lieferte Julian Ivanov mit seinem Video Obsidian + Claude Code: So baust du dein zweites Gehirn. Julian hatte etwas gebaut, das keiner der anderen hatte: einen strukturierten Onboarding-Prozess, der dich vom leeren Vault zu einem funktionierenden persönlichen System führt.

Seine CLAUDE.md war kein statisches Konfigurationsdokument — sondern ein interaktiver Setup-Guide. Ein Assistent der dich durch eine Reihe von Fragen führt: Wer bist du? Was machst du beruflich? Welche Projekte laufen gerade? Wie schreibst du? Und basierend auf deinen Antworten baut er die komplette Vault-Struktur auf — Ordner, Kontext-Dateien, Projektnotizen und die Regeln nach denen die KI mit deinem Vault arbeiten soll.

Das klingt vielleicht simpel, aber es löst ein Problem das die meisten Second-Brain-Systeme komplett ignorieren: den Kaltstart. Ein leerer Vault ist nutzlos — man sitzt vor einer leeren Struktur und weiß nicht wo man anfangen soll. Julians Ansatz nimmt dir diese Hürde ab und macht den Vault vom ersten Tag an persönlich und funktional.

Was ich daraus gebaut habe

Keines der drei Systeme war für sich allein das, was ich brauchte — aber zusammen ergeben sie etwas, das mehr ist als die Summe der Teile.

Karpathys Konzept war zu abstrakt: eine brillante Idee, aber kein Tool das man benutzen kann. Coles Implementierung war zu isoliert: sie funktioniert hervorragend, lebt aber als separates Projekt neben dem Vault statt darin. Und Julians Setup war ein hervorragender Start, aber ohne Gedächtnis — jede Session begann bei Null, abgesehen davon was in der CLAUDE.md steht.

Also habe ich alle drei verheiratet.

Der Weg dahin

Ehrlich gesagt habe ich nicht bei Null angefangen. Bevor ich den Vault aufgesetzt habe, hatte ich monatelang ChatGPT genutzt — für technische Fragen, Architektur-Entscheidungen, Projektplanung. Hunderte von Chats, in denen viel Wissen steckte, das in einem Chatfenster verstreut lag und bald vergessen sein würde.

Mein erster Schritt war deshalb ein Trick, auf den ich ziemlich stolz bin: Ich habe ChatGPT die Fragen aus Julians Setup-Guide beantworten lassen. Julians CLAUDE.md fragt beim Einrichten systematisch ab — Profil, Projekte, Bereiche, Schreibstil, Branding. Statt diese Fragen selbst zu beantworten, habe ich ChatGPT gebeten, basierend auf unseren bisherigen Chats meine Antworten auf genau diese Fragen vorzubereiten.

Das Ergebnis war verblüffend: ChatGPT kannte mich nach Monaten der Zusammenarbeit erstaunlich oder auch erschreckend gut — ehrlich gesagt besser, als ich mich in dem Moment selbst hätte beschreiben können. Es wusste welche Projekte ich hatte, welche Server ich betreibe, wie ich schreibe und denke. Ich musste die Antworten nur noch prüfen, bestätigen und an ein paar Stellen ergänzen.

Nachdem ich diese Vorbereitung abgeschlossen hatte, ging es in Obsidian weiter. Als erstes habe ich das Claudian Plugin installiert — das ist die Brücke zwischen Obsidian und Claude Code. Die Installation läuft über BRATS (Beta Reviewer’s Auto-update Tester): Man installiert BRATS als Obsidian-Plugin, fügt den GitHub-Link von Claudian ein, und aktiviert es. Julian erklärt das in seinem Video Schritt für Schritt, deshalb spare ich mir die Details hier.

Dann kam Julians CLAUDE.md zum Einsatz. Ich habe sie in den leeren Vault gelegt, Claude Code gestartet, und der Assistent hat mich durch den Prozess geführt: Ordner angelegt, Kontext-Dateien erstellt, Projekte als Notizen angelegt — alles basierend auf meinen Antworten, die ChatGPT vorbereitet hatte.

Als nächstes habe ich mit dem ChatGPT Exporter Plugin (eine Browser-Extension) meine relevanten ChatGPT-Chats als Markdown exportiert und in den Vault importiert. Nicht als Notizen die ich lesen würde, sondern als Rohmaterial — damit Claude Code von Tag eins an einen Kontext hatte, der über das bloße Setup hinausgeht.

Am Ende von Tag eins hatte ich: – Eine Ordnerstruktur nach dem PARA-Prinzip, angepasst an meine Bereiche – Ein persönliches Kontextprofil in fünf Dateien (wer ich bin, was ich mache, wie ich schreibe) – Projektnotizen für über 15 aktive Projekte – Eine CLAUDE.md die Claude sagt wer ich bin und wie der Vault funktioniert – Importierte ChatGPT-Chats als erste Wissensbasis

Das war ein solides Fundament. Aber es war noch kein lernendes System — denn nach jeder Session war immer noch alles weg, was nicht explizit in einer Notiz stand.

Vom Setup zum lernenden System

Was in den Tagen danach entstand, ist die Verschmelzung aller drei Ansätze — und der eigentliche Grund warum ich diese Serie schreibe.

Die Vault-Struktur basiert auf Julians PARA-Ansatz und sieht so aus:

00 Kontext/          ← Persönliches Profil, Zielgruppe, Schreibstil
01 Inbox/            ← Schnelle Gedanken, Brain Dumps
02 Projekte/         ← Aktive Projekte (Beruf, Aufbau, Privat)
03 Bereiche/         ← Laufende Verantwortungen ohne Enddatum
04 Ressourcen/       ← Referenzmaterial, Fachwissen + Knowledge Base
05 Daily Notes/      ← Tägliches Logbuch (automatisch + manuell)
06 Archiv/           ← Abgeschlossenes
07 Anhänge/          ← Medien

Das ist die sichtbare Seite. Aber das Entscheidende passiert unsichtbar: Im Hintergrund laufen automatische Prozesse — sogenannte Hooks — die bei jedem Session-Start, jedem Session-Ende und vor jeder Kontext-Komprimierung feuern. Sie sorgen dafür, dass jede Session Spuren hinterlässt, ohne dass ich aktiv etwas tun muss. Wie genau das funktioniert, erkläre ich ausführlich in Teil 2.

Was das in der Praxis bedeutet

Um das Ganze greifbar zu machen, ein konkretes Beispiel: Heute Morgen habe ich eine neue Claude-Session in Obsidian gestartet. Ich habe einfach angefangen zu arbeiten — nichts Besonderes getan. Im Hintergrund ist aber Folgendes passiert:

Der SessionStart-Hook hat automatisch geprüft, ob es Daily Notes gibt die noch nicht in Wissensartikel umgewandelt wurden. Er hat 27 Stück gefunden — alle aus den letzten Monaten, in denen ich das System erst aufgebaut habe. Daraufhin hat er den Compiler im Hintergrund gestartet, der still und leise 41 Konzept-Artikel und 3 Verbindungsartikel erstellt hat, während ich schon an etwas ganz anderem arbeitete.

Das Ergebnis: Claude wusste plötzlich, dass ich im März einen Reverse-Proxy-Vergleich zwischen Traefik, Caddy und Nginx gemacht habe. Dass meine Eventdatenbank auf Supabase läuft. Dass mein MCP-Setup ein SSH-PATH-Problem hatte und wie es gelöst wurde.

Nicht weil ich es in dieser Session erzählt habe — sondern weil das System sich erinnert hat.

Was man dafür braucht

Ich will das nicht als „einfaches Setup“ verkaufen — es ist kein One-Click-Install. Aber es ist auch keine Raketenwissenschaft, und wenn man den Weg einmal gegangen ist, läuft alles automatisch.

Voraussetzungen: – Obsidian (kostenlos) – Claude Code (Pro-, Max- oder Team-Abo) – Das Claudian Plugin als Brücke zwischen Obsidian und Claude Code – Python 3.12+ und uv als Paketmanager (für die automatischen Scripts) – Ein paar Stunden für den initialen Aufbau

Was man ausdrücklich NICHT braucht: – Keine Vektordatenbank, keine Cloud-Services, keinen separaten Server – Keine Programmierkenntnisse für den täglichen Betrieb — die Scripts laufen im Hintergrund – Kein separates API-Budget — alles läuft über das bestehende Claude-Abo

Was ich beim nächsten Mal anders machen würde

Rückblickend auf den Aufbau gibt es zwei Dinge, die ich beim nächsten Mal von Anfang an anders angehen würde:

1. ChatGPT-Chats viel früher exportieren. Ich hatte Monate an Wissen in ChatGPT-Sessions liegen, und der Export war Gold wert — aber er wäre noch wertvoller gewesen, wenn ich ihn von Anfang an als feste Routine eingebaut hätte. Wenn du regelmäßig mit einer KI arbeitest, exportiere deine wichtigen Chats regelmäßig, auch wenn du noch keinen Vault hast. Das Rohmaterial ist da, man muss es nur sichern.

2. Weniger Projekte auf einmal anlegen. Ich hatte am ersten Tag über 15 Projekte angelegt, weil Julians Setup-Guide so gründlich nachfragt. Das war ehrlich und vollständig — aber auch überwältigend. Besser wäre gewesen, mit 3-5 aktiven Projekten zu starten und den Rest entweder auf „pausiert“ zu setzen oder erst anzulegen, wenn sie wirklich relevant werden.

Weiter in Teil 2

In diesem Artikel habe ich die Geschichte erzählt — woher die Ideen kommen, wie der Vault aufgebaut ist und was der erste Tag gebracht hat. Im nächsten Teil geht es ans Eingemachte: Was passiert technisch bei jeder Session? Wie funktionieren die Hooks, die das System am Laufen halten? Und wo sind die Grenzen, die ich noch nicht gelöst habe?

→ Teil 2: Das Gedächtnis — wie das System lernt, sich zu erinnern