Aufbau eines lokalen KI-Memory-Repositories

Ammar Najjar · Veröffentlicht am 17. Oktober 2026 · 10 Min. Lesezeitaiproductivity

KI-generiertes Bild

In Wenn die KI-Erinnerung nicht zwischen Tools mitwandert habe ich beschrieben, wie ich Obsidian genutzt habe, um Wissen zwischen ChatGPT, Claude Code und lokalen KI-Modellen auszutauschen. Dieser Ansatz funktionierte, allerdings musste ich weiterhin selbst dafür sorgen, dass relevante Informationen abgerufen und neue Erkenntnisse festgehalten wurden.

Ich wollte diesen Aufwand reduzieren und gleichzeitig die Kontrolle darüber behalten, welche Informationen ich speichere und weitergebe. Deshalb begann ich mit einem separaten Markdown-Repository, das Agenten mit Dateisystemzugriff als gemeinsame Quelle für dauerhaft verfügbaren Kontext nutzen konnten. Tools ohne direkten Zugriff auf das Repository benötigten weiterhin einen eigenen Weg, um die für eine Unterhaltung relevanten Informationen zu erhalten.

Warum ich mich für ein lokales Repository entschieden habe

Meine wichtigsten Anforderungen waren der direkte Zugriff auf gespeicherte Informationen und die Kontrolle darüber, wie sie weitergegeben werden. Wenn das Repository auf meinem eigenen Rechner liegt, kann ich seine Inhalte jederzeit einsehen, bearbeiten und Änderungen mit Git versionieren. Verwendet ein Agent allerdings ein gehostetes Modell, werden die übermittelten Informationen außerhalb meines Rechners verarbeitet. Deshalb muss ich weiterhin entscheiden, welche Inhalte ich der jeweiligen Umgebung zur Verfügung stelle.

Ich entschied mich für Markdown, weil ich dieses Format bereits intensiv in Obsidian und bei meiner Entwicklungsarbeit nutze. Auch KI-Agenten können gut mit einfachen, menschenlesbaren Dateien arbeiten. Für den anfänglichen Umfang meines Systems benötigte ich damit weder zusätzliche Werkzeuge noch neue Konventionen.

Entscheidend war für mich, dass die gespeicherten Informationen an einem zentralen lokalen Ort liegen und unabhängig von einem bestimmten KI-Tool bleiben. Das Dateiformat ist dabei austauschbar. Jede Umgebung benötigt weiterhin eine Möglichkeit, auf das Repository zuzugreifen und relevante Informationen zu laden. Die gespeicherten Inhalte bleiben jedoch dieselben, unabhängig davon, welches Tool sie verwendet.

Zwei unterschiedliche Aufgaben: Obsidian und KI-Memory

Ich hatte bereits ein Wissensmanagementsystem in Obsidian aufgebaut, das ich in Wissen langfristig nutzbar halten beschrieben habe. Deshalb stellte sich zunächst die Frage, warum ich Informationen an zwei verschiedenen Orten verwalten sollte.

Die Antwort ergab sich aus der unterschiedlichen Verwendung der beiden Systeme.

Mein Obsidian-Vault enthält ausführliche Originalaufzeichnungen, darunter Besprechungsnotizen, technische Entscheidungen, Lesenotizen und Beobachtungen aus meinem Berufsalltag. Diese Dokumente bewahren den ursprünglichen Zusammenhang und die Details, auf die ich später möglicherweise zurückgreifen möchte.

Das Memory-Repository habe ich dagegen als kleinere, stärker zusammengefasste Wissensschicht angelegt, die meine KI-Tools über mehrere Unterhaltungen hinweg verwenden können. Darin befinden sich relativ beständige Hintergrundinformationen, Arbeitspräferenzen, wiederkehrende Beobachtungen und Zusammenhänge, die für zukünftige Gespräche relevant sein könnten.

Vertrauliche Originalinformationen übernehme ich nicht in das Memory-Repository. Wenn eine Aufgabe bestimmte Details aus einer Obsidian-Notiz benötigt, stelle ich diese gezielt über den passenden Arbeitsablauf zur Verfügung.

Diese Trennung ist auch für den Datenschutz relevant. Lokal gespeicherte Markdown-Dateien geben mir Kontrolle über die Speicherung, bestimmen aber nicht, wo ihre Inhalte verarbeitet werden. Ein lokales Modell verarbeitet Informationen auf meinem Rechner, während ein gehostetes Modell den Kontext erhält, den der Agent an dieses Modell übermittelt. Diese Unterscheidung beeinflusst, welche Informationen ich in welcher Umgebung verwenden möchte.

Beständige und veränderliche Informationen organisieren

Ich habe das Repository in zwei Verzeichnisse aufgeteilt, um relativ beständige Informationen von Beobachtungen zu unterscheiden, die sich im Laufe der Arbeit weiterentwickeln.

Im Verzeichnis context/ speichere ich Informationen, die sich nur selten ändern, beispielsweise meinen Hintergrund, Schreibpräferenzen und Arbeitsprinzipien. Sie sollen über mehrere Unterhaltungen hinweg einen konsistenten Kontext bieten. Änderungen daran überprüfe ich bewusst.

Im Verzeichnis memory/ halte ich Informationen fest, die während der laufenden Arbeit entstehen und sich verändern können. Dazu gehören Beobachtungen, wiederkehrende Muster, offene Fragen und Einträge, die inzwischen durch neuere Informationen ersetzt wurden.

Vereinfacht sieht die Struktur so aus:

my-ai-memory/
├── AGENTS.md
├── context/
│   ├── profile.md
│   └── principles.md
└── memory/
    ├── inbox.md
    ├── patterns.md
    └── superseded.md

Die Verzeichnisstruktur beschreibt, wie Informationen verwendet und gepflegt werden sollen. Wie zuverlässig ein Agent eine bestimmte Information einschätzen kann, hängt dagegen vom Status des jeweiligen Eintrags ab. Ein Eintrag in context/ ist nicht automatisch bestätigt, und eine neue Beobachtung in memory/ ist nicht zwangsläufig unzuverlässig. Die Anweisungen für den Umgang mit diesen Informationen liegen separat in AGENTS.md.

Ein Beispiel für eine Kontextdatei, die meine Arbeitsumgebung und bestimmte Vorgaben beschreibt:

# Working environment

- Prefer local tools that run on my hardware.
- Use version control for all tracked changes.
- Document configuration decisions alongside their reasoning.

Wenn ein Agent diese Datei lädt, kann er die darin enthaltenen Präferenzen berücksichtigen, ohne dass ich sie erneut erklären muss.

Die veränderliche Wissensschicht erfüllt eine andere Aufgabe. Ein Eintrag im Posteingang hält beispielsweise eine Beobachtung fest, bevor abschließend geklärt wurde, wie sie einzuordnen ist:

# Inbox

## Pattern: Debug logs expose infrastructure state
- **Confidence:** Low (single observation)
- **Source:** 2026-08-12 deployment discussion
- **Status:** Needs review

Observation: Container debug logs included internal IP addresses and service topology, revealing infrastructure details that should not appear in standard output.

Dieser Eintrag enthält eine Einschätzung der Verlässlichkeit, einen Quellenverweis und einen ausdrücklich angegebenen Status. Durch die Trennung von bereits etabliertem Kontext kann ich die Beobachtung später erneut prüfen, ohne eine erste Interpretation sofort als bestätigte Erkenntnis zu behandeln.

Auch ersetzte Informationen bleiben mit ausreichend Kontext dokumentiert. So kann ich ältere Verweise weiterhin nachvollziehen und gleichzeitig erkennen, welche Angaben aktuell sind. Bei wiederkehrenden Mustern halte ich die zugrunde liegenden Beobachtungen und die verbleibende Unsicherheit fest.

Vorgesehener Ablauf: Von der Unterhaltung ins Repository

In AGENTS.md habe ich den folgenden Ablauf beschrieben. Er zeigt, wie sich die Agenten meiner Vorstellung nach verhalten sollten, wenn aus einer Unterhaltung nützliche Informationen hervorgehen.

Unterhaltung endet
    │
    ▼
Agent prüft die Unterhaltung auf relevante Informationen
    │
    ▼
Entscheidung: Beobachtung speichern?
    │
    ├── Nein → kein Eintrag
    └── Ja   → in memory/inbox.md speichern
                   │
                   ▼
             Verlässlichkeit, Quelle und Status erfassen
                   │
                   ▼
             (Optional) Änderung in context/
             zur Überprüfung vorschlagen

Die Anweisungen umfassen das Erfassen neuer Informationen, ihre Bewertung und das Vorschlagen von Änderungen an beständigem Kontext. Das Repository enthält die Aufzeichnungen, während die Anweisungen den vorgesehenen Ablauf beschreiben. Ob die einzelnen Schritte tatsächlich ausgeführt wurden, hing weiterhin davon ab, ob der Agent während seiner eigentlichen Aufgabe die entsprechenden Anweisungen befolgte.

Umgang mit widersprüchlichen Informationen

Mit wachsendem Repository können verschiedene Einträge dasselbe Thema zu unterschiedlichen Zeitpunkten beschreiben. Eine Präferenz kann sich ändern, eine frühere Beobachtung kann sich als unvollständig erweisen oder eine Entscheidung kann durch eine neue ersetzt werden.

Meine ursprünglichen Anweisungen enthielten deshalb eine Prioritätenfolge: Zuerst galten ausdrückliche Anweisungen, danach aktuelle Erkenntnisse, anschließend der dokumentierte Ist-Zustand und zuletzt ältere Notizen.

Diese Reihenfolge bot einen einfachen Ausgangspunkt. Mit der Zeit begann ich allerdings zu hinterfragen, wie gut sie unterschiedliche Verlässlichkeitsgrade berücksichtigt. Eine neue Beobachtung kann noch vorläufig sein, während ein älterer Eintrag eine bestätigte Entscheidung dokumentiert. Deshalb müssen neben dem Alter einer Information auch ihre Quelle und ihre Verlässlichkeit berücksichtigt werden.

Ich habe die ursprüngliche Prioritätenfolge zunächst unverändert gelassen. Offen blieb, wie gut sich Aktualität, Verlässlichkeit und Autorität miteinander vereinbaren lassen, wenn sie zu unterschiedlichen Ergebnissen führen. Das Repository kann diese Unterschiede dokumentieren, aber es kann nicht erzwingen, wie ein Agent damit umgeht. Das hängt weiterhin davon ab, welche Anweisungen er tatsächlich befolgt.

KI-Agenten mit dem Repository verbinden

Das Repository besteht aus einfachen Textdateien, die in unterschiedlichen Umgebungen verwendet werden können. Ein Modell erhält dadurch allerdings nicht automatisch Zugriff auf die Dateien. Dafür benötigt es einen Agenten mit Dateisystemzugriff oder eine andere Integration, die relevante Inhalte lesen und dem Modell bereitstellen kann.

In meinem lokalen KI-Workflow konnten Coding-Agenten über gewöhnliche Dateisystemoperationen direkt auf das Memory-Repository zugreifen. Claude Code verwendete denselben Weg.

Bei ChatGPT sah das anders aus. Da ich keinen direkten Zugriff auf das lokale Repository voraussetzen konnte, stellte ich die benötigten Informationen weiterhin manuell bereit. Je nach Unterhaltung wählte ich relevante Inhalte aus den Markdown-Dateien aus und fügte sie in den Chat ein.

Jede Umgebung benötigt daher einen eigenen Mechanismus, um auf die Dateien zuzugreifen und gemeinsame Anweisungen zu laden. Das Repository dient als zentrale Informationsquelle. Wie ein Tool diese Informationen erhält, hängt von seinen Möglichkeiten und seiner Konfiguration ab.

Memory-Anweisungen über AGENTS.md

Die gemeinsamen Anweisungen befinden sich in einer Datei namens AGENTS.md im Stammverzeichnis des Repositories.

Verschiedene Agenten verwenden unterschiedliche Konventionen für Projektanweisungen. Manche erkennen AGENTS.md direkt, andere benötigen eine eigene Konfiguration oder eine ausdrückliche Aufforderung, die Datei zu laden. Deshalb verwende ich sie als zentralen Ort für meine Memory-Anweisungen, ohne davon auszunehmen, dass jeder Agent sie automatisch berücksichtigt.

Die Anweisungen beschreiben, wie Agenten Informationen lesen und aktualisieren sollen. Bevor ein Agent an einem Thema arbeitet, soll er den relevanten Kontext prüfen und bestehende Einträge berücksichtigen, um unnötige Duplikate zu vermeiden. Wenn er eine Beobachtung festhält, soll er die verbleibende Unsicherheit und ausreichend Quelleninformationen dokumentieren, damit die Herkunft später nachvollziehbar bleibt.

Beständige Informationen sollen sorgfältiger behandelt werden als veränderliche Einträge. Neue Beobachtungen werden im veränderlichen Speicher abgelegt, während vorgeschlagene Änderungen an etabliertem Kontext zur Überprüfung gekennzeichnet werden. Dabei handelt es sich um Verhaltensanweisungen, nicht um technisch erzwungene Berechtigungen. Ein Agent kann grundsätzlich jede Datei bearbeiten, für die er entsprechende Dateisystemrechte besitzt. Ob er die vorgesehene Trennung einhält, hängt davon ab, ob er die Anweisungen befolgt.

Dasselbe gilt für das Erfassen neuer Informationen. Wenn eine Unterhaltung zu einer nützlichen Erkenntnis führt, soll der Agent prüfen, was davon erhalten bleiben sollte, und die entsprechenden Einträge mit Angaben zu Verlässlichkeit und Quelle speichern.

Auf diese Weise konnte ich einen gemeinsamen Ablauf für verschiedene Agenten beschreiben, während das Repository selbst unabhängig von einem bestimmten Tool blieb.

Grenzen eines anweisungsbasierten Ansatzes

Das Repository löste mehrere Probleme, die ich zuvor mit der an einzelne KI-Tools gebundenen Erinnerung erlebt hatte. Ich konnte gespeicherte Informationen einsehen, Fehler korrigieren und Änderungen mit Git nachvollziehen. Das Wissen blieb unabhängig von einem bestimmten Agenten oder Modell verfügbar, sofern die jeweilige Umgebung mit dem Repository verbunden war. Auch die Trennung zwischen etabliertem Kontext und sich entwickelnden Beobachtungen wurde klarer.

Schwieriger blieb es, den Speicher aktuell zu halten und relevante Informationen zuverlässig wiederzufinden.

Dabei zeigten sich drei Probleme:

Unbemerkt ausgelassene Speicherung. Ein Agent schließt eine Aufgabe ab, ohne eine Beobachtung festzuhalten, die später nützlich gewesen wäre. Die Anweisungen sehen vor, Unterhaltungen auf relevante Erkenntnisse zu prüfen. Ob das geschieht, hängt jedoch davon ab, ob der Agent während der laufenden Aufgabe daran denkt und entsprechend handelt.

Ausbleibender Abruf. Eine relevante Information ist bereits im Repository vorhanden, wird aber beim Beginn einer verwandten Aufgabe nicht geladen. Alle Dateien in jeder Sitzung vollständig einzulesen, würde unnötig viel Kontext verbrauchen. Mit wachsender Sammlung wird die gezielte Auswahl deshalb immer wichtiger.

Fehlende Nachvollziehbarkeit ausgelassener Schritte. Beide Probleme lassen sich während einer Unterhaltung nur schwer erkennen. Eine Antwort kann hilfreich sein, obwohl keine neue Information gespeichert oder vorhandenes Wissen nicht berücksichtigt wurde. Solche Lücken fallen häufig erst auf, wenn ich die Dateien später überprüfe oder erneut auf ein Thema zurückkomme. Ein Protokoll darüber, welche Verarbeitungsschritte ausgelassen wurden, existiert nicht.

Verbesserungen an den Anweisungen halfen in manchen Situationen. Der grundlegende Ablauf blieb jedoch davon abhängig, dass der Agent die entsprechenden Schritte während seiner eigentlichen Aufgabe ausführte. Es gab keinen unabhängigen Mechanismus, um festzustellen, ob eine Unterhaltung auf nützliche Informationen geprüft wurde, eine ausgelassene Aktualisierung zu erkennen oder nicht verarbeitete Inhalte nachträglich aufzugreifen.

Diese Lücken brachten mich dazu, Teile der Memory-Pflege außerhalb des normalen Gesprächsablaufs zu betrachten. Ich wollte überprüfen können, ob relevante Informationen erfasst wurden, ausgelassene Verarbeitungsschritte sichtbar machen und Unterbrechungen nachträglich behandeln können.

Auch der Abruf benötigte mehr Aufmerksamkeit. Allerdings ist es schwieriger festzustellen, welche gespeicherten Informationen in einer bestimmten Sitzung hätten berücksichtigt werden sollen. Eine unabhängige Überprüfung oder ein Audit war deshalb einer der Ansätze, die ich zu untersuchen begann.

Wie es weitergeht

Die Markdown-Dateien gaben mir eine Grundlage für KI-Memory, die ich direkt einsehen, bearbeiten und zwischen verschiedenen Tools verwenden konnte. Der anweisungsbasierte Ansatz bewährte sich grundsätzlich im Alltag. Schwieriger blieb es, Informationen zuverlässig zu erfassen und abzurufen.

Deshalb beschäftige ich mich damit, diese Abläufe ausdrücklicher zu gestalten und besser überprüfbar zu machen, damit das Repository auch mit zunehmendem Umfang nützlich bleibt. Diese Arbeit ist noch nicht abgeschlossen. Im nächsten Artikel dieser Reihe gehe ich näher auf die Frage ein, wie sich die Zuverlässigkeit der Memory-Verarbeitung verbessern lässt.

Wenn ihr selbst eine Wissensbasis für eure KI-Tools pflegt: Wie entscheidet ihr, welche Informationen gespeichert werden sollen, und wie viel Verantwortung überlasst ihr dem Agenten, um diese Informationen aktuell zu halten?