Ein LLM erinnert sich an nichts – jede Session beginnt bei null. Dieser Beitrag erklärt, wie Algroveon-Agent dieses Problem mit einem vierlagigen Gedächtnis-System und einem mehrstufigen Agentic Loop löst.
LLMs verfügen über kein inhärentes Langzeitgedächtnis, was die Kontinuität in der täglichen Nutzung einschränkt. Der Algroveon-Agent begegnet dieser Problematik durch ein mehrstufiges Gedächtnis-System, das mittels einer SQLite-basierten Session-Log-Ebene eine unterbrechungsfreie Gesprächsführung ermöglicht.
Diese Zusammenfassung wurde mit KI-Unterstützung erstellt.
Ein LLM „erinnert“ sich an nichts. Es gibt kein dauerhaftes Wissen, keinen stabilen Zustand und keine echte Kontinuität zwischen einzelnen Anfragen. Alles, was ein Modell über einen Menschen, eine Aufgabe oder eine Präferenz wissen soll, muss im Kontext der aktuellen Anfrage stehen. Und dieser Kontext ist begrenzt. Gerade bei lokalen Modellen liegt das praktische Limit im Alltag oft deutlich unter dem, was auf dem Papier möglich wäre – nicht nur wegen des Modells selbst, sondern auch wegen Rechenaufwand, Speicherbedarf und Geschwindigkeit.
Für einen Assistenten, der im Alltag wirklich nützlich sein soll, ist das ein zentrales Problem:
Die Antwort von Algroveon-Agent auf dieses Problem ist ein vierlagiges Gedächtnis-System. Dieser Beitrag erklärt, wie es aufgebaut ist, wie die mehrstufige Arbeitslogik des Assistenten damit zusammenspielt und welche Probleme in der Praxis dabei aufgetaucht sind.
Der Session-Log ist die Arbeitsebene. Jede Nutzernachricht, jede Modellantwort, jeder Tool-Call und jedes Tool-Ergebnis wird sofort in eine SQLite-Datenbank geschrieben. Das ist kein Extra, sondern die Grundlage des Systems.
Warum sofort schreiben und nicht erst am Ende einer Session? Weil Sessions abbrechen können. Ein Server-Neustart, ein Browser-Crash oder ein unterbrochener Request reichen aus. Wenn der Zustand dann nur im RAM liegt, ist er weg. Der Session-Log schreibt deshalb jeden Eintrag so, dass eine wiederhergestellte Session ohne Bruch weiterlaufen kann.
Beim Öffnen einer bestehenden Session werden die letzten Nachrichten aus dem Session-Log geladen und als Kontext an das Modell übergeben. So entsteht Gesprächskontinuität innerhalb einer aktiven Session.
Session-Memory sind kurze Notizen, die das Modell für die Dauer einer Session ablegen kann. Es ist kein Langzeitgedächtnis – endet die Session, verschwinden diese Einträge wieder. Im Grunde ist es ein Notizzettel: „Für diese Aufgabe brauche ich Datei X“ oder „Der Nutzer möchte das Ergebnis heute im Format Y“.
Das Modell kann Session-Memory aktiv über ein memory-Tool schreiben und lesen. Der Unterschied zum Long-Term-Memory ist bewusst klar gezogen: kein Approval, kein SourceTag-Gate, sofortiger Schreibzugriff. Der Scope ist ausdrücklich ephemer.
Long-Term-Memory sind dauerhafte Informationen, die über Sessions hinweg verfügbar bleiben. Sie werden beim Login als Teil des Kontexts an das Modell übergeben – noch bevor die erste Nutzernachricht eingeht. Das ist die Ebene, die aus einem einfachen Dialogsystem überhaupt erst einen Assistenten mit Kontinuität macht.
Zwei Quellen füllen dieses Long-Term-Memory:
SessionSummarizer: Nach dem Logout komprimiert ein Summarizer die abgeschlossene Session in maximal fünf Sätze. Diese Zusammenfassung wird als Long-Term-Memory-Item gespeichert. Bei der nächsten Login-Session werden bis zu fünf solcher Summaries als seed_messages in den Kontext geladen – vor dem eigentlichen Chat-Verlauf. Das Modell ist damit sofort grob im Bild, worum es in früheren Sessions ging, welche Themen aktiv waren und welche Vereinbarungen bereits bestanden.
ProfileFacts: Im Laufe von Gesprächen kann der Agent Fakten über den Nutzer erkennen. Diese werden nicht stillschweigend übernommen. Der Nutzer bekommt eine Bestätigungsanfrage, und erst nach expliziter Zustimmung wird der Fakt persistent gespeichert. Das ist zugleich das Schutzgitter gegen Memory-Poisoning und ungewollte Dauerannahmen.
Für größere Informationsmengen reicht es nicht mehr, alles direkt in den Kontext zu schieben. Dafür gibt es den Retrieval-Index. Er beantwortet im Kern eine einfache Frage: „Was davon ist für die aktuelle Anfrage wirklich relevant?“
Der Index kombiniert zwei Methoden:
nomic-embed-text erzeugt Embeddings für gespeicherte Inhalte und für die aktuelle Anfrage; die semantische Nähe wird über Kosinus-Ähnlichkeit mit NumPy bestimmtDas hybride Retrieval kombiniert beide Scores. Reine Keyword-Treffer funktionieren gut für Namen, Befehle und spezifische Begriffe. Die semantische Suche findet dagegen auch Inhalte, die thematisch passen, obwohl andere Formulierungen verwendet wurden.
Das Ergebnis: Relevante Long-Term-Einträge werden gezielt in das Context-Fenster gezogen, statt alles dauerhaft mitzuschleppen.
Wenn ein Nutzer sich einloggt, ist der erste LLM-Aufruf meist der aufwendigste. In diesem Moment muss das Modell nicht nur auf die aktuelle Anfrage reagieren, sondern auch erst wieder in den richtigen Zusammenhang gebracht werden.
Algroveon-Agent löst das mit einem zweistufigen Kontext-Header:
Stufe 1 – Seed-Messages: Bis zu fünf Long-Term-Memory-Summaries aus vergangenen Sessions. Das gibt dem Modell sofort eine Form von Kontinuität: Es weiß, welche Themen zuletzt relevant waren, welche Projekte offen sind und an welcher Stelle frühere Gespräche geendet haben.
Stufe 2 – Recent Context: Die letzten 20 Nachrichten der vorherigen Session dieses Nutzers. Das sorgt für unmittelbare Gesprächskontinuität bei laufenden Aufgaben – ohne den gesamten Verlauf erneut laden zu müssen.
Der Effekt ist im Alltag entscheidend: Eine Session von gestern kann fortgesetzt werden, ohne dass der Nutzer erst wieder erklären muss, „wo wir stehen geblieben sind“.
Ein einzelner Tool-Call ist noch recht einfach: Der Nutzer fragt etwas, das Modell ruft ein Tool auf, das Ergebnis kommt zurück, und daraus entsteht die Antwort.
Agentic Tasks sind deutlich komplexer. Ein Beispiel:
„Schau, was meine letzten fünf E-Mails in den Postfächern A und B sind, und erstelle mir einen kurzen Überblick.“
Dafür braucht der Agent mehrere Schritte:
mail_list für Postfach A aufrufenmail_list für Postfach B aufrufenmail_read für die relevanten Mails aufrufenDas sind schnell mehrere Tool-Call-Runden. Algroveon-Agent unterstützt Loops von bis zu sechs Durchläufen. Wenn nach sechs Runden kein finaler Text ausgegeben wurde, bricht der Loop kontrolliert ab. Das ist bewusst so gewählt, damit aus einem Agenten kein Endlosschleifen-Generator wird.
Der Loop funktioniert wie folgt:
1. Aufbau des Kontexts (System-Prompt, Seed-Messages, Session-Log)
2. Erster LLM-Aufruf
3. Antwort parsen: Text oder Tool-Calls?
→ Nur Text: fertig, streamen
→ Tool-Calls: weiter
4. Tool-Calls durch Policy Engine prüfen
→ BLOCKED: Fehler zurückmelden
→ APPROVAL_REQUIRED: pausieren, warten
→ ALLOWED: ausführen
5. Tool-Ergebnisse in den Message-Stack einfügen
6. Nächster LLM-Aufruf → zurück zu Schritt 3
Auf dem Papier sieht das recht geradlinig aus. In der Praxis wird es an einer anderen Stelle schwierig: Reasoning-Modelle halten sich nicht immer sauber an diesen Ablauf.
Der Agentic Loop ist vollständig in einer Klasse umgesetzt, die keinen HTTP-Layer braucht. Der HeadlessRunner führt denselben Ablauf aus wie der eigentliche Endpoint – gleicher Kontextaufbau, gleiche Policy Engine, gleicher Audit-Log, nur ohne SSE-Stream.
Das ermöglicht zwei wichtige Einsatzfälle:
Zeitgesteuerte Tasks: Ein interner Scheduler kann HeadlessRunner-Aufrufe nach Zeitplan auslösen. Der tägliche Morgenbrief ist das naheliegende Beispiel: Wetter, Kalender und konfigurierte RSS-Feeds werden zusammengestellt und per Mail versendet – vollständig ohne direkte Nutzerinteraktion.
Messenger-Integration: Eine Anbindung an Messenger ist grundsätzlich mitgedacht, aktuell aber noch nicht umgesetzt.
Der Zeitpunkt ist bewusst gewählt: Der Summarizer läuft nicht während der Session, sondern erst nach dem Logout.
Während einer laufenden Session wäre ein kontinuierlicher Summarizer eher störend. Er würde in einen aktiven Arbeitsprozess eingreifen und im Zweifel nur unnötig Last erzeugen. Nach dem Logout dagegen ist die Session abgeschlossen. Der gesamte Verlauf liegt vollständig vor und kann in Ruhe verdichtet werden.
Der Summarizer bekommt die komplette Session und erzeugt daraus maximal fünf Sätze. Das Komprimierungsverhältnis liegt typischerweise bei 10:1 oder höher. Fünf Sätze aus einer Stunde Arbeit wirken zunächst knapp, reichen in der Praxis aber oft aus, damit man beim nächsten Login sofort wieder im Thema ist.
Das Memory-System funktioniert und bringt im Alltag spürbar etwas. Es hat aber auch klare Grenzen:
RAG für große Dokumente ist vorbereitet, aber noch nicht aktiv. Der Retrieval-Index existiert, die Embedding-Pipeline ebenfalls. Für echtes Retrieval-Augmented Generation über größere Dokumentenmengen fehlt aber noch eine saubere Indexierungs-Pipeline: neue Dateien im Workspace automatisch embedden, Änderungen erkennen und Re-Indexierungen zuverlässig steuern. Die Grundlage ist vorhanden, die eigentliche Produktivschicht darüber noch nicht.
Zusammenfassungen verlieren Nuancen. Gemeint ist hier der SessionSummarizer aus dem vorigen Abschnitt: Er verdichtet eine komplette Sitzung am Ende auf maximal fünf Sätze. Das reicht oft, um beim nächsten Login den Faden schnell wiederzufinden. Bei längeren oder technisch tieferen Sitzungen gehen dabei aber zwangsläufig Details verloren.
Die Seed-Message-Sequenz wächst langfristig weiter. Jede abgeschlossene Session erzeugt einen neuen Eintrag. Mittelfristig braucht das System deshalb eine zweite Komprimierungsstufe – also Zusammenfassungen von Zusammenfassungen, sobald ein Nutzer sehr viele Sessions angesammelt hat. Das ist aktuell noch kein akutes Problem, aber ein klar bekannter technischer Schuldenpunkt.
Das Memory-System von Algroveon-Agent versucht, das grundlegende Zustandslosigkeitsproblem von LLMs in eine Form zu bringen, die im Alltag wirklich brauchbar ist: vier Lagen mit unterschiedlichen Lebensdauern, ein hybrider Retrieval-Index, ein Session-Summarizer und ein Agentic Loop, der mehrere Tool-Runden hintereinander sauber abarbeiten kann.
Die wichtigste Erkenntnis dabei ist: Gedächtnis in einem KI-System ist kein reines Speicherproblem. Es ist vor allem eine Frage der Relevanz. Was wird geladen, wann, in welcher Form und in welchem Maß? Lädt man zu viel, entsteht Rauschen. Lädt man zu wenig, fehlt genau die Kontinuität, die einen Assistenten erst nützlich macht.
Diese Balance ist nicht theoretisch am Reißbrett entstanden, sondern iterativ im Betrieb. Jede reale Nutzungs-Session zeigt neu, was das System wirklich braucht – und was man ihm besser erspart.
algroveonbook ist ein selbst gehostetes System, in dem Algroveon-Agent eigenständig schreibt, Gedanken entwickelt und über Zeit ein persistentes Außengedächtnis aufbaut. Ein Entwicklertagebuch über autonome Kognition ohne 'AI Theater'.
Warum ich begonnen habe, ein lokales LLM auf eigenem Server zu betreiben – und was das konkret bedeutet: Hardware, Virtualisierung, GPU-Wahl und die realen Grenzen lokaler Modelle.