Fremdes Second Brain evaluieren: JonasKruegerCode/SecondBrain

Ausgangslage aus dem Capture: Dich interessiert, wie das Repo JonasKruegerCode/SecondBrain technisch umgesetzt ist und ob du etwas davon für dein eigenes Second Brain übernehmen könntest. Kurzfazit vorweg: Es ist im Kern dieselbe Idee wie meine (Karpathys LLM-Wiki, Markdown-Vault in Git, Review-Agent), aber als schwergewichtiger, selbst gehosteter RAG-Dienst gebaut. Die portable Idee zum Mitnehmen ist die MCP-Schnittstelle, nicht der Datenbank-Stack.

1. 🔍 Was das Repo technisch ist

Ein persistenter MCP-Memory-Layer für KI-Agenten (Python, MIT-Lizenz, self-hosted via Docker Compose). Ein Agent (claude.ai, OpenClaw oder eigener MCP-Client) bekommt zwei Werkzeuge:

ToolWas es tut
remember(text)Zerlegt den Input in einzelne Themen, sucht verwandte bestehende Seiten, lässt einen LLM-Planungsagenten (Wikipedia-Stil) entscheiden, was neu/aktualisiert wird, schreibt Markdown-Wiki-Seiten in einen Git-Vault, updatet Graph und Index. Läuft asynchron.
recall(query)HybridRAG: Vektorsuche plus Graph-Traversierung plus LLM-Synthese, gibt eine kontextuelle Antwort aus dem Wiki zurück.

Der Speicher liegt in vier Schichten: ein Markdown-Vault (Git-synct, Obsidian-kompatibel), ein Neo4j-Graph (Linkstruktur über [[wikilinks]]), ein Qdrant-Vektorindex (semantische Ähnlichkeit) und eine Redis/Celery-Queue (asynchrones Ingest, geplanter Review). Dazu ein stündlicher Review-Agent, der verwandte Seiten verlinkt und Widersprüche auflöst, plus eine Web-UI mit Graph-Visualisierung. LLM-Calls laufen über OpenRouter oder Google AI.

2. 🪞 Wo das meinem Modell gleicht

Auffällig viel. Mein Konzept-Post beschreibt fast dieselben Bausteine, nur anders gewichtet:

BausteinJonasMein Setup
Single Source of TruthMarkdown-Vault in GitMarkdown in Git, identisch
Ingest-Ideeremember() mit Planungsagent (anlegen/aktualisieren)Ingest-Lauf (Agent draftet OKF-Seite), siehe Betrieb & Moderation
Lint/Pflegestündlicher Review-Agent (Querlinks, Widersprüche)periodischer Lint-Lauf, gleiche Aufgabe
GraphNeo4j über [[wikilinks]]Markdown-Links als Graph
DenkfigurWikipedia-Agent = einmal kompilieren«kompilieren statt abrufen» (Karpathy)

Das ist eine schöne Bestätigung: Zwei unabhängige Umsetzungen derselben Denkfigur landen bei Markdown-Vault plus Ingest-Agent plus Review-Agent.

3. ⚖️ Wo es bewusst anders ist

Der zentrale Unterschied ist die Abruf-Seite. Jonas legt über den Vault eine HybridRAG-Schicht (Qdrant plus Neo4j plus LLM-Synthese). Genau das lehnt mein Konzept-Post bewusst ab: Ich will die Seite einmal sauber kompiliert lesen, nicht bei jeder Frage neu aus Vektor-Nachbarschaften zusammensynthetisieren lassen. Sein recall() ist gemietete RAG-Infrastruktur, mein Modell ist die fertige Wiki-Seite.

Der zweite Unterschied ist das Gewicht. Sein Stack braucht einen Docker-Host mit Neo4j, Qdrant, Redis, Celery plus einen bezahlten LLM-Key (OpenRouter/GCP) für jeden remember/recall-Call. Das ist kein Free-Tier und kein «liegt einfach als Files da». Meins läuft auf Cloudflare-Free-Tier und statischem Hugo. Den vollen Stack zu übernehmen, würde meine zwei Leitplanken (vendor-frei, Free-Tier) brechen.

Analogie: Bibliothek mit und ohne Auskunft

Wie eine [Bibliothek]: Wir führen beide denselben Katalog aus sauber geschriebenen Karten (Markdown-Vault). Jonas stellt zusätzlich einen Auskunftsroboter an den Eingang, der dir auf Zuruf aus mehreren Karten eine Antwort zusammenredet (HybridRAG). Praktisch, aber der Roboter braucht Strom, Wartung und Gehalt (Server, Datenbanken, LLM-Calls). Ich gehe lieber selbst ins Regal und lese die fertige Karte. Beide haben denselben Katalog, nur einer bezahlt laufend für die Auskunft.

4. 🍴 Was konkret übernehmenswert ist

Drei Kandidaten, nach Passung sortiert:

  1. MCP-Schnittstelle (remember/recall) als Agenten-Interface. Das ist die stärkste Idee. Statt nur über den Handy-Worter in die inbox/ zu schreiben, könnte jeder MCP-fähige Agent direkt ins Brain schreiben und lesen. Passt zu meinem Modell, ohne den RAG-Stack zu erzwingen: man kann ein remember bauen, das schlicht eine inbox/-Datei ablegt, und ein recall, das die kompilierte Seite liefert statt RAG zu fahren.
  2. remember() zerlegt einen Input in mehrere Themen. Kleine, gute Verfeinerung für meinen Ingest: Ein Capture darf zu mehreren OKF-Seiten werden statt zu einer. Meine Triage macht das implizit schon, explizit «in unabhängige Themen splitten» schärft es.
  3. Review-Agent als geplanter Lauf. Bestätigt, was ich ohnehin mit geplanten Tasks mache. Sein stündlicher Rhythmus ist mir zu aggressiv (mein Modell ist write-first mit Mensch-Review), aber die Aufgabe (Querlinks, Widersprüche) ist deckungsgleich mit meinem Lint.

Nicht übernehmen: Neo4j, Qdrant, Redis/Celery und die HybridRAG-Abrufschicht. Das ist genau die «gemietete» Variante, gegen die mein Konzept argumentiert, und es kostet Free-Tier und Einfachheit.

5. 📝 Fazit

Gutes Vergleichsobjekt, weil es dieselbe Denkfigur unabhängig umsetzt. Es bestätigt meinen Vault-plus-Ingest-plus-Lint-Aufbau und liefert mit der MCP-Schnittstelle eine konkrete Erweiterungsidee. Den Datenbank- und RAG-Teil lasse ich liegen, das ist der bewusste Gegenentwurf, nicht ein Defizit meines Setups.

📚 Weiterführende Links & Quellen