Hindsight: Ein Agent-Memory-System, das mich begeistert hat

Jeder, der täglich mit Claude Code, Codex CLI oder opencode arbeitet, kennt das Problem: Der Agent ist am Ende jeder Session wieder bei null. Man erklärt zum gefühlt zehnten Mal den Tech-Stack, die Team-Konventionen, warum man Redis-Caching vor drei Monaten wieder verworfen hat. Notizen in System-Prompts oder CLAUDE.md-Dateien helfen, skalieren aber nicht – sie erfassen keine gewachsene, sich verändernde Wissensbasis, sondern nur einen statischen Snapshot.

Ich bin seit ein paar Wochen mit Hindsight unterwegs, einem Open-Source-Memory-System von Vectorize.io, und bin ziemlich angetan. Oder sagen wir es wie es ist. Ich bin seit langem mal wieder richtig begeistert von einer Software-Lösung gewesen. Es macht genau das, was man sich unter "Agent-Gedächtnis" vorstellt, wenn man es nicht auf die naive Vektor-DB-Lösung reduziert. Es haben sich für mich gedanklich aber auch technisch neue Welten aufgetan.

Warum sollte man Hindsight nutzen?

Bevor ich in die technischen Details gehe, kurz die drei Gründe, die für mich den Ausschlag gegeben haben:

• Erhöhte Kontextkontinuität: Agenten behalten relevantes Vorwissen über Sessions hinweg und liefern dadurch konsistente, personalisierte Empfehlungen – statt bei jeder neuen Session wieder bei null anzufangen.
• Bessere Genauigkeit bei komplexen Fragen: Temporal- und Graph-Retrieval kombiniert mit automatischer Beobachtungs-Konsolidierung erhöhen die Trefferquote spürbar, gerade bei historischen oder indirekt verknüpften Fakten.
• Kontrollierte, erklärbare Erinnerungs-Logik: Missionen und Direktiven schaffen Sicherheits- und Compliance-Guardrails, Evidenz-Tracking macht nachvollziehbar, worauf eine Antwort eigentlich basiert.

Was Hindsight ist – und was nicht

Der wichtigste Punkt zuerst: Hindsight ist keine reine Vektor-Datenbank mit hübscher API drumherum. Wer Rohdaten reinwirft und hofft, dass Cosine-Similarity am Ende die richtige Antwort liefert, wird von naiven RAG-Ansätzen regelmäßig enttäuscht. Sobald man ein paar hundert Memories über verschiedene Themen und Zeiträume hat, bricht das Prinzip "Embed alles, hol dir Top-K" oft zusammen.

Hindsight geht einen anderen Weg. Im Hintergrund läuft PostgreSQL mit der pgvector-Extension als Speicher, aber was aber genutzt wird, sind nicht die Rohdaten, sondern das Ergebnis eines Extraktionsprozesses: strukturierte Fakten, aufgelöste Entitäten (aus "Alice" und "meine Kollegin Alice" wird ein und dieselbe Entität), Zeitstempel für temporale Auswertungen und ein Wissensgraph, der die Beziehungen zwischen den Entitäten abbildet. Wer jetzt angst um seine Daten hat... ok, es sind auch die Dokumente in der Postgres Datenbank weiterhin gespeichert als "Document". Aber die reinen Dokuemten sind eben in dem gesamten Prozess nicht das spannende sondern die aufbereiteten Daten.

Angebunden wird das Ganze über MCP – Claude Code, Codex, opencode, Cursor, VS Code, praktisch jeder MCP-fähige Client kann sich verbinden. Für die interne Verarbeitung (Fakten-Extraktion, Entity-Resolution, Reflect-Operationen) braucht Hindsight einen eigenen LLM-Provider – unabhängig vom Modell, das der eigentliche Agent nutzt. Das ist ein Detail, das mir gut gefällt: Man kann hier bewusst ein günstiges, schnelles Modell einsetzen, weil diese Verarbeitung im Hintergrund läuft und nicht die Qualität der eigentlichen Agent-Antworten beeinflusst. Ich habe für meine Tests das GPT-5.6 Luna Modell verwendet, weil es erstmal auf meine private Rechnung lief. Trotz des günstigen Modells habe ich aber richtig gute Ergebnisse bekommen. Man kann in Hindsight aber auch mehrere Modelle nutzen und falles feintunen. Ich habe ehrlicherweise bisher vielleicht 30-40% der Funktionen ausprobiert. Aber das macht nichts. Man bekommen einfach schnell Ergebnisse und kann mit den Daten arbeiten und auch selbst die Daten verbessern. Wie? Das kommt jetzt.

Die drei Kernoperationen

Hindsight bietet drei zentrale Operationen, die als MCP-Tools zur Verfügung stehen:

retain – Speichern. Man füttert Hindsight mit Text (eine einzelne Tatsache, eine ganze Konversation, ein Dokument), und im Hintergrund extrahiert ein LLM strukturierte Fakten, löst Entitäten auf, erzeugt Embeddings und indiziert alles für die spätere Suche. Wichtig: Man sollte nicht vorab selbst zusammenfassen oder Fakten extrahieren – Hindsight braucht den vollen Kontext einer Konversation, sonst wird aus "ja, genau" oder "ich nehme Option 2" schlicht bedeutungsloser Text.

recall – Suchen. Hier laufen vier Retrieval-Strategien parallel: semantische Suche, BM25-Keyword-Matching, Graph-Traversal über den Wissensgraphen und temporale Filterung. Die Ergebnisse werden anschließend per Cross-Encoder-Reranking sortiert. Das ist der eigentliche Clou gegenüber einer simplen Vektorsuche: Eine Frage wie "Was haben wir zum Caching entschieden?" findet die richtige Antwort auch dann, wenn die ursprüngliche Memory eine andere Terminologie verwendet.

reflect – Synthetisieren. Reflect geht über reines Abrufen hinaus und lässt ein LLM über mehrere Memories hinweg Schlüsse ziehen – etwa auf die Frage "Welchen Tech-Stack würdest du mir basierend auf meinen bisherigen Entscheidungen empfehlen?".

flowchart LR    
    subgraph YourApp["Your Application"]
        A["AI Agent"]
    end

    subgraph Hindsight["Hindsight"]
        API["API Server"]

        subgraph MemoryBank["Memory Bank"]
            direction TB
            MM["Mental Models"]
            OBS["Observations"]
            ME["Memories & Entities"]
            CH["Chunks"]
            DOC["Documents"]

            MM --> OBS
            OBS --> ME
            ME --> CH
            CH --> DOC
        end
    end

    A -->|retain| API
    A -->|recall| API
    A -->|reflect| API

    API --> ME

Extraktionsstrategien und Tagging

Ein Punkt, der in der Praxis unterschätzt wird: Nicht jede Datenquelle soll gleich verarbeitet werden. Hindsight bietet dafür benannte Retain-Strategien – etwa verbatim für Inhalte, die wortwörtlich gespeichert werden sollen, oder chunks für größere Dokumente, die in Abschnitte zerlegt werden. Diese Strategien lassen sich in der Bank-Konfiguration definieren und dann je nach Quelle gezielt beim retain-Aufruf auswählen.

Dazu kommt ein Tagging-System mit sogenannten Entity Labels: kontrollierte Vokabulare nach dem Schema key:value, etwa user:christian oder topic:architektur, die beim Speichern automatisch extrahiert werden können. Für die reine inhaltliche Suche braucht man das oft gar nicht – Entitäten landen ohnehin im Wissensgraph und treiben die Graph-basierte Suche an. Für explizite Filterung auf entitätsähnliche Werte sind die Tags aber Gold wert, gerade wenn man mehrere Projekte oder Kunden in einer Bank sauber getrennt halten will.

Mental Models: lebende Dokumente

Was mich am meisten überzeugt hat, sind die Mental Models. Man definiert eine Frage – zum Beispiel "Welche Architekturentscheidungen wurden für Projekt X getroffen?" – und Hindsight erzeugt daraus ein Dokument, das sich automatisch aktualisiert, sobald neue Memories dazukommen oder sich bestehende Dokumente ändern. Man muss also nicht bei jeder Anfrage ein volles reflect über den kompletten Memory-Bestand laufen lassen, sondern bekommt eine Art vorberechnete, immer aktuelle Zusammenfassung.

Technisch läuft das asynchron über eine Queue: Die eigentliche LLM-gestützte Generierung passiert im Hintergrund, ein API-Aufruf liefert zunächst nur eine Operation-ID zurück, das fertige Ergebnis ist dann nach ein paar Sekunden abrufbar. Das ist konsequent zu Ende gedacht, hat aber auch eine Kehrseite, dazu gleich mehr.

Skalieren ist auch kein Problem, denn es gibt im Konzept auch Worker-Instanzen die dann auch per Kubernetes skaliert werden können. Das ist alles möglich. In meinem Homelab Setup tut es auch ein einzelner Worker in einem fixen Docker-Container.

Visualisierung

Im Control Plane – dem Admin-UI von Hindsight – gibt es die sogenannte Constellation View: eine interaktive, zoombare Graphdarstellung der Entity-Relationships mit Heat-Gradient-Einfärbung, auch im Dark Mode nutzbar. Für mich ist das mehr als nur ein nettes Feature – bei einem wachsenden Wissensgraphen hilft die visuelle Übersicht enorm dabei, ein Gefühl dafür zu bekommen, was die eigene Memory-Bank eigentlich "weiß" und wo die Extraktion vielleicht danebenliegt.

Natürlich kann man auch filtern, zoomen und auf die einzelnen dahinterliegenden Dokumente schauen.

Features im Überblick

Ein paar Punkte aus der Gesamtliste, die im Artikel bisher noch nicht vorkamen, aber zum Verständnis dazugehören:

• Hierarchische Memory-Typen: Neben Mental Models (kuratierte, selbst definierte Zusammenfassungen) gibt es Observations – automatisch aus Rohfakten konsolidierte, evidenzgestützte Glaubenssätze –, außerdem World Facts und Experience Facts. Diese Trennung sorgt dafür, dass reflect bei der Beantwortung einer Frage zuerst die Mental Models prüft, dann die Observations und erst zuletzt auf Rohfakten zurückgreift.
• Multi-Strategie-Retrieval (TEMPR): Die vier parallelen Suchstrategien aus recall – Semantic, Keyword/BM25, Graph, Temporal – laufen unter dem Namen TEMPR und werden per Reciprocal-Rank-Fusion zusammengeführt, bevor das Cross-Encoder-Reranking greift. Das macht den Abruf auch bei zeitlich oder graphbasiert verknüpften Fragen robust.
• Observation Consolidation: Nach jedem retain-Aufruf läuft im Hintergrund automatisch ein Konsolidierungsprozess, der neue Fakten gegen bestehende Observations abgleicht, dedupliziert und mit Evidenz-Verweisen versieht. Beobachtungen, die durch neuere, noch nicht konsolidierte Fakten überholt sein könnten, werden dabei als "stale" markiert und vor der Nutzung gegen die Rohfakten verifiziert.
• Temporal Reasoning: Abfragen wie "letzten Frühling" oder "im Juni" werden nicht nur semantisch, sondern explizit zeitbasiert aufgelöst – ein Bereich, in dem reine Vektorsuche typischerweise versagt.
• Missions- und Richtlinien-Konfiguration: Auf Bank-Ebene lässt sich eine Mission definieren, die vorgibt, welches Wissen priorisiert werden soll, dazu unveränderliche Direktiven als Compliance-Guardrails und Disposition-Traits wie Skepsis, Literalität oder Empathie, die beeinflussen, wie reflect Argumente gewichtet. Wichtig: Diese Einstellungen wirken nur auf reflect, nicht auf recall.
• Evidenz-gestützte Antworten: Observations verweisen auf ihre Quell-Memories inklusive Zitat-Belegen und Proof-Counts – das macht die Herleitung einer Antwort nachvollziehbar, statt sie als Black Box hinzunehmen.
• Clients & SDKs: Offizielle SDKs für Python, TypeScript und Go, dazu CLI und HTTP-API – die Integration in bestehende Agent-Stacks jenseits von MCP ist damit unkompliziert.
• Deployment-Optionen: Neben dem lokalen Docker-Setup, wie ich es im Homelab nutze, gibt es Helm-Charts für Kubernetes, eine pip-Installation für den schnellen lokalen Test sowie einen Integrations-Hub für angebundene Datenquellen.

Wie kommen Daten ins System?

Daten können auf verschiedenen Wegen in das Memory gelangen. Wird der MCP-Server genutzt kann einfach über das retain Tool etwas gespeichert werden. Bei jedem erfassten Dokumente können Tags und eine eindeutige Document-ID definiert werden. Das definieren der Document-ID ist optional. Wird keine mitgesendet, erstellt das System eine UUID.
Wenn man Rohdaten z.B. Chatverläuft speicher will, dann reicht es die generierte UUID zu verwenden. Wenn es Daten wie z.B. der Inhalt hinter Webseite sind, dann kann die Document-ID auch eine URL sein. Wird mit der gleichen Document-ID ein neues Dokument gesendet, dann aktualisiert Hindsight auch den bestehenden Eintrag.
Zusätzlich lassen sich in Hindsight auch für verschiedene Quellen dann unterschiedliche strategien für das extrahieren der Daten definieren. Man kann dann auch Einfluss auf die RAG spezifischen Parameter wie die Chunk-Size nehmen.

Da Hindsight durchgängig so konzipiert wurde, dass alles was die UI macht über eine REST-API kommuniziert, ist es auch ein einfaches die gleiche API für das importieren von Daten zu nutzen.
Beispielhaft habe ich mal ein n8n Community Plugin installiert, dass einfach die drei Grundopterationen in einem n8n Node abbildet.

Mein Setup im Homelab

Ich habe mir das Ganze nicht in der Cloud, sondern in meinem Homelab aufgesetzt – zwei LXC-Container, einer für die API, einer für das Admin-UI beziehungsweise Control Plane. Die Datenbank musste ich nicht neu aufsetzen: Ich hatte bereits einen PostgreSQL-Server mit pgvector-Extension laufen und musste dort nur eine zusätzliche Datenbank anlegen. Das hat das Setup deutlich vereinfacht – wer schon eine Postgres-Instanz mit pgvector betreibt, ist hier in Minuten startklar, statt sich mit der eingebetteten PostgreSQL-Variante aus dem Docker-Quickstart herumzuschlagen.

Als LLM-Provider für die interne Verarbeitung habe ich schnell OpenRouter angebunden und dort auf GPT-5.6 Luna gesetzt – die günstige, latenzoptimierte Variante aus OpenAIs GPT-5.6-Serie, gedacht für genau solche hochfrequenten, aber nicht sonderlich anspruchsvollen Hintergrundaufgaben wie Fact-Extraction. Das Modell lässt sich aber problemlos austauschen: Hindsight unterstützt eine breite Auswahl an Providern, von OpenAI über Anthropic und Gemini bis zu lokalen Modellen über Ollama oder llama.cpp. Wer die interne Verarbeitung lieber komplett offline und ohne externe API-Calls fahren will, kann das inzwischen ebenfalls tun.

Integration in andere Systeme

Über MCP lässt sich Hindsight praktisch überall andocken, wo ein Client den Standard spricht – Claude Code, Codex CLI, opencode und weitere Coding-Agents sind direkt unterstützt, teils sogar mit automatischer Ingestion ohne zusätzlichen Setup-Schritt.

Der MCP Server ist direkt in Hindsight enthalten und kann für jede Memory-Bank einzeln eingestellt werden. Man kann auch die MCP-Tools beschränken.

Ich habe bei mir nichts beschränkt da ich sowieso noch einen zwischengeschalteten LiteLLM-Gateway habe.

Use Cases

Der naheliegendste Use Case für mich persönlich ist gar nicht primär technisch: Ich möchte Daten rund um den Fußballverein Wormatia Worms aufbereiten, um die Mitarbeiter in der Geschäftsstelle zu entlasten. Statt jede Anfrage manuell zu beantworten, könnte ein Agent auf einer Hindsight-Bank mit historischen Informationen, Vereinsregeln und wiederkehrenden Fragen aufsetzen und so einen echten Teil der Kommunikationslast abnehmen.

Daneben baue ich gerade eine zweite, eigene Bank auf: Dort arbeite ich die Vereinschronik, Saisonergebnisse und Spieler-Steckbriefe ein. Das Interessante hier ist nicht der reine Abruf einzelner Fakten, sondern dass das System selbstständig statistische Besonderheiten und Zusammenhänge über die eingespielten Daten hinweg entdecken soll – etwa, dass eine bestimmte Saison auffällig viele Unentschieden hatte oder ein Spieler in mehreren Spielzeiten überdurchschnittlich oft getroffen hat. Genau dafür ist reflect gedacht: nicht nur Fakten abrufen, sondern über den gesamten Datenbestand hinweg Schlüsse ziehen. Besonders spannend wird das für den Archivar des Vereins, der Fragen stellen möchte wie "Wann war die längste Siegesserie?" – Fragen, die kein einzelner Datensatz beantwortet, sondern die erst aus der Zusammenschau vieler Saisonergebnisse entstehen.

Im technischen Projektumfeld sehe ich mindestens zwei weitere sinnvolle Einsatzszenarien:

• Architektur- und Richtlinien-Gedächtnis: Ein Agent, der Softwarearchitektur-Entscheidungen, Coding-Guidelines und Projektkonventionen im Blick behält und Entwicklern direkt im Coding-Tool als Frage-Antwort-Instanz zur Verfügung steht – ohne dass diese erst in einem Wiki suchen müssen.
• Vollständigkeitsprüfung bei Anforderungen: In Projekten, in denen Anforderungen laufend erfasst werden, kann ein Agent mit Zugriff auf die gesammelten Memories prüfen, ob alle notwendigen Dokumente und Informationen vorliegen, und gezielt auf Lücken hinweisen. Gerade in Business-Kontexten mit vielen Stakeholdern ist das ein Szenario, das echten Mehrwert liefert.

Beurteilung

Was gut funktioniert: Der Einstieg ist erfreulich niedrigschwellig, insbesondere wenn – wie in meinem Fall – schon eine Postgres/pgvector-Instanz vorhanden ist. MCP als Anbindungsstandard bedeutet, dass man nicht für jeden Client eine eigene Integration bauen muss. Die Kombination aus Multi-Strategy-Retrieval und Reranking liefert in der Praxis spürbar bessere Trefferqualität als eine simple Vektorsuche, gerade bei größeren, thematisch gestreuten Memory-Beständen.

Gibt es bei dem Ansatz auch Dinge die mich stören? Nicht wirklch, aber man sollte sich bewusst sein, dass mit der steigenden Anzahl an Informationen und mit jedem Mental Model auch der Aufwand steigt alles aktuell zu halten. Es können schon einige Token-Kosten entstehen.
Jede retain-Operation bedeutet zusätzliche LLM-Calls für die interne Verarbeitung, das summiert sich bei hohem Volumen. Und der Reifegrad des Ökosystems ist noch nicht in Stein gemeißelt. Integrationen können sich relativ kurzfristig ändern.

Hier kommt es einfach darauf an ob man den Context/Memory auch als Wert für sich entdeckt hat.

Business-Ausblick

Für ein Projekt-Umfeld wie ich es bei valantic kenne sehe ich den größten Hebel darin, dass Agenten über Sessions hinweg Projektkontext, Kundenpräferenzen und getroffene Architekturentscheidungen behalten. Das bedeutet, dass weniger Zeit für wiederholte Kontext-Vermittlung, mehr Zeit für die eigentliche Wertschöpfung vorhanden ist. Das ist ein handfester Produktivitätsgewinn, gerade in längeren Projekten mit wechselnden Ansprechpartnern.

Gleichzeitig darf man die Governance-Frage nicht ausblenden: Wo landen die extrahierten Fakten, wer hat Zugriff auf die Memory-Bank, wie sauber lässt sich zwischen Kunden oder Projekten trennen? Self-Hosting via Docker beziehungsweise, wie in meinem Fall, im eigenen Homelab per LXC-Container ist hier eine valide Antwort – man behält die volle Kontrolle über die Daten, statt sie einem Cloud-Anbieter anzuvertrauen.

Fazit

Hindsight ist das erste Agent-Memory-System, das mich wirklich direkt begeistert hat, weil es Memory nicht auf "Text in eine Vektor-DB werfen" reduziert, sondern strukturierte Fakten, Entitäten, Zeitbezug und einen Wissensgraphen kombiniert. Das Setup im eigenen Homelab war dank vorhandener Postgres/pgvector-Infrastruktur überraschend unkompliziert, und die Kombination aus MCP-Standard und flexibler LLM-Provider-Wahl macht das System für sehr unterschiedliche Einsatzszenarien interessant – vom Vereinsalltag bei Wormatia Worms bis zum Architektur-Gedächtnis in technischen Projekten. Ich werde das in den kommenden Wochen weiter ausbauen und berichte, sobald sich daraus konkrete Workflows ergeben haben.