Die naheliegende Antwort auf das Gedächtnisproblem von KI-Agenten lautet: ein größeres Kontextfenster. Die Zahlen, die Databricks zur Einführung von Agent Memory veröffentlicht, zeigen etwas anderes. In den internen Benchmarks des Unternehmens lösten Agenten mit eigenem Gedächtnis etwa dreimal so viele reale Unternehmensaufgaben wie identische Agenten ohne – und verbrauchten 31 Prozent weniger Tokens. Dabei geht es nicht um mehr Kontext, sondern um die Frage, ob ein Agent aus seinen Sitzungen lernt oder jede Begegnung bei null beginnt.
Am besten lässt sich das mit einem Archiv vergleichen. Ein schlecht geführtes Archiv bewahrt jeden Vorgang auf, aber niemand findet etwas wieder. Jede Anfrage heißt, den ganzen Stapel durchzublättern. Ein gutes Archiv trennt zwei Dinge: ein Eingangsbuch, das lückenlos festhält, was passiert ist, und ein Register, das verdichtet, was dauerhaft wichtig ist. Diese Trennung steckt hinter Agent Memory von Databricks. Sie wird für Teams relevant, die Databricks-Agenten produktiv betreiben.
Warum zustandslose Agenten denselben Kontext doppelt bezahlen
Sobald ein Agent aus der Demo in den Alltag kommt, zeigen sich zwei Probleme. Das erste ist der Preis der Wiederentdeckung: Ein zustandsloser Agent erarbeitet sich jeden Tag neu, welche Tabelle die Nutzungsdaten hält, was ein internes Kürzel bedeutet und welcher Join funktioniert. In einer internen Sitzung brauchte ein Agent 11 Tool-Aufrufe, 8 Subagenten und fast sechs Minuten, um die Top-Kunden eines Produkts zu beantworten. Am nächsten Tag hätte er das wieder getan.
Das zweite Problem ist der fehlende Bezug zum Nutzer. Jemand nennt eine Präferenz, korrigiert einen Fehler oder erklärt, wie sein Team eine Kennzahl definiert – mit dem Ende der Sitzung ist das weg. Danach wiederholt entweder der Mensch seine Erklärung oder der Agent seinen Fehler. Das kostet Zeit und Vertrauen.
Zwei Notlösungen sind verbreitet, und beide tauschen ein Problem gegen ein anderes. Die erste lädt einfach den kompletten Verlauf erneut in den Kontext. Das funktioniert, bis die Verläufe lang werden: Auf offenen Memory-Benchmarks kostete dieser Ansatz bei gleicher Genauigkeit etwa zwölfmal so viele Eingabe-Tokens pro Frage. Bei den längsten Verläufen wurde das Ergebnis schlechter, weil irrelevante Beiträge den Agenten verwirrten.
Die zweite Notlösung ist der Eigenbau auf Objektspeicher oder in einer Vektordatenbank. Damit übernimmt ein Team Extraktion, Deduplizierung, Abruf und Zugriffskontrolle selbst. In der Praxis veralten Einträge, widersprüchliche Fakten sammeln sich an, und später lässt sich schwer sagen, welcher Eintrag zu einer falschen Antwort geführt hat. Nötig ist ein Gedächtnis, das Kosten und Personalisierung verbessert, ohne dass ein weiteres System betrieben werden muss.
Zwei Schichten, drei Zugriffswege: die MemCurrent-Architektur
Agent Memory auf Databricks ist die Produktversion von MemCurrent, einem Gedächtnissystem aus der Forschung des Unternehmens. Die Erkenntnis dahinter: Ein Gedächtnis funktioniert am besten in zwei Schichten – einem rohen Protokoll dessen, was geschehen ist, und einem verdichteten Bestand dessen, was erinnert werden sollte. Wichtig ist, wer schreibt: nicht der Agent spontan mitten in der Aufgabe, sondern ein Hintergrundprozess, der den Bestand aktuell hält.
Im Bild des Archivs bleibt das Eingangsbuch vollständig, das Register wird regelmäßig überarbeitet. Der Agent muss bei der Arbeit nicht entscheiden, was wichtig ist, und kann sich auf die Aufgabe konzentrieren. Der Verdichtungsprozess sortiert aus, führt Doppelungen zusammen und ersetzt Fakten, die neuere Gespräche widerlegt haben.
Technisch kombiniert MemCurrent drei Zugriffsmuster. Plugins protokollieren und laden Kontext automatisch, ohne eigenen Code des Agenten. Tools ruft der Agent bei Bedarf selbst auf, um gezielt nachzuschlagen. Die Dreaming-Pipeline verdichtet Erinnerungen im Hintergrund, wenn gerade keine Anfrage läuft. Zu Beginn einer Sitzung lädt der Agent einen Index dessen, was im Gedächtnis bekannt ist; während der Sitzung findet er Details über Stichwort- und semantische Suche.
Unter der Haube steht all das auf Lakebase, dem serverlosen Postgres von Databricks, das im eigenen Workspace läuft und vom Anbieter betrieben wird. Speichern und Abrufen von Erinnerungen sollen dadurch schnell sein, und die Speicher wachsen mit dem Agentenverkehr mit. Dieselbe Infrastruktur trägt bereits das Gedächtnis von Genie, der natürlichen Sprachoberfläche von Databricks für Geschäftsnutzer. Das spricht dafür, dass hier kein Demo-Prototyp läuft, sondern eine Komponente, die Last kennt.
Was die Benchmarks zeigen – und was sie nicht zeigen
Die Zahlen von Databricks sind deutlich. Agenten mit Gedächtnis bestanden in einem internen Benchmark für Unternehmensdatenaufgaben etwa dreimal so viele Aufgaben wie Agenten ohne, waren schneller und brauchten weniger Tokens. Im Beispiel oben sank der Aufwand für eine verwandte Folgefrage auf 2 Tool-Aufrufe und 41 Sekunden – nach 11 Aufrufen und fast sechs Minuten zuvor. Der Unterschied kommt nicht von einem klügeren Modell, sondern daher, dass bereits erarbeitetes Wissen nicht ein zweites Mal erarbeitet wird.
Zur Einordnung: Es sind interne Benchmarks des Anbieters, gemessen an eigenen Enterprise-Aufgaben. Unabhängige Messungen gibt es bislang nicht. Wer die Databricks Agent Memory Beta evaluiert, sollte solche Zahlen nicht als Zusage lesen, sondern als Hypothese, die im eigenen Datenbestand zu prüfen ist. Auch die Zwölffach-Zahl zum vollen Kontextverlauf stammt aus offenen Benchmarks, nicht aus dem eigenen Betrieb.
Ein Gedächtnis verschiebt Kosten, es löscht sie nicht. Die Verdichtung der Sitzungen läuft im Hintergrund und verbraucht selbst Rechenleistung und Tokens. Ob sich das rechnet, hängt davon ab, wie oft dieselben Nutzer dieselben Arbeitsabläufe wiederholen. Bei einmaligen Fragen an wechselnde Nutzer bringt ein Gedächtnis wenig, bei wiederkehrenden Aufgaben in einem festen Team sehr viel.
Was sich im Betrieb konkret ändert
Für den Alltag ändern sich vier Dinge. Erstens sinken die Kosten pro Aufgabe, weil der Agent Arbeit überspringt, die er schon einmal erledigt hat. Zweitens bleibt Personalisierung erhalten: Präferenzen, Korrekturen und teaminterne Definitionen überdauern das Sitzungsende und sind einem Nutzer zugeordnet. Menschen müssen sich seltener wiederholen – für die Akzeptanz im Team ist das oft entscheidend.
Drittens bleiben Korrekturen haften. Ein Agent, der einen Fehler erinnert, macht ihn nicht zweimal; das spart Zeit und Tokens. Viertens bleibt der Speicher in eigener Hand: Sitzungen und Erinnerungen liegen im eigenen Lakebase-Projekt, unabhängig vom Agenten-Framework. Entwickler können lesen, exportieren und löschen, was ein Agent über einen Nutzer festhält. Sie können der Verdichtungs-Pipeline auch Anweisungen geben, etwa dauerhafte Kundenpräferenzen zu behalten und einmalige Debug-Notizen zu ignorieren.
Ein Gedächtnis für Unternehmen ist immer auch eine Datenschutzfrage. Ein Speicher, der Nutzerpräferenzen über Sitzungen hinweg hält, braucht Löschkonzepte, Zweckbindung und eine klare Antwort darauf, wer welche Einträge einsehen darf. Databricks adressiert diese Punkte, die Verantwortung für die Ausgestaltung liegt aber beim betreibenden Team.
Agent Memory ist kein Einzelstück, sondern Teil von Agent Bricks, der Entwicklungsplattform für Agenten. Dazu gehören Hosting, eine Sandbox zum Testen, Unity Gateway für den Modellzugriff, vorgefertigte MCP-Server sowie Tracing und Evaluation. Der gleiche Agent nutzt Modelle über das Gateway, wird per Agent Bricks CLI deployt und lässt sich samt Gedächtnis nachvollziehen und bewerten. Der Nutzen: Der Speicher ist nicht mehr die Stelle, an der eine sonst fertige Pipeline auseinanderfällt.
Einstieg mit der CLI und die offenen Punkte
Der Einstieg ist niedrigschwellig. Zusätzliche Infrastruktur sei nicht nötig, heißt es bei Databricks; die Agent Bricks CLI soll einen Agenten samt Gedächtnis und Sitzungen in Minuten deployen. Für neue Agenten gibt es einen Quickstart, für bestehende ein Tutorial, das Gedächtnis und Sitzungen ergänzt. Die Databricks Agent Memory Beta ist allerdings eine Beta – Schnittstellen und Verhalten können sich noch ändern.
Wer den Agentenspeicher auf Databricks produktiv prüfen will, sollte drei Dinge messen. Erstens die Durchlaufquote vor und nach der Umstellung auf den eigenen Aufgaben, nicht auf den Benchmark-Aufgaben des Anbieters. Zweitens die tatsächlichen Token- und Latenzkosten inklusive der Hintergrundverdichtung. Drittens die Qualität des Speichers selbst: Wie viele widersprüchliche Einträge sammeln sich an, wie oft greift der Agent auf Veraltetes zurück, und wie zuverlässig lässt sich ein einzelner Eintrag löschen.
Der Wandel zeigt sich weniger in den Zahlen als in der Rolle solcher Agenten. Ein Agent ohne Gedächtnis ist ein Werkzeug, das man bei jeder Anfrage neu bedient. Ein Agent mit Gedächtnis baut institutionelles Wissen auf – und trägt dafür auch Verantwortung. Wie dieses Gedächtnis gepflegt, geprüft und begrenzt wird, ist deshalb wichtiger als die Frage, wie viele Tokens es einspart. Databricks liefert die Infrastruktur; die Regeln muss jedes Team selbst schreiben.
Quelle: databricks.com
