Hermes Agent Memory System: Wie persistenter KI-Speicher tatsächlich funktioniert

Sie kennen das Spiel. Sie öffnen einen Chat mit einem KI-Agenten, erklären Ihr Projekt, teilen Ihre Vorlieben mit, erledigen einige Aufgaben und schließen den Tab. Wenn Sie in der nächsten Woche zurückkommen, ist es, als würden Sie mit einem Fremden sprechen – der gesamte Kontext ist weg, jede Vorliebe vergessen, das Projekt muss von Grund auf neu erklärt werden.

Das ist kein Fehler. Es ist so, wie Large Language Models von Haus aus funktionieren. Sie sind zustandslos (stateless): Jede Anfrage ist unabhängig, jede Antwort wird basierend auf dem Prompt generiert, den Sie gerade senden, ohne Gedächtnis, ohne Historie und ohne Kontinuität über die Token im aktuellen Kontextfenster hinaus.

Für Interaktionen mit nur einem Durchgang ist das in Ordnung. Eine Frage stellen, eine Antwort erhalten, weitermachen. Aber für Agenten – Systeme, die über Sitzungen hinweg Dinge tun sollen, aus Fehlern lernen und sich mit Ihnen weiterentwickeln sollen – ist Zustandslosigkeit eine harte architektonische Grenze. Es ist eines der zentralen ungelösten Probleme in selbstgehosteten KI-Systemen.

Die Branche hat versucht, dies zu lösen. LangChain hat Memory-Module hinzugefügt. OpenAI hat Assistants mit Threads eingeführt. Frameworks wie Letta, Zep und Cognee haben ganze Architekturen um persistentes Gedächtnis herum aufgebaut. Databricks veröffentlichte Arbeiten zu „Memory Scaling“ – der Idee, dass sich die Leistung von Agenten mit der angesammelten Erfahrung verbessert. Seit 2024 sind spezialisierte Benchmark-Studien, Untersuchungen zu episodischem Gedächtnis und ein schnell wachsendes Ökosystem an Werkzeugen entstanden, um das Problem anzugehen, das zunehmend als eines der zentralen ungelösten Probleme der agentischen KI erkannt wird.

Die meisten dieser Ansätze teilen ein gemeinsames Problem: Sie behandeln Gedächtnis als nachträglichen Gedanken – als eine Datenbank, die man abfragt, ein Kontextfenster, das man vollstopft, oder ein Abrufsystem, das eher Latenz und Rauschen als Klarheit hinzufügt.

[https://www.glukhov.org/de/ai-systems/hermes/] Hermes Agent verfolgt einen grundlegend anderen Ansatz. Gedächtnis ist nichts, was der Agent bei Bedarf abruft. Es ist etwas, das der Agent zu jeder Zeit ist – fest im System-Prompt eingebaut, kuratiert, begrenzt und immer aktiv. Es ist klein genug, um schnell zu sein, strukturiert genug, um nützlich zu sein, und diszipliniert genug, um zu wissen, was man vergessen sollte.

Dieser Artikel erklärt genau, wie das funktioniert.

Teil 1: Das Problem des KI-Agenten-Gedächtnisses

Warum „Einfach mehr Kontext hinzufügen“ für Agenten nicht skalierbar ist

Die naheliegende Lösung für zustandslose KI ist das Hinzufügen von Kontext. Hängen Sie das vorherige Gespräch an. Fügen Sie die Projektdokumentation bei. Senden Sie die gesamte Historie mit.

Eine Zeit lang funktioniert das auch. Sie haben ein 128K-Kontextfenster. Da passt viel Text hinein.

Aber Kontext ist nicht dasselbe wie Gedächtnis – es gibt einen realen und wichtigen Unterschied zwischen ihnen. Kontext ist alles, was Ihnen gerade gezeigt wird; Gedächtnis ist das, was Sie aktiv behalten und mit sich führen.

Kontext hat keine Kuratierung. Er ist ein Datenmüll: Je größer er wird, desto mehr muss das Modell tausende von Token irrelevanter Historie verarbeiten, um die eine benötigte Tatsache zu finden. Das kostet Token und Geld, erhöht die Latenz und stößt irgendwann an seine Grenzen.

Gedächtnis hingegen ist kuratiert. Es ist die Destillation von Erfahrung in etwas Kompaktes und Handlungsrelevantes. Es wächst nicht unendlich – es konsolidiert, aktualisiert und vergisst.

Das menschliche Gedächtnis funktioniert auf die gleiche Weise. Sie erinnern sich nicht an jedes Gespräch, das Sie je geführt haben. Sie erinnern sich an die Teile, die wichtig sind: mit wem Sie sprechen, was diese Person interessiert, worauf Sie sich geeinigt haben, was Sie gelernt haben. Der Rest wird entweder vergessen oder ist durchsuchbar, wenn Sie ihn benötigen.

Die Forschungslandschaft

Der Bereich des Agenten-Gedächtnisses ist seit 2024 explodiert, mit dedizierten Benchmark-Suites, einer wachsenden Forschungsliteratur und einer messbaren Leistungslücke zwischen verschiedenen architektonischen Ansätzen. Hier ist der aktuelle Stand.

Letta (ehemals MemGPT) war eines der frühesten Frameworks, das persistentes Gedächtnis als vorrangiges Anliegen behandelte, und erreichte 21,7K GitHub-Stars. Es nutzt ein von Betriebssystemen inspiriertes Drei-Ebenen-Modell: Core Memory (klein, immer im Kontext), Recall Memory (durchsuchbare Gesprächshistorie) und Archival Memory (langfristiger Kaltspeicher). Die Erkenntnis, dass nicht alles Gedächtnis gleichwertig ist, war korrekt. Die Implementierung erfordert jedoch, dass Agenten vollständig innerhalb der Letta-Runtime laufen – die Nutzung bedeutet also die Übernahme der gesamten Plattform, nicht nur einer Gedächtnisschicht.

Zep / Graphiti konzentriert sich auf konversationelles Gedächtnis mit temporärem Entity-Tracking – Fakten haben Gültigkeitszeiträume, sodass der Graph weiß, wann etwas wahr war. Dies eignet sich gut für Chatbots, die Beziehungs-Graphen benötigen, ist aber weniger geeignet für autonome Agenten, die Umgebungsfakten und Projektkonventionen verfolgen.

Cognee ist für die Wissensextraktion aus Dokumenten und strukturierten Daten konzipiert, mit über 30 Ingestion-Connectoren und einem Knowledge-Graph-Backend. Es glänzt bei institutionellem Wissen und RAG-Pipelines, ist aber weniger auf das persönliche Agenten-Gedächtnis fokussiert. Weitere Informationen finden Sie im praktischen Setup-Leitfaden Self-hosting Cognee mit lokalen LLMs.

Hindsight nutzt Knowledge-Graph-basierten Abruf mit Entity-Beziehungen und einem einzigartigen reflect-Synthese-Tool, das eine über das Gedächtnis hinausgehende Synthese ermöglicht – indem mehrere Erinnerungen zu neuen Erkenntnissen kombiniert werden. Es gehört zu den leistungsstärksten Systemen in Agenten-Gedächtnis-Benchmarks und steht als Memory-Provider für Hermes Agent zur Verfügung.

Mem0 übernimmt die Gedächtnisextraktion serverseitig via LLM-Analyse und erfordert minimale Konfiguration. Das Mem0-Forschungspapier, veröffentlicht auf der ECAI 2025 (arXiv:2504.19413), hat zehn verschiedene Ansätze für KI-Gedächtnis verglichen und den Ansatz der selektiven Extraktion validiert – das Speichern diskreter Fakten, das Deduplizieren und das Abrufen von nur dem, was relevant ist. Mem0 ist auf etwa 48K GitHub-Stars angewachsen und unterstützt 21 Framework-Integrationen. Der Nachteil sind die Cloud-Abhängigkeit und die Kosten.

Die Memory-Scaling-Forschung von Databricks führte das Konzept ein, dass die Leistung von Agenten mit der angesammelten Erfahrung steigt. Ihre Architektur hält System-Prompts, Unternehmensressourcen sowie episodische/semantische Erinnerungen bereit, die auf Organisations- und Benutzerebene skaliert werden, was die Idee bestätigt, dass die Gedächtnisqualität ebenso wichtig ist wie die Modellkapazität.

Der gemeinsame Nenner der meisten Frameworks ist, dass sie Gedächtnis als ein Abrufproblem behandeln: Speichern Sie es irgendwo, fragen Sie es bei Bedarf ab, injizieren Sie es in den Kontext. Hermes macht das Gegenteil – Gedächtnis wird nicht auf Abruf abgerufen, es wird zu Beginn der Sitzung injiziert und ist immer präsent. Immer aktiv, immer verfügbar, ausreichend kuratiert, um nützlich zu bleiben.

Teil 2: Architektur

Lesen Sie diesen Teil von oben nach unten – zuerst die Ebenen und den Recall/Store pro Turn, dann was in MEMORY.md und USER.md steht, und schließlich wie man einen externen Provider anbindet.

Zwei Ebenen

Hermes stapelt das Gedächtnis in zwei Ebenen:

1. Integriert (Built-in) — MEMORY.md und USER.md, dateibasiert, immer aktiv. Mit festen Limits von 2.200 Zeichen (Agenten-Notizen) und 1.375 Zeichen (Benutzerprofil).
2. Ein externer Provider (optional) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory und andere, die Sie über die Konfiguration aktivieren. Es läuft immer nur ein externer Backend gleichzeitig. Er fügt neben den Dateien Abruf- und Speicherfunktionen hinzu; er ersetzt sie jedoch nicht.

Das mentale Modell ist additiv – feste Kern-Dateien plus höchstens ein Plugin. Prefetch- und Sync-Hooks orchestrieren die externe Ebene; die beiden Dateien werden separat als Teil des festen System-Prompts injiziert.

Runtime-Ablauf (Prefetch und Sync)

Der Abruf (Recall) geschieht, bevor das Modell antwortet; die Speicherung (Persistence) geschieht nach der Assistant-Nachricht. Im Memory-Manager von Hermes Agent entspricht dies dem prefetch beim Eingehen und dem sync beim Ausgehen. Die unten stehenden Namen entsprechen der Implementierung (MemoryManager, pro Provider prefetch / sync_turn / queue_prefetch).

User message
    |
    v
MemoryManager.prefetch_all(query)        <-- recall phase
    |
    +-- provider.prefetch(query)        <-- jeder externe Provider durchsucht seinen Speicher
    |
    v
Context injected into LLM turn
    |
    v
LLM responds (assistant message)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- store phase
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- Hintergrundsuche für den nächsten Turn

Die integrierten Dateien MEMORY.md und USER.md werden nicht über prefetch_all abgerufen – sie sind bereits Teil des festen System-Prompts. Externe Backends werden an prefetch_all / sync_all angeschlossen; queue_prefetch ermöglicht es einem Provider, den Abruf für den folgenden Turn vorzubereiten, ohne die aktuelle Antwort zu blockieren.

Drei Wege in das Langzeitgedächtnis

1. Integriertes memory Tool. Das Modell ruft memory mit add, replace oder remove auf, wenn Anweisungen besagen, dass etwas dauerhaft gespeichert werden soll – beständige Fakten, Vorlieben, Korrekturen, Umgebungshinweise. target='user' pflegt die USER.md; target='memory' pflegt die MEMORY.md. Beispielhafte Struktur: memory(action='add', target='user', content='…').

2. Passives Behalten durch externe Provider. In jedem Turn ruft das Framework den Sync-Pfad des Providers auf, sodass Konversationen in Stücke unterteilt, zusammengefasst oder extrahiert werden können, ohne dass das Modell jeden einzelnen Fakt explizit benennen muss. Das Verhalten unterscheidet sich je nach Backend – Hindsight beispielsweise gruppiert Turns und führt eine strukturierte Speicherung mit Entitäten und Beziehungen durch; Honcho schickt den Dialog durch seine dialektische Pipeline; Mem0- und Supermemory-ähnliche Stacks extrahieren Fakten passiv aus den Turns.

3. Providerspezifische Tools. Wenn das Plugin sie bereitstellt, ermöglichen explizite Schreibvorgänge wie honcho_conclude, hindsight_retain oder honcho_profile das Speichern dauerhafter Datensätze auf Abruf.

Automatischer Abruf versus Provider-Tools

Das Kern-Gedächtnis benötigt kein Read-Tool – es befindet sich bereits im Prompt. Externe Backends bieten entweder eine automatische Injektion durch Prefetch (kein separater Tool-Aufruf für diesen Teil des Kontextes nötig) oder explizite Abruf-Tools (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect und andere), wenn das Modell eine präzisere Abfrage benötigt, als Prefetch allein leisten kann.

Abruf-Modi (Externe Provider)

Plugins unterstützen einen konfigurierbaren Abruf-Modus (typischerweise recall_mode neben memory.provider in der Konfiguration), der Token gegen Kontrolle eintauscht.

Wenn kein externer Provider eingestellt ist (memory.provider leer oder nicht gesetzt), gelten nur die integrierten Dateien und die Sitzungssuche – kein Prefetch/Sync durch ein Plugin.

Pfade auf der Festplatte und Budgets

Das integrierte Gedächtnis von Hermes Agent liegt in zwei Dateien.

• ~/.hermes/memories/MEMORY.md — Persönliche Notizen des Agenten (2.200 Zeichen, ~800 Token)
• ~/.hermes/memories/USER.md — Benutzerprofil (1.375 Zeichen, ~500 Token)

Das ist die gesamte persistente Gedächtnisfläche: zwei Dateien, insgesamt weniger als 3.600 Zeichen, weniger als 1.300 Token. Das wirkt bewusst klein, weil es so gewollt ist – und genau das ist die Designabsicht.

MEMORY.md: Die Notizen des Agenten

Hier speichert der Agent alles, was er über seine Umgebung, das Projekt, Werkzeuge, Konventionen und gelernte Lektionen erfährt. So sieht es aus:

User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL
This machine runs Ubuntu 22.04, has Docker and kubectl installed
User prefers snake_case for variable names and avoids camelCase

Dies sind keine Logs. Es sind Fakten. Kompakt, deklarativ, informationsdicht. Keine Zeitstempel, kein unnötiger Ballast, kein „Am 5. Januar hat der Benutzer mich gebeten zu…“.

USER.md: Das Benutzerprofil

Hier speichert der Agent alles, was er über Sie weiß.

User is a full-stack developer comfortable with TypeScript, Go, and Python.
User prefers snake_case for variable names and avoids camelCase.
User primarily uses Linux Ubuntu 22.04.
User deploys to AWS using Terraform.

Identität, Rolle, Vorlieben, technische Fähigkeiten, Kommunikationsstil, persönliche Abneigungen. Dinge, die dazu führen, dass der Agent Ihnen anders antwortet als jeder anderen Person.

Das Muster des „Frozen Snapshot“

Zu Beginn einer Sitzung werden beide Dateien von der Festplatte geladen und als fester Block in den System-Prompt injiziert. So sieht das aus:

══════════════════════════════════════════════
MEMORY (your personal notes) [7% — 166/2,200 chars]
══════════════════════════════════════════════
User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL
§
This machine runs Ubuntu 22.04, has Docker and kubectl installed
§
User prefers snake_case for variable names and avoids camelCase
§

══════════════════════════════════════════════
USER PROFILE (who the user is) [8% — 110/1,375 chars]
══════════════════════════════════════════════
User is a full-stack developer comfortable with TypeScript, Go, and Python.
§
User prefers snake_case for variable names and avoids camelCase.
§

Das Format nutzt Header, Nutzungsstatistiken, Zeichenzählungen und § (Paragraphenzeichen) als Trenner. Einträge können mehrzeilig sein. Es ist so konzipiert, dass es vom Modell parst werden kann, während es für Menschen lesbar bleibt.

Warum „frozen“ (eingefroren)? Prefix Caching. Der System-Prompt bleibt über jeden Turn einer Sitzung hinweg gleich. Indem das Gedächtnis nach Sitzungsbeginn statisch gehalten wird, kann das Modell die Präfix-Berechnung zwischenspeichern (cachen) und nur die variablen Teile – die Konversation – verarbeiten. Dies ist eine erhebliche Leistungsoptimierung. Man berechnet nicht bei jedem Turn die Attention über dieselben Gedächtnis-Token neu.

Änderungen, die während einer Sitzung vorgenommen werden, werden sofort auf die Festplatte geschrieben, erscheinen aber erst beim nächsten Sitzungsstart im System-Prompt. Tool-Antworten zeigen immer den aktuellen Live-Zustand, aber der „Geist“ des Modells ändert sich nicht mitten in der Sitzung. Dies verhindert, dass das Modell im Kreis läuft – also das Gedächtnis aktualisiert und dann in derselben Konversation auf die eigene Aktualisierung reagiert.

Zeichenlimits als Feature

2.200 Zeichen. 1.375 Zeichen. Dies sind keine willkürlichen Limits. Es sind Design-Einschränkungen, die zur Kuratierung zwingen.

Unbegrenztes Gedächtnis ist ein Risiko. Es verleitet dazu, alles hineinzuwerfen, niemals zu konsolidieren und schließlich zu Rauschen zu werden. Begrenztes Gedächtnis zwingt den Agenten zur Selektivität. Was ist wirklich wichtig? Was werde ich wieder brauchen? Was kann komprimiert werden, ohne an Bedeutung zu verlieren?

Wenn das Gedächtnis voll ist, scheitert der Agent nicht einfach stillschweigend. Er erhält eine Fehlermeldung mit den aktuellen Einträgen und der Auslastung und folgt dann einem Workflow:

1. Aktuelle Einträge aus der Fehlermeldung lesen
2. Entwürfe identifizieren, die entfernt oder konsolidiert werden können
3. replace verwenden, um zusammengehörige Einträge in kürzere Versionen zu mergen
4. Den neuen Eintrag hinzufügen

So bleibt das Gedächtnis nützlich. Es ist keine Datenbank. Es ist eine kuratierte Sammlung wichtiger Fakten.

Sicherheit: Prompt-Injection-Scanning

Jeder Gedächtniseintrag wird vor der Annahme gescannt. Das System blockiert Prompt-Injection-Versuche, das Exfiltrieren von Anmeldedaten, SSH-Backdoors und unsichtbare Unicode-Zeichen.

Zudem wird das Gedächtnis dedupliziert. Identische Einträge werden automatisch abgelehnt. Dies verhindert, dass Angreifer versuchen, durch wiederholte Eingaben bösartige Inhalte einzuschleusen.

Externe Gedächtnis-Provider (Aktivierung und Links)

Zusätzlich zu den integrierten Dateien MEMORY.md und USER.md kann Hermes Agent zu jeder Zeit einen externen Gedächtnis-Plugin anbinden – Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover oder Supermemory – für persistentes, sitzungsübergreifendes Wissen. Es ist immer nur ein externer Provider aktiv; die beiden Kern-Dateien bleiben parallel dazu geladen (additiv, nicht ersetzend).

Aktivieren und inspizieren Sie Provider mit hermes memory setup, hermes memory status und hermes memory off, oder setzen Sie memory.provider und recall_mode in der ~/.hermes/config.yaml. Die Muster für Anmeldedaten variieren (z. B. HINDSIGHT_API_KEY, Honcho-Keys unter $HERMES_HOME/honcho.json); verwenden Sie hermes memory setup für die interaktive Einrichtung.

Minimaler YAML-Aufbau (nur integriert):

memory:
  provider: ""
  memory_enabled: true
  user_profile_enabled: true

Beispiel für die Aktivierung eines Backends (ersetzen Sie hindsight durch honcho, mem0, supermemory oder andere, die Ihre Installation unterstützt):

memory:
  provider: "hindsight"

Für die vollständige Vergleichstabelle, Hinweise zur Abhängigkeit von LLMs und Embeddings, detaillierte Aufschlüsselungen pro Provider und wie diese Backends mit OpenClaw und anderen Stacks zusammenhängen, siehe Agent memory providers verglichen.

Für die profilspezifische Einrichtung und Produktions-Workflows siehe Hermes Agent Production-Setup. Der AI Systems Memory Hub listet diesen Leitfaden sowie verwandte Artikel zu Cognee und der Wissensebene auf.

Teil 3: Wenn das Gedächtnis feuert – Trigger & Entscheidungen

Die häufigste Frage zum Gedächtnis von Hermes Agent ist, wann er tatsächlich etwas speichert.

Die Antwort lautet: ständig, aber selektiv. Der Agent verwaltet sein Gedächtnis über das memory-Tool, und die Entscheidung zum Speichern wird durch eine Kombination aus expliziten Signalen und impliziten Mustern gesteuert.

Schreib-Trigger: Wann entscheidet sich der Agent zum Speichern?

Der Agent speichert das Gedächtnis proaktiv. Er wartet nicht darauf, dass Sie ihn darum bitten. Folgendes löst dies aus:

Benutzerkorrekturen. Wenn Sie den Agenten korrigieren, ist das ein Signal, sich das zu merken. „Mach das nicht noch einmal.“ „Nutze stattdessen dies.“ „Merk dir das.“ Dies sind explizite Anweisungen, das Gedächtnis zu aktualisieren.

Beispiel: Sie bitten den Agenten, eine Python-Umgebung zu konfigurieren. Er schlägt pip vor. Sie sagen: „Ich nutze für alles poetry.“ Der Agent speichert: User prefers using the 'poetry' package manager for all Python projects.

Entdeckte Vorlieben. Der Agent beobachtet Muster und schließt auf Vorlieben. Wenn Sie konsistent ein bestimmtes Werkzeug, Framework oder einen Workflow verwenden, wird dies gespeichert.

Beispiel: Nachdem er gesehen hat, dass Sie poetry mehrfach in verschiedenen Projekten verwenden, speichert er dies als Vorliebe.

Umgebungsfakten. Dinge über die Maschine, das Projekt, die installierten Werkzeuge. Diese werden durch Exploration entdeckt und als Fakten gespeichert.

Beispiel: Der Agent prüft, was installiert ist, und speichert: This machine runs Ubuntu 22.04, has Docker and kubectl installed.

Projektkonventionen. Wie das Projekt strukturiert ist, welche Werkzeuge es nutzt, welchen Mustern es folgt. Diese werden durch Code-Inspektion entdeckt und gespeichert.

Beispiel: User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL.

Abgeschlossene komplexe Workflows. Nach Abschluss einer Aufgabe, die mehr als 5 Tool-Aufrufe erforderte, erwägt der Agent, den Ansatz als Fähigkeit zu speichern oder zumindest zu notieren, was funktioniert hat.

Tool-Eigenheiten und Workarounds. Wenn der Agent etwas Unkonventionelles über ein Werkzeug, eine API oder ein System entdeckt – eine Einschränkung, ein Workaround, eine Konvention – speichert er es.

Was übersprungen wird:

• Triviale oder offensichtliche Informationen
• Dinge, die leicht wieder entdeckt werden können
• Rohe Datendumps
• Sitzungsspezifische Flüchtigkeiten
• Informationen, die bereits in den Kontext-Dateien stehen (SOUL.md, AGENTS.md)

Lese-Trigger: Wann ruft der Agent Informationen ab?

Gedächtnis wird nicht „abgerufen“ – es ist immer da. Aber es gibt verschiedene Zugriffsebenen.

Sitzungsbeginn (automatisch). MEMORY.md und USER.md werden in den System-Prompt injiziert. Der Agent hat sie ab dem ersten Token. Keine Abfrage nötig, keine Latenz, kein Tool-Aufruf. Dies ist das Kern-Gedächtnis – immer aktiv.

session_search (on-demand). Wenn der Agent etwas aus vergangenen Gesprächen finden muss, das nicht im Kern-Gedächtnis enthalten ist, nutzt er das session_search-Tool. Dies durchsucht SQLite (~/.hermes/state.db) mit FTS5-Volltextsuche und Gemini Flash-Zusammenfassung. Nutzen Sie dies, wenn die Frage eher nach „Wir haben schon mal darüber gesprochen“ klingt als nach „Merk dir diesen Fakt für immer“.

Beispiel: Sie fragen „Haben wir letzte Woche über Docker-Networking gesprochen?“. Der Agent durchsucht die Sitzungshistorie und liefert eine Zusammenfassung des relevanten Gesprächs.

Externe Provider-Tools (wenn konfiguriert). Wenn ein externer Gedächtnis-Provider aktiv ist, führt das Framework vor jeder Antwort zudem einen automatischen Prefetch-Schritt aus (siehe Teil 2). Zusätzliche Tools wie honcho_search, hindsight_recall oder mem0_search dienen gezielten Abfragen, wenn der Agent eine explizite Suche wählt – je nach recall_mode können automatische Injektion, Tools oder beides aktiv sein.

Der Entscheidungsbaum

So wägt der Agent ab: „Ist das es wert, sich gemerkt zu werden?“:

Is this a correction or explicit instruction?
  YES → Save to memory
  NO → Is this a preference or pattern?
    YES → Save to user profile
    NO → Is this an environment fact or convention?
      YES → Save to memory
      NO → Is this easily re-discovered?
        YES → Skip
        NO → Is this session-specific?
          YES → Skip
          NO → Save to memory

Der Agent denkt nicht zu viel darüber nach. Er speichert proaktiv, konsolidiert, wenn das Gedächtnis voll ist, und vertraut darauf, dass die Zeichenlimits die Dinge kompakt halten.

Teil 4: Internes Gedächtnis vs. Externe Wissensdatenbanken

Hier entstehen oft Missverständnisse. Hermes Agent hat internes Gedächtnis (MEMORY.md, USER.md, externe Provider) und externe Wissensdatenbanken (LLM Wiki, Obsidian, Notion, ArXiv, Dateisystem), die völlig unterschiedliche Rollen erfüllen. Dies ähnelt dem Unterschied zwischen Retrieval-Augmented Generation Pipelines und dem Arbeitsgedächtnis eines Agenten – externe Abfragen sind gut für tiefes Wissensnachschlagen, aber nicht dafür, Identität und Vorlieben mitzuführen. Internes Gedächtnis ist das Gehirn des Agenten – immer aktiv, kuratiert, in jede Sitzung mitgenommen. Externe Wissensdatenbanken sind seine Bibliothek – riesige Referenzressourcen, die bei Bedarf konsultiert werden.

Die Unterscheidung

Internes Gedächtnis (das Gehirn):

• Klein, persistent, in den System-Prompt injiziert
• Enthält: Benutzerpräferenzen, Agentenkonventionen, unmittelbare Lektionen
• Während des Gesprächs immer „im Kopf“
• Kuratiert, begrenzt, aktiv verwaltet
• Beispiele: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

Externe Wissensdatenbanken (die Bibliothek):

• Riesig, nur als Referenz, bei Bedarf abgerufen
• Enthält: Dokumente, Paper, Code, Notizen, Datenbanken
• Über Tools zugänglich, wenn nötig
• Wird nicht „gelernt“ – sondern nachgeschlagen
• Beispiele: LLM Wiki, Obsidian, Notion, ArXiv, Dateisystem, GitHub

Wie sie zusammenhängen

Der Agent greift über Tools auf externe Datenbanken zu, wenn nötig. Er „merkt“ sie sich nicht – er schlägt sie nach.

LLM Wiki (llm-wiki): Karpathys miteinander verknüpfte Markdown-Wissensbasis zum Aufbau und Abfragen von Domänenwissen. Der Agent nutzt das llm-wiki-Skill, um darin zu lesen, zu suchen und Anfragen zu stellen. Es ist eine Referenzressource, kein Gedächtnis.

Obsidian: Persönliche Notiz-Tresore mit bidirektionalen Links. Der Agent nutzt das obsidian-Skill, um Notizen zu lesen, zu suchen und zu erstellen. Obsidian ist Teil des breiteren Personal Knowledge Management-Ökosystems, auf das Hermes als Bibliotheksressource zugreifen kann.

Notion/Airtable: Strukturierte Datenbanken und Wikis, die über APIs abgerufen werden. Der Agent fragt sie bei Bedarf ab.

ArXiv: Repositories für wissenschaftliche Arbeiten. Der Agent durchsucht und extrahiert Paper, wenn er zu einem Thema recherchiert.

Dateisystem: Projektcode, Dokumentation, Konfigurationen. Der Agent liest Dateien, während er an einem Projekt arbeitet.

Das Destillations-Muster

Hier liegt die entscheidende Erkenntnis: Kritische Erkenntnisse aus externen Quellen können in das interne Gedächtnis destilliert werden.

Beispiel: Der Agent liest ein Paper von ArXiv über Memory Scaling für KI-Agenten. Er speichert nicht das gesamte Paper im Gedächtnis. Er speichert die wichtigste Erkenntnis: Memory scaling: agent performance improves with accumulated experience through user interaction and business context stored in memory.

Die externe Ressource ist riesig. Das interne Gedächtnis ist die Destillation.

Wann man was benutzt

Internes Gedächtnis für:

• „Wem helfe ich gerade?“
• „Was bevorzugt diese Person?“
• „Was haben wir gerade gelernt?“
• „Wie sieht das Projekt-Setup aus?“
• „Welche Werkzeuge stehen zur Verfügung?“

Externe Wissensdatenbanken für:

• „Was ist der neueste Forschungsstand zu X?“
• „Was steht in der Projektdokumentation?“
• „Worüber haben wir letzten Monat gesprochen?“
• „Wie sieht die API für diesen Dienst aus?“
• „Wie ist die Codestruktur?“

Der Agent versteht den Unterschied und nutzt beides angemessen – er verwechselt das Nachschlagen eines Dokuments nicht mit dem Erinnern an etwas, das er über Sie und Ihre Umgebung gelernt hat.

Teil 5: Wie es tatsächlich funktioniert

Schauen wir uns die Mechanik an.

Das memory Tool

Der Agent verwaltet das Gedächtnis über ein einziges Tool mit drei Aktionen: add, replace, remove.

Es gibt keine read-Aktion – der Gedächtnisinhalt wird automatisch in den System-Prompt injiziert. Der Agent muss ihn nicht lesen, weil er immer da ist.

add — Fügt einen neuen Eintrag hinzu.

memory(action="add", target="memory",
       content="User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed.")

replace — Ersetzt einen bestehenden Eintrag mittels Substring-Abgleich.

memory(action="replace", target="memory",
       old_text="dark mode",
       content="User prefers light mode in VS Code, dark mode in terminal")

remove — Entfernt einen Eintrag mittels Substring-Abgleich.

memory(action="remove", target="memory",
       old_text="temporary project fact")

Substring-Abgleich

replace und remove verwenden kurze, eindeutige Teilstrings über old_text. Sie müssen nicht den gesamten Text des Eintrags angeben. Dies ermöglicht präzise Bearbeitungen, ohne den exakten Inhalt kennen zu müssen.

Falls ein Teilstring mit mehreren Einträgen übereinstimmt, wird eine Fehlermeldung zurückgegeben, die um eine präzisere Angabe bittet. Der Agent verfeinert dann seine Abfrage.

Ziel-Speicher: memory vs. user

Der Parameter target bestimmt, welche Datei aktualisiert wird.

• memory — Persönliche Notizen des Agenten. Umgebungsfakten, Projektkonventionen, Tool-Eigenheiten, gelernte Lektionen.
• user — Benutzerprofil. Identität, Rolle, Zeitzone, Kommunikationspräferenzen, persönliche Abneigungen, Workflow-Gewohnheiten.

Kapazitätsmanagement

Wenn das Gedächtnis zu mehr als 80 % gefüllt ist, konsolidiert der Agent. Er führt zusammengehörige Einträge zusammen, entfernt veraltete Fakten und komprimiert Informationen.

Gute Gedächtniseinträge sind kompakt und informationsdicht:

User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed. Shell: zsh with oh-my-zsh. Editor: Neovim with Telescope plugin.

Schlechte Gedächtniseinträge sind vage oder zu wortreich:

User has a project.
On January 5th, 2026, the user asked me to look at their project which is located at ~/code/gateway and it uses Go with gRPC and PostgreSQL for the database layer.

Der erste ist dicht und nützlich. Der zweite ist entweder zu vage oder zu ausschweifend.

Sitzungssuche vs. Persistentes Gedächtnis

session_search und persistentes Gedächtnis erfüllen unterschiedliche Zwecke.

Faustregel: Nutzen Sie das Gedächtnis für kritische Fakten, die immer im Kontext sein sollten. Nutzen Sie die Sitzungssuche für historische Abfragen.

Teil 6: Die Philosophie

Warum begrenztes Gedächtnis besser ist als unbegrenztes Gedächtnis

Der Instinkt ist, das Gedächtnis so groß wie möglich zu machen. Speichere alles. Rufe ab, was du brauchst.

Begrenztes Gedächtnis funktioniert besser. Hier ist der Grund:

Kuratierung erzwingt Qualität. Wenn man begrenzten Platz hat, speichert man nur das, was wichtig ist. Man komprimiert, konsolidiert und priorisiert. Unbegrenztes Gedächtnis verleitet dazu, einfach alles hineinzuwerfen und niemals aufzuräumen.

Geschwindigkeit zählt. 1.300 Token im System-Prompt sind schnell. 100.000 Token, die aus einer Datenbank abgerufen werden, sind langsam. Gedächtnis sollte unmittelbar verfügbar sein, nicht das Ergebnis einer Abfrage.

Rauschen verschlechtert die Leistung. Mehr Gedächtnis bedeutet nicht besseres Gedächtnis. Es bedeutet verrauschtes Gedächtnis. Das Modell muss Signal von Rauschen unterscheiden, und das erfordert Aufmerksamkeit – Aufmerksamkeit, die eigentlich für die eigentliche Aufgabe verwendet werden sollte.

Vergessen ist ein Feature. Das menschliche Gedächtnis vergisst. Das ist kein Fehler – so priorisieren wir. Agenten sollten das auch tun. Nicht alles verdient es, erinnert zu werden.

Das „Vergessen“-Problem

Agenten müssen verlernen können. Nicht nur vergessen, sondern aktiv veraltete Informationen entfernen.

So handhabt Hermes Agent dies:

• remove-Aktion: Einträge löschen, die nicht mehr relevant sind.
• replace-Aktion: Einträge mit neuen Informationen aktualisieren.
• Kapazitätsdruck: Wenn das Gedächtnis voll ist, konsolidiert der Agent und entfernt alte Einträge.
• Sicherheits-Scanning: Blockiert bösartige oder korrumpierte Einträge.

Vergessen ist kein Scheitern – es ist Wartung. Ein Agent, der nicht verlernen kann, wird irgendwann genauso viel Rauschen wie Signal mit sich herumtragen.

Memory Scaling

Databricks führte das Konzept des „Memory Scaling“ ein: Schneidet ein Agent mit tausenden Nutzern besser ab als einer mit nur einem Nutzer?

Ihre Forschung deutet darauf hin, dass dies der Fall ist, aber unter Vorbehalt. Memory Scaling erfordert:

1. Qualitative Extraktion: Nicht jede Interaktion ist es wert, sich zu merken. Der Agent muss Erkenntnisse extrahieren, keine Logs.
2. Effektiver Abruf: Abgerufene Erinnerungen müssen relevant sein. Rauschen mindert die Leistung.
3. Generalisierung: Erinnerungen sollten Muster sein, keine Details. „Benutzer bevorzugt Python“ skaliert. „Benutzer führte Befehl X zum Zeitpunkt Y aus“ skaliert nicht.

Das begrenzte Gedächtnis von Hermes Agent unterstützt Memory Scaling auf natürliche Weise. Durch den Zwang zur Kuratierung wird sichergestellt, dass Erinnerungen verallgemeinerbar, kompakt und nützlich sind.

Was das für die Zukunft bedeutet

Gedächtnis wird zum entscheidenden Wettbewerbsvorteil in der agentischen KI – nicht das Modell selbst, sondern das, was das Modell zwischen den Sitzungen mitnimmt. Zwei Agenten mit identischen zugrunde liegenden Modellen können sich sehr unterschiedlich verhalten: Der eine erinnert sich an Ihre Vorlieben, Ihre Umgebung und Ihre vergangenen Fehler; der andere fängt jedes Mal bei Null an.

Die Frage ist nicht mehr, ob Agenten über ein persistentes Gedächtnis verfügen sollten. Das ist entschieden: Sie müssen es. Die offene Frage ist, wie man dieses Gedächtnis gut gestaltet – was man behält, was man verwirft, wie man es unmittelbar verfügbar macht und wie man verhindert, dass es zu Rauschen wird.

Die Antwort von Hermes Agent ist, das Gedächtnis klein, kuratiert und immer aktiv zu halten – nicht als eine Datenbank, die man abfragt, sondern als ein Arbeitsmodell des Benutzers, das der Agent in jedes Gespräch mitnimmt.

Fazit

Das Gedächtnissystem von Hermes Agent ist bewusst einfach gehalten: zwei Dateien, feste Zeichenlimits, keine Retrieval-Pipeline, keine Vektordatenbank und keine Latenz pro Abfrage. Was wie eine Einschränkung klingt, ist genau der Punkt.

Es funktioniert, weil es Gedächtnis so behandelt, wie ein Gehirn arbeitet, und nicht wie eine Datenbank – klein, kuratiert und immer aktiv. Der Agent ruft das Gedächtnis nicht bei Bedarf ab; das Gedächtnis ist einfach immer da, eingewebt in den System-Prompt ab dem ersten Token jeder Sitzung.

Externe Gedächtnis-Provider erweitern dieses System für Nutzer, die mehr benötigen: Knowledge-Graphen, Multi-Agenten-Unterstützung, selbstgehosteten Speicher oder Enterprise-Funktionen. Aber der Kern bleibt gleich: begrenzt, kuratiert, immer verfügbar.

Und externe Wissensdatenbanken – LLM Wiki, Obsidian, Notion, ArXiv – erfüllen eine andere Rolle. Sie sind die Bibliothek, nicht das Gehirn. Der Agent schlägt sie nach, er erinnert sich nicht an sie. Kritische Erkenntnisse werden in das interne Gedächtnis destilliert; der Rest bleibt in der Bibliothek.

So erinnert sich ein KI-Agent an Sie. Nicht indem er alles speichert, sondern indem er sich das merkt, was wichtig ist.

Hermes Agent wurde im Februar 2026 von Nous Research veröffentlicht und erreichte bis April 2026 über 64.000 GitHub-Stars (v0.9.0) mit über 242 Mitwirkenden. Er ist Open-Source und unter github.com/NousResearch/hermes-agent verfügbar. Installations-, Konfigurations- und Workflow-Anleitungen finden Sie in der Hermes Agent Übersicht.