Mit KI-Stack 2.17 bekommt der lokale Assistent eine Fähigkeit, die für längere Zusammenarbeit entscheidend ist: persistentes Memory. Während die vorherigen Releases den Tool-Zugriff und Local Control aufgebaut haben, adressiert 2.17 eine andere Grenze klassischer Chats. Ein neuer Chat beginnt normalerweise ohne dauerhaftes Wissen darüber, was in früheren Gesprächen bereits festgelegt wurde.
Genau das ändert sich jetzt. Der Assistent kann ausgewählte Informationen lokal speichern und in späteren Gesprächen wiederverwenden. Wichtig ist dabei: 2.17 führt dafür keinen neuen Memory-Dienst, keine zusätzliche Datenbank, keinen weiteren Port und keine Cloud-Abhängigkeit ein. Stattdessen wird die bereits vorhandene native Memory-Funktion von Open WebUI genutzt und gezielt in die passenden KI-Stack-Profile integriert.
Damit bleibt das Architekturprinzip der vorherigen Releases erhalten: Neue Fähigkeiten werden möglichst auf vorhandenen, funktionierenden Komponenten aufgebaut, statt für jede Funktion eine zusätzliche Parallelstruktur einzuführen.
Warum ein lokaler Assistent überhaupt Memory braucht
Ein klassischer Chat besitzt Kontext innerhalb eines Gesprächs. Solange der Chatverlauf im aktuellen Kontext liegt, kann das Modell auf frühere Aussagen reagieren. Beginnt aber ein neuer Chat, steht dieser Kontext nicht automatisch wieder zur Verfügung.
Das ist für viele Aufgaben unproblematisch. Bei längerfristiger Zusammenarbeit wird es jedoch schnell unpraktisch. Ein Benutzer möchte nicht bei jedem neuen Gespräch erneut erklären, welche Umgebung er verwendet, welche Präferenzen gelten oder welche Entscheidungen bereits getroffen wurden.
Typische Beispiele für sinnvolle Erinnerungen wären:
- bevorzugte Sprache oder Antworttiefe
- technische Randbedingungen eines Projekts
- wiederkehrende Arbeitsweisen
- bereits getroffene Architekturentscheidungen
- Präferenzen für bestimmte Tools oder Abläufe
- stabile Informationen über eine Umgebung
Memory schafft damit eine zusätzliche Ebene zwischen kurzfristigem Chatkontext und dauerhaftem Dokumentwissen.
Chatkontext, RAG und Memory sind drei verschiedene Dinge
Gerade beim Thema Memory ist die Abgrenzung zu RAG wichtig.
Der Chatkontext enthält Informationen aus dem aktuellen Gespräch. Er ist kurzfristig und an diesen Chat gebunden.
RAG stellt Wissen aus Dokumenten oder anderen Wissensquellen bereit. Dabei werden relevante Inhalte gesucht und für die aktuelle Anfrage in den Modellkontext eingebracht.
Memory speichert dagegen ausgewählte Informationen, die über mehrere Chats hinweg relevant bleiben sollen.Diese drei Mechanismen ergänzen sich. Keiner ersetzt den anderen. Im KI-Stack bleibt das bestehende RAG-System deshalb unabhängig von Memory bestehen. 2.17 verändert nicht das Retrieval-System, sondern ergänzt eine separate persistente Erinnerungsebene.
Warum keine zweite Memory-Datenbank?
Eine naheliegende Architektur wäre gewesen, einen eigenen Memory-Service mit eigener Datenbank, Embeddings und eigener API einzuführen. Technisch wäre das möglich. Es hätte aber gleichzeitig eine zweite Persistenzschicht geschaffen, die zusätzlich installiert, abgesichert, gesichert und gewartet werden müsste.Open WebUI bringt bereits eine native lokale Memory-Funktion mit. KI-Stack 2.17 nutzt deshalb bewusst diese vorhandene Implementierung.
Es gibt keinen separaten Memory-Server und keine neue externe Datenhaltung. Die gespeicherten Informationen verbleiben damit in der bestehenden lokalen Open-WebUI-Datenbank webui.db.
Das ist besonders für einen lokalen KI-Stack sinnvoll. Jede zusätzliche Datenbank würde nicht nur mehr Komplexität bedeuten, sondern auch einen weiteren Sicherungs- und Recovery-Pfad erfordern.
Memory ist benutzerbezogen
Die native Memory-Funktion ist benutzerbezogen. Gespeicherte Informationen gehören zum angemeldeten Open-WebUI-Benutzer und können über mehrere Chats hinweg genutzt werden.
Damit entsteht erstmals eine echte Kontinuität zwischen getrennten Gesprächen.
Ein Benutzer könnte beispielsweise in einem Gespräch festlegen:
Für dieses Projekt verwende ich Windows 11 und PowerShell 7.
Wird diese Information als Memory gespeichert, kann sie in einem späteren Chat erneut berücksichtigt werden, ohne dass sie erneut eingegeben werden muss.
Memory funktioniert dabei nicht nur innerhalb eines einzelnen Profils. Für denselben authentifizierten Benutzer kann es auch profilübergreifend verfügbar sein, sofern die jeweiligen Profile Memory verwenden dürfen.
Das ist praktisch, erfordert aber gleichzeitig eine bewusste Profilstrategie.
Nicht jedes Profil bekommt Memory
Persistentes Gedächtnis ist nicht automatisch für jeden Agenten sinnvoll.
Deshalb wird Memory in KI-Stack 2.17 gezielt aktiviert.
Die Profile:
ki-stack-it-technikki-stack-allgemein
erhalten native Memory-Unterstützung.
Für:
ki-stack-18bravoki-stack-research
bleibt Memory bewusst deaktiviert.
Das Roleplay-Profil wird nicht aktiv verändert.
Diese Trennung ist wichtig, weil unterschiedliche Agenten unterschiedliche Arbeitsweisen haben.
Ein allgemeiner Assistent profitiert davon, stabile Benutzerpräferenzen zu kennen. Ein Research-Agent sollte dagegen primär mit aktuellen Quellen, Dokumenten und nachvollziehbarem Recherchekontext arbeiten. Persistentes persönliches Memory ist dort nicht automatisch hilfreich.
Warum der Research-Agent bewusst kein Memory bekommt
Bei einem Research-Agenten zählt vor allem Nachvollziehbarkeit.
Wenn ein Agent eine Recherche durchführt, sollte möglichst klar sein, welche Informationen aus Quellen stammen und welche aus dem aktuellen Auftrag.
Persistentes Memory könnte hier zusätzliche, schwer sichtbare Einflussfaktoren einbringen.
Ein Research-Agent sollte beispielsweise nicht deshalb zu einer bestimmten Schlussfolgerung kommen, weil in einem früheren Gespräch eine persönliche Präferenz gespeichert wurde, wenn die aktuelle Aufgabe eigentlich quellenbasiert beantwortet werden soll.
Darum bleibt ki-stack-research in 2.17 ohne natives Memory.
Gleichzeitig bleibt dessen bestehende Knowledge-/RAG-Bindung exakt erhalten. Die Validierung wurde dafür angepasst, damit vorhandene fremde Knowledge-Bindings nicht fälschlich als Fehler erkannt oder entfernt werden.
Memory darf bestehende Tool-Bindings nicht zerstören
2.17 erweitert die Profile um Memory, darf dabei aber die vorherigen Funktionen nicht beschädigen.
Besonders wichtig ist die MCP-Bindung aus 2.15 und 2.16.
Die Profile, die Local Control verwenden, müssen ihre MCP-Verbindung behalten. Ein Reconcile des Agent Packs darf nicht durch die neue Memory-Konfiguration plötzlich Tool-Zugriff verlieren.
Deshalb wurde ausdrücklich geprüft, dass bestehende MCP-Bindings und das Local-Control-Verhalten erhalten bleiben.
Das ist ein wichtiges Architekturprinzip: Neue Agentenfunktionen dürfen bestehende Fähigkeiten nicht stillschweigend überschreiben.
Memory ist nicht automatisch immer aktiv
Ein technisches Detail der verwendeten Open-WebUI-Version ist wichtig.
Memory kann für ein Profil grundsätzlich freigegeben sein, aber die tatsächliche Nutzung innerhalb eines Chats hängt weiterhin von der Memory-Funktion des Chats ab.
Für Open WebUI 0.11.3 existiert kein persistierter serverseitiger Mechanismus, der Memory für jeden neuen Chat automatisch aktiviert. Deshalb bleibt features.memory=true eine Voraussetzung für die Nutzung.
Das bedeutet: Die Infrastruktur kann Memory unterstützen, ohne dass jeder Chat automatisch jedes gespeicherte Memory verwendet.
Diese Trennung ist sinnvoll, weil ein Benutzer damit weiterhin entscheiden kann, ob ein konkretes Gespräch Memory verwenden soll.
Was sollte überhaupt gespeichert werden?
Die technische Möglichkeit, Informationen dauerhaft zu speichern, bedeutet nicht, dass möglichst viel gespeichert werden sollte.
Ein gutes Memory enthält stabile, langfristig relevante Informationen.
Beispiele:
- „Antworten standardmäßig auf Deutsch.“
- „Die Entwicklungsumgebung läuft unter Windows 11.“
- „Für dieses Projekt wird PowerShell 7 verwendet.“
- „Bei Architekturentscheidungen soll die lokale Variante bevorzugt werden.“
Weniger sinnvoll wären kurzfristige Zustände:
- „Der Dienst ist gerade gestoppt.“
- „Heute läuft Container X nicht.“
- „Die aktuelle CPU-Auslastung beträgt 73 Prozent.“
Solche Informationen verändern sich schnell und gehören eher in den aktuellen Kontext oder in eine aktuelle Systemabfrage.
Memory sollte deshalb nicht zu einer zweiten Logdatei werden.
Memory braucht Pflege
Persistentes Memory kann falsch oder veraltet werden.
Eine früher richtige Information kann später nicht mehr gelten. Ein Projekt kann die Plattform wechseln, eine bevorzugte Software kann ersetzt werden oder eine Architekturentscheidung kann revidiert werden.
Ein Memory-System benötigt deshalb nicht nur Funktionen zum Hinzufügen, sondern auch zum Suchen und Löschen.
Genau dieser vollständige Ablauf wurde für 2.17 real getestet:
Memory hinzufügen
↓
Memory suchen
↓
Memory verwenden
↓
Memory löschen
Der reale Add-/Search-/Delete-Acceptance-Flow wurde erfolgreich validiert.
Damit wird Memory nicht als statisches Archiv betrachtet, sondern als verwaltbarer Bestand.
Memory und sensible Informationen
Je mehr ein Assistent dauerhaft speichert, desto wichtiger wird die Frage, welche Informationen überhaupt in ein Memory gehören.
Nicht jede Information, die in einem Chat auftaucht, sollte langfristig gespeichert werden.
Passwörter, Tokens, API-Keys oder andere Secrets gehören grundsätzlich nicht in ein Benutzer-Memory. Gleiches gilt für Informationen, die nur für eine einzelne Sitzung benötigt werden.
Persistentes Memory sollte bewusst kuratiert werden.
Das ist weniger eine technische als eine Governance-Frage.
Die Technik kann speichern. Die eigentliche Frage lautet: Was soll langfristig gespeichert werden?
Ballistics bleibt bewusst restriktiver
Für spezialisierte Agenten gelten teilweise andere Regeln. Beim Ballistics-Kontext bleiben die bestehenden expliziten Save-Confirmation-Regeln erhalten. Das bedeutet, dass Informationen nicht automatisch nur deshalb dauerhaft gespeichert werden, weil Memory technisch verfügbar ist.
Diese Entscheidung bleibt auch mit 2.17 bestehen.Damit wird verhindert, dass kontextabhängige oder sensible fachliche Daten unbemerkt in dauerhaftes Memory übergehen.Auch hier zeigt sich: Memory ist kein globaler Schalter, sondern eine Fähigkeit, die pro Profil und Anwendungsfall geregelt werden sollte.
Mit Memory wird webui.db wichtiger
Bisher enthielt die Open-WebUI-Datenbank bereits wichtige lokale Daten wie Konfigurationen und Gesprächsinformationen.
Mit persistentem Memory steigt ihre Bedeutung weiter.
Die Datei:
webui.db
enthält nun zusätzlich Informationen, die für zukünftige Gespräche relevant sein können.
Damit wird Memory automatisch auch zu einem Backup-Thema.
Ein persistentes Gedächtnis ist nur dann wirklich persistent, wenn es auch nach einem Defekt, Updateproblem oder einer Neuinstallation wiederhergestellt werden kann.
Online-Backup mit SQLite VACUUM INTO
KI-Stack 2.17 ergänzt deshalb einen eigenen Online-Backup-Pfad für die Open-WebUI-Datenbank.Dafür wird SQLite VACUUM INTO verwendet.Der Vorteil liegt darin, dass eine konsistente Kopie der Datenbank erstellt werden kann, während Open WebUI weiterläuft.
Während des realen Backup-Tests blieb Open WebUI gesund und verfügbar.Damit ist für eine normale Sicherung kein vollständiger Shutdown des Frontends notwendig.
Warum einfaches Kopieren einer SQLite-Datei problematisch sein kann
SQLite wirkt zunächst wie eine einzelne Datei, die man einfach kopieren könnte.
Im laufenden Betrieb können jedoch zusätzliche Write-Ahead-Log-Dateien existieren, typischerweise:
webui.db-wal
webui.db-shm
Eine unkoordinierte Dateikopie kann deshalb einen Zustand erfassen, der nicht vollständig konsistent ist.
VACUUM INTO erzeugt dagegen gezielt eine neue konsistente SQLite-Datenbank.
Das ist für einen automatisierten Backup-Pfad deutlich sauberer als ein simples Copy-Item webui.db.
Restore ist kritischer als Backup
Ein Backup zu erzeugen ist vergleichsweise ungefährlich. Ein Restore verändert dagegen den aktiven Datenbestand. Deshalb wurde für 2.17 ein kontrollierter Restore-Pfad implementiert, der mehrere Sicherheitsmaßnahmen kombiniert.Vor einem Restore wird zunächst eine zusätzliche Sicherheitskopie des aktuellen Zustands erstellt. Anschließend wird die wiederherzustellende Datenbank auf Integrität geprüft. Auch vorhandene WAL- und SHM-Dateien werden berücksichtigt, damit keine veralteten Journalzustände mit einer restaurierten Datenbank kollidieren.
Nach dem Restore wird zusätzlich geprüft, ob Open WebUI wieder korrekt funktioniert. Damit folgt Restore nicht dem Prinzip:
Datei überschreiben und hoffen.
sondern einem kontrollierten Ablauf.
Der Restore-Ablauf
Dieser Ablauf reduziert das Risiko, durch einen fehlerhaften Restore den letzten funktionierenden Zustand ebenfalls zu verlieren. Für die Release-Validierung wurde kein Restore auf der produktiven Datenbank durchgeführt. Stattdessen erfolgte ein kontrollierter Restore gegen eine temporäre Datenbankkopie. Das ist für einen produktiven Stack die richtige Vorgehensweise: Restore-Funktionalität testen, ohne für den Test selbst unnötig Produktionsdaten zu gefährden.
Warum Backup und Memory zusammengehören
Auf den ersten Blick könnte Backup wie ein Nebenthema des Memory-Releases wirken. Tatsächlich gehören beide Themen unmittelbar zusammen. Sobald ein System Informationen über längere Zeit behalten soll, muss geklärt sein, was passiert, wenn die zugrunde liegende Datenbank beschädigt wird oder verloren geht. Persistenz ohne Backup ist nur scheinbare Persistenz. Deshalb ist die Ergänzung von Online-Backup und kontrolliertem Restore ein wesentlicher Teil von 2.17 und nicht nur ein zusätzliches Betriebsfeature.
Keine neue Cloud-Abhängigkeit
Die gesamte Memory-Architektur bleibt lokal. Gespeicherte Memories liegen in der lokalen Open-WebUI-Datenbank. Es wird kein externer Memory-Service angesprochen und keine zusätzliche Cloud-Komponente eingeführt. Für den KI-Stack ist das ein zentraler Punkt. Ein lokaler Assistent sollte nicht ausgerechnet seine langfristigsten Informationen an einen externen Dienst auslagern müssen, wenn das restliche System lokal betrieben wird.
Damit bleibt auch 2.17 dem bisherigen Grundprinzip treu:
lokale Daten, lokale Werkzeuge, lokale Kontrolle.
Memory verändert die Zusammenarbeit stärker als das Modell
Persistentes Memory verbessert nicht direkt die Qualität des Sprachmodells. Das Modell wird dadurch nicht größer, schneller oder intelligenter. Was sich verändert, ist die Kontinuität der Zusammenarbeit.
Ohne Memory:
Neuer Chat
↓
Kontext erneut erklären
↓
Arbeit beginnen
Mit Memory:
Neuer Chat
↓
relevante bekannte Informationen vorhanden
↓
direkter weiterarbeiten
Gerade bei wiederkehrenden technischen Aufgaben kann dieser Unterschied erheblich sein.
Ein lokaler Assistent beginnt dadurch weniger häufig bei null.
Von Local Control zu einem kontinuierlichen Assistenten
Die Entwicklung der letzten Releases wird mit 2.17 besonders deutlich.
2.14 hat den kontrollierten lokalen Terminalzugriff geschaffen.
2.15 hat diesen Zugriff über MCP standardisiert.
2.16 hat daraus Local Control gemacht.
2.17 ergänzt nun persistentes Memory.
Damit entsteht folgende Entwicklung:
2.14
Lokaler Zugriff
↓
2.15
MCP
↓
2.16
Local Control
↓
2.17
Persistent Memory
↓
lokaler Assistent mit Werkzeugen
und langfristigem Kontext
Der Assistent kann damit nicht nur lokale Aufgaben durchführen. Er kann sich zusätzlich ausgewählte Informationen merken, die für spätere Aufgaben weiterhin relevant sind.
Was 2.17 bewusst nicht ist
2.17 ist kein autonomes „Gedächtnis über alles“.
Nicht jeder Chatinhalt wird automatisch gespeichert. Nicht jedes Profil verwendet Memory. Und gespeicherte Informationen bleiben verwaltbar und löschbar.
2.17 ersetzt auch nicht RAG.
Dokumentwissen bleibt Dokumentwissen. Memory bleibt langfristiger Benutzer- beziehungsweise Arbeitskontext.
Ebenso wird kein neuer MCP-Memory-Server eingeführt. MCP, Local Control und Memory bleiben getrennte Architekturbausteine.
Diese Trennung ist wichtig, weil jede Funktion eine andere Aufgabe erfüllt:
MCP
= Zugang zu Werkzeugen
Local Control
= Werkzeuge für lokale Aktionen nutzen
RAG
= Wissen aus Dokumenten bereitstellen
Memory
= langfristig relevante Informationen behalten
Was tatsächlich validiert wurde
Für 2.17 wurden nicht nur Konfigurationsänderungen vorgenommen.
Die Release-Validierung umfasst unter anderem:
- 34 von 34 Repository-Regressionstests bestanden
- Memory-/Profilvalidierung bestanden
- Knowledge-Preservation im Agent Pack bestanden
- Ballistics-Reconcile mit deaktiviertem Memory bestanden
- realer Memory Add/Search/Delete-Flow bestanden
- SQLite-Cleanup geprüft
- reales Online-Backup von
webui.dbbestanden - Open WebUI blieb während des Backups gesund
- kontrollierter Restore gegen eine temporäre Datenbankkopie bestanden
Ein Restore der produktiven Datenbank wurde bewusst nicht durchgeführt.
Damit ist auch 2.17 nicht nur als Konfigurationsidee validiert, sondern gegen reale Datenbank- und Memory-Pfade getestet.
Fazit
KI-Stack 2.17 ergänzt eine Fähigkeit, die für einen langfristig nutzbaren lokalen Assistenten fast genauso wichtig ist wie Tool-Zugriff: Erinnerung.
Dabei wurde bewusst keine neue Memory-Plattform entwickelt. Stattdessen nutzt der Stack die native lokale Memory-Funktion von Open WebUI und integriert sie nur dort, wo sie fachlich sinnvoll ist.
Gleichzeitig wird das Thema konsequent aus Betriebssicht betrachtet. Wenn Memories dauerhaft relevant sind, muss auch die zugrunde liegende Datenbank zuverlässig gesichert und wiederhergestellt werden können. Deshalb gehören Online-Backup, Integritätsprüfung und Restore genauso zu 2.17 wie das eigentliche Speichern von Erinnerungen.
Nach 2.14 bis 2.17 besitzt der KI-Stack damit vier zentrale Bausteine eines lokalen Assistenten:
lokalen Zugriff, standardisierte Tools, Local Control und persistentes Memory.
Der nächste Entwicklungsschritt liegt damit weniger bei der Frage, ob der Assistent auf das lokale System zugreifen kann. Interessanter wird nun, welche Anwendungen sich nur über grafische Benutzeroberflächen bedienen lassen und wie sich auch solche Workflows kontrolliert automatisieren lassen.