Local Memory Profile Building mit Honcho

tl;dr

• Honcho ist die Memory-Infrastruktur meines Second Brain — sie speichert keine Chunks, sondern baut ein dynamisches Modell meiner Person über Zeit auf
• Jeder Teilnehmer (ich, Hermes, Codex, OpenCode) ist ein Peer mit eigener Peer-Card und Beobachtungen
• Der Deriver extrahiert aus jeder Nachricht explizite und deduktive Beobachtungen über Peers
• Der Dreamer konsolidiert alle 50 Nachrichten (Threshold) neue Erkenntnisse in Induktionen und Reasoning-Trees
• Das Ganze läuft komplett lokal auf meinem MacBook — keine Cloud-Abhängigkeit
• Honcho injektiert zur Laufzeit Kontext in jeden LLM-Call, unabhängig vom genutzten Frontend

Kurzbeschreibung

Honcho ist ein Open-Source Memory-Infrastruktur-Projekt von Plastic Labs, das ich lokal self-hosted betreibe. Statt nur Nachrichten zu speichern, analysiert es Konversationen in Echtzeit, baut ein strukturiertes Modell der beteiligten Personen auf und stellt dieses Wissen jedem angeschlossenen KI-System zur Verfügung. Die Besonderheit: mehrere KI-Assistenten (Hermes, Codex, OpenCode) sind als eigenständige Peers mit eigener Perspektive repräsentiert — ein Multi-Agent-Memory-Layer.

Ausgangspunkt / Problemstellung

KI-Assistenten haben standardmäßig kein Gedächtnis. Jede Sitzung beginnt bei Null. Die gängigen Workarounds — System-Prompts, lange Kontext-Fenster, manuelle Zusammenfassungen — sind brüchig, nicht skalierbar und gehen nicht über einzelne Sessions hinaus.

Für mein Second-Brain brauchte ich:

• Ein System, das über Sessions und Tools hinweg lernt
• Das nicht nur speichert, sondern aktiv Schlüsse zieht (explizit + deduktiv + induktiv)
• Das lokal läuft — meine Daten gehören mir
• Das mehrere KI-Agenten gleichzeitig versorgen kann
• Das sich für unterschiedliche LLM-Frontends (Hermes, Codex, OpenCode) als einheitliche Memory-Schicht nutzen lässt

Idee

Jeder Teilnehmer — Mensch oder KI — wird als Peer modelliert. Peers haben:

• Peer Cards: kompakte Zusammenfassungen der wichtigsten Fakten einer Person (analog zu einer Visitenkarte)
• Beobachtungen (Explizit, Deduktiv, Induktiv): fortlaufend extrahierte Erkenntnisse aus Nachrichten
• Representations: ein LLM-generiertes Persönlichkeitsbild, das aus allen Beobachtungen synthetisiert wird

Vom gesendeten Prompt zur injizierten Kontext-Erweiterung — Honcho arbeitet asynchron im Hintergrund.

Welche Hypothese steckt dahinter?

Ein Reasoning-First Memory (Schlussfolgerungen statt Vektor-Ähnlichkeit) erzeugt stabilere, relevantere Nutzerprofile als reine Embedding-basierte RAG-Systeme. Durch mehrstufige Verarbeitung (Deriver → Dreamer) entstehen nicht nur Fakten, sondern echte Reasoning Trees — Begründungsketten, die erklären, warum das System eine bestimmte Annahme über den Nutzer hat.

Die Dual-Peer-Architektur (jeder Agent hat seine eigene Beobachter-Perspektive) erlaubt differenzierte Profile: Hermes’ Wissen über Patrick kann sich von Codex’ Wissen unterscheiden, je nachdem welche Interaktionen sie hatten.

Warum das relevant ist

Das Projekt löst das grundlegende Gedächtnisproblem lokaler KI-Assistenten — ohne Cloud, ohne Vendor-Lock-in. Es ist:

• Für mich: Single Source of Truth für alle Kunden- und Projektkontexte
• Für andere Entwickler: Blaupause für selbst-gehostete Memory-Infrastruktur mit mehreren Agenten
• Für die AI-Community: Praxisbeispiel einer Reasoning-First-Memory-Architektur im Produktiveinsatz

Geschachtelte Systemarchitektur: Jeder Agent ist ein Peer mit eigener Karte und Beobachtungen.

Ansatz

Die Architektur folgt einem asynchronen Pipeline-Modell mit mehreren spezialisierten LLM-Agenten:

Deriver (phi4-mini 3.8B)

Der Deriver ist der erste Verarbeitungsschritt. Sobald eine Nachricht über die Honcho-API eingeht, wird sie in die representation-Queue eingereiht. Der Deriver verarbeitet Batches von Nachrichten und extrahiert:

• Explizite Beobachtungen: direkte Fakten (“Patrick arbeitet an Honcho-Integration”)
• Deduktive Beobachtungen: logische Schlussfolgerungen (“Patrick beschäftigt sich mit Memory-Architektur → hat Erfahrung mit KI-Systemen”)

Er läuft auf einem phi4-mini (3.8B) via Ollama — ein bewusster Kompromiss zwischen Geschwindigkeit und Qualität für die Massenverarbeitung.

Dreamer (gemma4:12b)

Der Dreamer ist der Konsolidierungs-Mechanismus. Alle 50 neuen Dokumente (Threshold) oder nach 8h Inaktivität (Cooldown) wird ein Dream ausgelöst:

1. DeductionSpecialist: zieht neue deduktive Schlüsse aus vorhandenen expliziten Beobachtungen
2. InductionSpecialist: erzeugt induktive Verallgemeinerungen (“Patrick investiert wiederholt in lokale AI-Infrastruktur → Priorität: Souveränität”)

Die Ergebnisse werden in Reasoning Trees gespeichert — jedes Conclusion-Objekt verweist auf seine Prämissen und abgeleiteten Schlüsse.

Der Dreamer läuft auf gemma4:12b (NVFP4) via Ollama, da hier Qualität vor Geschwindigkeit geht.

Dialectic Agent

Auf Anfrage (Chat-Endpoint) durchsucht der Dialectic-Agent mit einem Tool-Loop die gespeicherten Observations, Peer Cards und Sessions und generiert eine kontextbewusste Antwort. Fünf Reasoning-Levels (minimal → max) steuern die Tiefe der Suche.

Dual-Peer-Architektur

Jeder angeschlossene Client hat eine eigene Peer Card:

• Peer Patrick: enthält Identität, Präferenzen, laufende Projekte, beruflicher Kontext
• Peer Hermes: enthält Systemkontext, verfügbare Tools, Kommunikationsstil
• Peer Codex / OpenCode: enthalten Code-Knowledge, Workspace-Struktur, verwendete Technologien

Dank Directional Peer Cards kann jeder Peer eine eigene Sicht auf die anderen haben — Hermes’ Bild von Patrick unterscheidet sich potenziell von Codex’ Bild.

Lokale Ausführung

Das gesamte Setup läuft auf meinem MacBook:

• Honcho API + Deriver + Dreamer: Docker-Container mit Postgres & Redis
• LLM-Inferenz: Ollama (phi4-mini für Deriver, gemma4:12b für Dream)
• MCP-Integration: Hermes greift über Honcho-MCP auf Memory zu
• Keine Cloud-Abhängigkeit: alle API-Calls gehen an localhost

Typischer Ablauf: Prompt → Deriver → Dream-Zyklus → Context-Injektion

Aktueller Stand

Status: Aktiv — im täglichen Produktiveinsatz

Bereits implementiert

• Selbst-gehostete Honcho-Instanz (v3) mit Postgres + Redis unter Docker
• Deriver aktiv mit phi4-mini (3.8B) via Ollama – verarbeitet alle eingehenden Messages
• Dream-Mechanismus konfiguriert (Threshold=50, Cooldown=8h, Idle=60min)
• Deduction- + Induction-Specialists aktiv auf gemma4:12b
• Peer Cards für Patrick, Hermes, Codex und OpenCode angelegt
• Honcho-MCP-Integration in Hermes aktiv (via MCP-Server)
• Kontext-Injektion in jede Hermes-Session (Representation + Observations)
• Import bestehender Sessions (OpenCode/Codex) abgeschlossen

In Entwicklung / geplant

• Feintuning des Dream-Triggers (Threshold/Surprisal-Balance)
• Modell-Optimierung: MLX-Runtime-Tests für schnellere Deriver-Inferenz
• Benchmark: phi4-mini vs. gemma4:e2b vs. gemma4:e4b (aktuell in Evaluierung)
• Automatisierte Dream-Qualitätskontrolle (leere/nichtssagende Induktionen erkennen)
• Historischen Import von älteren Hermes-Sessions (pre-Honcho-Integration)
• Integration in das geplante “Second Brain” Projekt als zentrale Memory-Komponente

Erkenntnisse

1. Reasoning-first schlägt reines RAG für persistente Profile — die extrahierten Beobachtungen sind robuster als reine Embedding-Ähnlichkeit
2. Der Deriver-Flaschenhals ist real — phi4-mini auf CPU (vor GPU-Konfiguration) verarbeitet nur ~5-6s pro Work-Item; GPU-Beschleunigung ist essentiell
3. Dream-Qualität hängt stark vom Modell ab — gemma4:12b liefert deutlich brauchbarere Induktionen als kleinere Modelle; der Qualitäts-/Geschwindigkeits-Kompromiss bei der Modellwahl ist der kritischste Config-Hebel
4. Dual-Peer-Architektur ist mächtig, aber aufwändig — je mehr Peers, desto komplexer wird die Abstimmung der Observation-Permissionen und Perspektiven
5. MCP als Integrationsmuster ist der Game-Changer — Honcho via MCP anzubinden macht die Memory-Schicht für jedes MCP-kompatible Frontend nutzbar, ohne jeweils SDK-Integration zu schreiben

Nächste Schritte

1. MLX-Benchmark durchführen — phi4-mini (Ollama) vs. gemma4:e2b (MLX) vs. gemma4:e4b (MLX) mit echten Deriver-Prompts messen
2. GPU-Konfiguration optimieren — Ollama auf Metal-Backend umstellen für niedrigere Token-Latenzen
3. Dream-Schedule verfeinern — Surprisal-basierte Priorisierung statt festem Threshold evaluieren
4. Peer-Card-Qualität verbessern — Automatisierte Prüfung, ob Cards aktuell und konsistent sind
5. Second-Brain-Projekt dokumentieren — Honcho als Kernkomponente des übergreifenden Memory-Systems

Persönliche Note

Honcho ist für mich mehr als nur ein Tool — es ist die zentrale Memory-Infrastruktur, auf der mein gesamtes Second-Brain aufbaut. Die Idee, dass nicht nur ich, sondern auch meine KI-Assistenten ein eigenes “Profil” haben, das sich über Zeit weiterentwickelt, fühlt sich an wie der nächste logische Schritt in der Mensch-Maschine-Kollaboration. Dass alles lokal läuft, ist für mich nicht verhandelbar — meine Daten, meine Kontrolle, meine Infrastruktur. Die Arbeit am MLX-Benchmark und Deriver-Tuning zeigt, wie früh wir in dieser Entwicklung noch stehen: das Konzept ist überzeugend, aber die Optimierung für Consumer-Hardware ist noch Handarbeit. Genau das reizt mich.

FAQ

Was ist Honcho genau?
Honcho ist eine Open-Source Memory-Infrastruktur, die Beobachtungen aus Konversationen extrahiert und persistente Profile von Nutzern und KI-Agenten aufbaut — als Reasoning-First-Alternative zu reinen Vektor-Datenbanken.

Was ist ein Peer?
Ein Peer ist jeder Teilnehmer im System — Mensch oder KI. Jeder Peer hat eine eigene Peer Card (kompakte Faktenübersicht) und eine Representation (LLM-synthetisiertes Persönlichkeitsbild).

Was ist ein Dream?
Ein Dream ist ein Konsolidierungs-Durchlauf, bei dem Honcho vorhandene Beobachtungen analysiert, neue induktive Schlüsse zieht und Reasoning Trees aufbaut. Er wird automatisch nach 50 neuen Nachrichten oder 8 Stunden Inaktivität getriggert.

Was ist der Deriver?
Der Deriver ist der asynchrone Hintergrund-Prozess, der eingehende Nachrichten analysiert und explizite sowie deduktive Beobachtungen über die beteiligten Peers extrahiert.

Läuft Honcho wirklich komplett lokal?
Ja. Honcho-API, Postgres, Redis, Deriver und Dreamer laufen in Docker auf meinem MacBook. Die LLM-Inferenz erfolgt über lokale Ollama-Modelle. Kein externer API-Call.

Welche LLM-Modelle nutzt Honcho bei dir?
Deriver: phi4-mini (3.8B) via Ollama. Dreamer: gemma4:12b (NVFP4) via Ollama. Embeddings: Nomic Embed Text (768d). Dialectic: konfigurierbar pro Reasoning-Level.

Was ist eine Peer Card vs. eine Representation?
Die Peer Card ist eine kompakte, menschenlesbare Liste von Fakten (analog zur Visitenkarte). Die Representation ist ein LLM-generierter Fließtext, der das Gesamtbild der Person aus allen Observations synthetisiert.

Kann Honcho mit mehreren KI-Assistenten gleichzeitig arbeiten?
Ja. Honcho nutzt eine Dual-Peer-Architektur — jeder Assistent (Hermes, Codex, OpenCode) ist ein eigener Peer mit eigener Perspektive und Observations. Über Directional Peer Cards kann jeder Peer eine andere Sicht auf die anderen haben.

Was ist der Unterschied zu RAG / Vektor-DBs?
RAG sucht nach ähnlichen Text-Chunks. Honcho extrahiert aktiv Schlussfolgerungen (Observations) aus Nachrichten und baut ein strukturiertes Modell der Person auf — nicht des Texts. Das ist robuster gegen Umformulierungen und liefert kontextuell dichtere Ergebnisse.

Wie wird der Honcho-Kontext in die LLM-Sessions injiziert?
Über den Honcho-MCP-Server. Bei Session-Start ruft Hermes die Representation und Peer Card des Users ab und injiziert sie als System-Kontext. Zusätzlich können Observations per Dialectic-Agent on Demand abgefragt werden.