AI Agent Memory: Build vs. Buy

Entwickeln Sie Ihr Agent Memory selbst, wenn Ihr Retrieval-Muster einfach und stabil ist: Eine Postgres-Tabelle mit einigen typisierten Spalten und einem Aktualitätsfilter übertrifft eine Plattformintegration sowohl in Bezug auf Kosten als auch auf Nachvollziehbarkeit. Kaufen Sie eine verwaltete Memory-Schicht erst dann, wenn Sie viele Nutzer haben, die jeweils ihren eigenen langlebigen Memory-Graphen aufbauen, und wenn keine Engineering-Kapazität mehr vorhanden ist, um Decay-, Zusammenfassungs- und Ranking-Logik selbst zu verantworten.

„Agent Memory" ist über Nacht zu einer überfüllten Kategorie geworden: Jeder AI-Agent-Anbieter bringt inzwischen ein „Memory"-Produkt auf den Markt, und jeder Gründer, der einen Agent entwickelt, fragt sich, ob er eines davon braucht. Die ehrliche Antwort lautet: Die meisten Teams verwechseln drei grundlegend verschiedene Probleme miteinander und kaufen am Ende eine Plattform für ein Problem, das eine einzige SQL-Tabelle gelöst hätte.

Was „Memory" für einen Agent wirklich bedeutet

Hinter dem Marketing verbergen sich beim Agent Memory genau drei Dinge:

• Session State: Was in diesem Gespräch passiert ist. Das ist reines Context-Window-Management – kein Memory im eigentlichen Sinne. Kaufen Sie dafür nichts.
• Strukturierte Fakten: Der Plan-Tarif eines Nutzers, seine letzten fünf Bestellungen, eine Präferenz, die er einmal geäußert hat. Das ist ein Datenbankproblem mit einem Lookup-Schlüssel.
• Emergenter Abruf: Der Agent bringt von sich aus etwas Relevantes an die Oberfläche – Wochen nach der ursprünglichen Erwähnung, gewichtet nach Relevanz und Aktualität, ohne dass jemand explizit einen Index angelegt hat. Das ist der einzige Teil, der wirklich anspruchsvoll ist.

Die meisten Produkte, die fragen „Brauchen wir Agent Memory?", meinen eigentlich den zweiten Punkt. Und der zweite Punkt ist eine facts-Tabelle mit den Spalten user_id, type, value und updated_at. Keine Plattform erforderlich.

Das Argument für Eigenentwicklung

Wenn Ihre Memory-Abfragen vorhersehbar sind, entwickeln Sie es selbst. Ein typisches Schema besteht aus einer Postgres-Tabelle, die nach Nutzer oder Mandant geschlüsselt ist, einem type-Enum für die Art des Fakts, einer JSON-Spalte value sowie pgvector auf einem Zusammenfassungsfeld – für die Fälle, in denen Sie tatsächlich semantische Suche statt exakter Abfragen benötigen. Die Grundlagen finden Sie in den PostgreSQL-Dokumentationen zu JSONB und in pgvector.

Der Vorteil liegt nicht nur in den Kosten, sondern in der Kontrolle. Wenn Memory-Probleme auftreten – ein Agent bringt einen veralteten Fakt an die Oberfläche oder vergisst etwas, das er hätte behalten sollen –, müssen Sie in der Lage sein, SELECT * FROM facts WHERE user_id = ... auszuführen und genau zu sehen, was gespeichert ist und warum es abgerufen wurde oder nicht. Eine verwaltete Plattform macht daraus ein Support-Ticket. Dieselbe Erkenntnis haben wir in unserer eigenen Arbeit zu Single-Call vs. Agent Chains gewonnen: Je weniger Indirektionsebenen zwischen Ihrem Code und dem zugrunde liegenden Store liegen, desto schneller können Sie nachvollziehen, warum ein Agent sich eigenartig verhalten hat.

Eigenentwicklung ist auch dann die bessere Wahl, wenn:

• Sie ein primäres Retrieval-Muster haben (nach Nutzer, nach Gespräch, nach Entität) statt eines offenen „Finde alles Relevante".
• Das Datenvolumen pro Nutzer gering ist (wenige Dutzend bis niedrige dreistellige Faktenanzahl), sodass einfaches Filtern einen spezialisierten Ranking-Engine schlägt.
• Sie Postgres bereits betreiben und keinen weiteren Anbieter in Ihre Evaluierungsliste für AI-Agent-Anbieter aufnehmen möchten.

Das Argument für den Kauf

Verwaltete Memory-Plattformen zahlen sich aus, wenn das Retrieval-Problem wirklich offen gestaltet ist: viele Nutzer, jeder mit einem großen und wachsenden Memory-Graphen, bei dem der Agent selbst entscheiden muss, welche Erinnerungen im aktuellen Kontext relevant sind – ohne dass Sie die Ranking-Logik selbst schreiben. Das ist ein echtes Engineering-Problem, das Decay-Funktionen, Widerspruchsauflösung (die Präferenz des Nutzers hat sich geändert – welcher Fakt gewinnt?) und die Verdichtung alter Erinnerungen zu komprimierten umfasst, damit der Graph nicht unbegrenzt wächst.

Kaufen Sie, wenn:

• Sie Consumer-skalierte, mandantenfähige Agents betreiben, bei denen das Memory-Volumen pro Nutzer unbegrenzt wachsen wird.
• Sie automatische Zusammenfassung oder gezieltes Vergessen benötigen und der Eigenaufbau ein mehrtägiges Projekt wäre, für das Sie keine Kapazität haben.
• Die Stärke Ihres Teams im Produkterlebnis liegt – nicht in der Memory-Infrastruktur – und die Preisgestaltung der Plattform tatsächlich günstiger ist als der Engineering-Aufwand, sie zu replizieren.

Das Risiko auf der Kaufseite spiegelt das wider, was wir über das Self-Hosting von LLMs vs. API-Kosten und Compliance geschrieben haben: Sie tauschen einmalige Entwicklungskosten gegen laufende Kosten pro Aufruf oder Nutzer ein – plus eine Abhängigkeit von einer Roadmap, die Sie nicht kontrollieren. Lesen Sie das tatsächliche Retrieval- und Ranking-Verhalten des Anbieters, bevor Sie sich festlegen – genauso wie Sie Evals in einem AI-Anbietervertrag lesen würden, bevor Sie unterschreiben.

Ein allgemeines Prinzip: Werkzeug und Retrieval-Muster aufeinander abstimmen

Wir sind bei unserem eigenen Outreach-Agent auf eine ähnliche Build-vs.-Buy-Frage gestoßen. Dieser Agent ruft die Website jedes Interessenten ab und formuliert eine individuell zugeschnittene E-Mail. Anfangs haben wir eine mehrstufige Pipeline mit einem separaten Memory-Schritt in Betracht gezogen, der verwaltet, was der Agent über ein Unternehmen über mehrere Durchläufe hinweg bereits gelernt hatte. Es stellte sich heraus, dass ein Single-Call-Muster – bei dem die abgerufenen Fakten direkt im Kontext übergeben werden – die mehrstufige Variante sowohl in Bezug auf Kosten als auch auf Qualität übertraf. Denn das „Memory", das wir brauchten, war schlicht „das letzte Scrape-Ergebnis" – kein sich entwickelnder Graph. Die Lehre lässt sich direkt übertragen: Greifen Sie nicht zu einer Infrastruktur, die für offenen Abruf konzipiert ist, wenn Ihr tatsächliches Retrieval-Muster ein einfacher Lookup ist.

Ein einfacher Entscheidungstest

Stellen Sie sich drei Fragen, bevor Sie sich entscheiden:

1. Können Sie die Abfrage im Voraus benennen? Wenn Sie die WHERE-Klausel heute schreiben können, entwickeln Sie es selbst.
2. Wird das Memory pro Nutzer unbegrenzt wachsen? Falls ja – und Sie keinen Plan zur Bereinigung haben –, spart der Kauf von Decay- und Zusammenfassungslogik echte Zeit.
3. Haben Sie jemanden, der das ein Jahr lang verantwortet? Selbst entwickelte Systeme brauchen einen Eigentümer. Wenn niemand die Kapazität hat, verschiebt ein Kauf diese Verantwortung zum Anbieter – zu einem Preis.

Die meisten Agent-Produkte – insbesondere B2B-Tools mit einigen hundert strukturierten Fakten pro Account – landen beim Selbstentwickeln. Consumer-skalierte Personalisierungsprodukte landen beim Kaufen. Wissen Sie, was Sie bauen, bevor Sie anfangen, Plattformen zu evaluieren.

Wenn Sie einen Agent konzipieren und eine zweite Meinung einholen möchten, ob Memory überhaupt die richtige Investitionsebene ist, sprechen Sie uns an.