Wann reicht naives Agent-Memory nicht mehr aus?

Der Moment, in dem die Demo auf den Montagmorgen trifft

Jedes Team, das agentische Lösungen baut, erlebt denselben stillen Moment. Die Demo lief gut: Der Agent merkte sich, dass ein Kunde E-Mail bevorzugt, zog den richtigen Absatz aus der Erstattungsrichtlinie und antwortete in Sekunden. Dann bittet jemand ihn um echte Arbeit. „Bereite die Verlängerung für die Müller GmbH vor.“

Und der Agent, der eine ordentliche Markdown-Notizdatei und einen Vektorindex über jedes Dokument des Unternehmens hat, liefert etwas, das technisch korrekt und praktisch nutzlos ist. Er weiß nicht, dass der Rabatt im CRM eine einmalige Ausnahme war, im März genehmigt. Er weiß nicht, dass der Champion im Juli gegangen ist oder dass der Einkaufsleiter nur donnerstags unterschreibt. Er kann es nicht wissen, denn nichts davon war je ein Dokument. Es war eine Entscheidung, eine Beziehung, ein Timing – das Bindegewebe zwischen den Datensätzen, nicht die Datensätze selbst.

Das ist kein Versagen des Modells. Es ist ein Versagen dabei, wie wir das sammeln, speichern und durchsuchen, womit das Modell denken darf.

Wie aus Haftnotiz und Suchleiste „Agent-Memory“ wurde

Fairerweise muss man der ersten Generation etwas zugutehalten. Agents begannen als Chat mit Tools, und das Gedächtnis, das um sie herum wuchs, war das Billigste, das funktionierte.

Die erste Zutat war eine Notizdatei. Der Agent schreibt auf, was er gelernt hat, liest es zu Beginn der nächsten Sitzung wieder ein, und mit der Zeit wird die Datei eine Art Persönlichkeit: Präferenzen, Konventionen, Lehren. Die zweite Zutat war Retrieval. Jedes Dokument in Chunks zerlegen, die Chunks einbetten und bei einer Frage die zehn nächsten Nachbarn in den Prompt ziehen. Nichts zu modellieren, nichts zu pflegen, am ersten Tag einsatzbereit.

Für eine breite Klasse von Aufgaben ist das weiterhin die richtige Antwort. „Was sagt unsere Reiserichtlinie zu Taxis?“ ist ein Nachschlagen. „Fasse diesen Vertrag zusammen“ braucht den Vertrag, nicht das Unternehmen. Ist die Arbeit auf ein Dokument und eine Sitzung begrenzt, sind Markdown-Datei und Vektorindex kein Kompromiss, sondern das richtige Werkzeug.

Das Problem: Beide Zutaten beantworten dieselbe enge Frage – welcher gespeicherte Text ähnelt den Worten, die ich gerade bekommen habe? Diese Frage taugt, um einen Absatz zu finden. Für eine Entscheidung ist sie die falsche.

Die Form einer echten Business-Aufgabe

Schauen Sie, was „Verlängerung vorbereiten“ tatsächlich verlangt, und die Fehlpassung wird offensichtlich. Echte Aufgaben haben vier Eigenschaften, für die Ähnlichkeitssuche nie gebaut wurde.

• •Sie umspannen viele Entitäten. Ein Account, drei Kontakte, zwei Verträge, ein Wettbewerber, ein Support-Ticket, ein interner Verantwortlicher. Die Antwort steckt in keinem einzelnen davon, sondern in ihrem Zusammenhang.
• •Sie sind zeitgebunden. Was im zweiten Quartal galt, gilt jetzt nicht mehr. Der Rabatt ist ausgelaufen, der Champion hat gewechselt, die Preisregel wurde geändert. Ein Vektorindex kennt kein „Stand vom“; ein veralteter Absatz, der gut klingt, schlägt einen aktuellen, der schlecht klingt.
• •Sie überschreiten Systeme und Funktionen. Die Belege liegen im CRM, in E-Mails, in einem Slack-Thread, in einer Finanztabelle und in jemandes Kopf. Jedes davon wurde getrennt indexiert, wenn überhaupt.
• •Sie hängen an Entscheidungen, nicht an Fakten. Wichtig am Rabatt vom März ist nicht die Zahl. Wichtig ist, dass es eine Ausnahme war, wer sie genehmigt hat und warum. Diese Begründung war nie ein Datensatz und wurde deshalb nie eingebettet.

Währenddessen hat die Notizdatei ihren eigenen schleichenden Verfall. Sie wächst, widerspricht sich, hat keine Herkunft, und niemand kann sie aufräumen, weil niemand weiß, welche Zeile noch zählt. Bei 50 Zeilen ist das ein Gedächtnis. Bei 2.000 ist es Rauschen mit gutem Ruf.

Also tut der Agent, was er kann: Er findet Dinge, die wie die Frage klingen, und schlussfolgert selbstbewusst über den falschen Kontext. In der Demo sieht das Ergebnis gut aus, in der Praxis ist es fast immer falsch.

Retrieval ist ein Aufmerksamkeitsproblem, kein Suchproblem

Hier ist die Neubetrachtung, die meiner Meinung nach am meisten zählt. Ein Sprachmodell kann nur über das nachdenken, was vor ihm liegt. Seine Aufmerksamkeit ist begrenzt und wird für das aufgebraucht, was wir ins Kontextfenster legen. Retrieval ist deshalb keine Suchfunktion, die an den Agent drangeschraubt wird. Es ist der Mechanismus, der entscheidet, worauf das Modell achten darf.

So gesehen ist „liefere die zehn ähnlichsten Chunks“ eine seltsame Regel. Sie füllt die Aufmerksamkeit des Modells mit Text, der der Frage ähnelt, und lässt weg, was die Antwort bestimmt: die Beziehung zwischen Account und Vertrag, das Datum, an dem die Ausnahme gewährt wurde, die Person, die tatsächlich Ja sagen kann.

Ich sage es noch einmal: Der wichtigste Prozess der meisten Unternehmen wurde nie aufgeschrieben. Es ist das Denken, das einen Datensatz mit dem nächsten verbindet, der Ausnahmeweg, das „bei diesem Kunden machen wir das immer so“. Systems of Record speichern, was passiert ist. Niemand speichert, warum. Und ein Agent, der Text durchsucht, findet nur, was geschrieben wurde.

Es gibt einen zweiten, leiseren Fehler im einfachen Memory: Es wirft zwei sehr verschiedene Arten von Information in einen Topf. Rohe Beobachtungen (eine E-Mail kam an, ein Ticket wurde geschlossen, ein Transkript nannte einen Wettbewerber) liegen neben bestätigtem Wissen (dieser Account verlängert im November, dieser Kontakt ist der Economic Buyer). Das Erste ist reichlich und unzuverlässig, das Zweite selten und wertvoll. Ein Agent braucht einen Beleg-Strom und ein kuratiertes Weltmodell, sauber getrennt, mit einem bewussten Prozess, der das eine ins andere hebt. Eine einzelne Markdown-Datei oder ein einzelner Vektorindex bietet beides nicht.

Was sich ändert, wenn Kontext ein Graph ist

Die sich abzeichnende Antwort, auf die mehrere Teams unter dem Namen Context Graph zugelaufen sind, ändert alle drei Schritte: wie Kontext gesammelt, wie er gespeichert und wie er durchsucht wird.

Das Sammeln wandert in den Arbeitsfluss. Statt Kontext nachträglich aus Dokumenten zu rekonstruieren, erfasst das System ihn dort, wo er entsteht: wenn eine Entscheidung fällt, eine Ausnahme genehmigt wird, ein Agent eine Aufgabe abschließt und festhält, was er genutzt und was er geschlossen hat. Die Entscheidungsspur wird zu Daten. Nur so lässt sich das „Warum“ erfassen, das nie in einen Datensatz gelangte.

Das Speichern wird typisiert und zeitbewusst. Entitäten (Accounts, Personen, Verträge, Produkte, Projekte) sind Knoten. Beziehungen sind Kanten mit Typ, Quelle, Konfidenz und Gültigkeitszeitraum. „Die Müller GmbH hatte 15 % Rabatt, genehmigt von Anna, gültig von März bis Juni, wegen einer Konkurrenzausschreibung“ ist ein kleiner Teilgraph, kein Absatz. Hier leben die zwei Boxen: Rohsignale kommen als Kandidaten an; kuratierte Fakten sind das, worüber der Agent schlussfolgert.

Die Suche wird zu Traversierung, dann zu Zusammenstellung. Der Agent verankert sich an der Entität der Aufgabe, folgt den Beziehungen, die für diese Art von Entscheidung zählen, filtert nach Zeit und stellt ein kompaktes Briefing zusammen. Ähnlichkeitssuche behält eine Rolle an den Rändern, um Kandidaten für Belege zu finden, entscheidet aber nicht mehr, worauf das Modell achtet. Das entscheiden Struktur, Aktualität und Herkunft. Der Agent hört auf, Fragmente zu holen, und fängt an, die Punkte zu verbinden.

Fairerweise: Nicht alle halten das für nötig. Manche Teams argumentieren, dass ein fähiges Modell mit guten Suchwerkzeugen die Beziehungen bei Unternehmen unter etwa tausend Mitarbeitern zur Abfragezeit selbst ableiten kann und dass ein gespeicherter Graph teuer und berechtigungsintensiv ist. Das ist ein ernstzunehmender Einwand, und für eine Aufgabe in einem System mit geringem Risiko halte ich ihn für berechtigt. Weniger gut hält er, sobald die Aufgabe Systeme überschreitet, von Historie abhängt und sich vor einem Prüfer oder Kunden erklären muss. Es geht nicht um Mitarbeiterzahl oder Kontextlänge. Es geht darum, dass es nicht einfacher ist, bei jedem Aufruf den richtigen Kontext neu abzuleiten. Es ist nur versteckte Arbeit, schlecht gemacht, jedes Mal.

Wann reicht einfaches Memory also aus?

Die ehrliche Antwort: öfter, als die Graph-Enthusiasten zugeben, und seltener, als die Demo vermuten lässt. Drei Fragen sortieren die meisten Fälle.

• 1.Braucht die Aufgabe mehr als ein System für die Antwort?
• 2.Hängt die richtige Antwort davon ab, wann Sie fragen?
• 3.Kostet eine falsche Antwort mehr als einen neuen Versuch?

Bei einem „Ja“ hält eine Notizdatei plus Vektorindex wahrscheinlich. Bei zwei oder mehr bauen Sie einen Prototyp, kein Produkt.

Der Übergang muss kein Neubau sein. Die meisten Teams, die ich sehe, kommen schrittweise dorthin: gespeicherte Notizen mit Entität, Quelle und Datum versehen; Beobachtetes von Bestätigtem trennen; Entscheidungen als strukturierte Ereignisse statt als Prosa festhalten; dann Traversierung statt Ähnlichkeit bestimmen lassen, was in den Prompt kommt. Jeder Schritt zahlt sich aus, bevor der nächste nötig wird.

Die eigentliche Frage

Zwei Jahre lang haben wir Modelle klüger gemacht. Die nächsten Gewinne kommen daraus, bewusster zu entscheiden, worüber wir sie nachdenken lassen. Markdown-Memory und Vektorsuche waren der richtige erste Schritt, weil sie der Organisation nichts abverlangten. Der Schritt danach verlangt etwas: Beziehungen, Zeit und Entscheidungen als erstklassige Daten zu behandeln – denn daraus besteht die Arbeit.