## Die Datenbankauswahl, die schlecht altert

Ein Unternehmen baut einen Agenten für die Kundenbetreuung auf. Es speichert Beobachtungen in einer Datenbank, Postgres, Mongo, Redis, was auch immer das Team bereits betreibt. Monate später erstellt ein anderes Team einen Agenten für die Kontogesundheit. Jemand verbindet sie, weil ein Mensch es satt hat, den Kontext zwischen Tools zu kopieren und einzufügen. Diese Verbindung, eine gemeinsam genutzte Datenbanktabelle, wird versehentlich in den gemeinsam genutzten Zustand mehrerer Agenten versetzt.

Drei Agenten teilen jetzt den Status zu Kundenkonten: eingehender Support, Gesundheitsbewertung und Verlängerungsempfehlungen.

Der Support-Mitarbeiter bearbeitet einen frustrierten Kunden und speichert: „Der Kunde äußerte seine Unzufriedenheit mit der Preisgestaltung und erwog Alternativen.“ Der Gesundheitsbewertungsagent liest dies und stuft das Konto herab. Der Erneuerungsagent liest die herabgestufte Punktzahl, generiert und sendet ein Rabattangebot. Alles innerhalb weniger Minuten. Kein Mensch auf dem Laufenden.

Die erste Beobachtung des Supportmitarbeiters war falsch. Der Kunde war frustriert über einen Abrechnungsfehler, nicht über die Preisgestaltung. Aber die LLM-vermittelte Speicherextraktion komprimierte die Interaktion zu einer irreführenden Zusammenfassung, und diese Zusammenfassung verbreitete sich über den gemeinsamen Zustand als Grundwahrheit.

Das Abrufen funktionierte bei jedem Schritt. Der Fehler lag im Schreiben. Nichts im System konnte erkennen, dass die ursprüngliche Beobachtung ihrer Quelle nicht treu war, oder die Kausalkette vom fehlerhaften Schreiben bis zur fehlerhaften Aktion nachvollziehen.

## Warum Single-Agent-Systeme das Problem verschleiern

Wenn ein Agent in einen Speicherspeicher schreibt, beeinträchtigt die Schreibbeschädigung die Qualität langsam. Der Agent fasst eine Beobachtung leicht falsch zusammen. Es überschreibt ein Entitätsattribut. Es speichert widersprüchliche Fakten. Das System funktioniert immer noch. Es wird nur allmählich weniger zuverlässig. Der Speicherschicht wird nie die Schuld gegeben, da der Fehlermodus wie ein LLM-Problem aussieht.

Hier ist heute fast jeder. Der Schmerz ist latent. Niemand kann grundlegende Fragen beantworten: Was hat der Agent wann und aus welcher Quelle gelernt, widerspricht er etwas, das er letzte Woche gespeichert hat? Aber das System bricht nicht sichtbar zusammen. Das Vertrauen schwindet auf subtile Weise.

## Was ändert sich bei mehreren Agenten?

Wenn Agent A Beobachtungen schreibt, die Agent B liest und auf die er reagiert, entsteht eine andere Fehlertopologie.

**Widerspruchsverstärkung.** Zwei Agenten speichern widersprüchliche Fakten über dieselbe Entität aus unterschiedlichen Interaktionen. Ein dritter Agent trifft ein, um Maßnahmen zu ergreifen, und sieht, welche Tatsache auch immer die Abrufschicht ans Licht bringt, ohne dass eine Grundlage für eine Entscheidung zwischen ihnen besteht. Ohne ein nur angehängtes Beobachtungsprotokoll mit Zeitstempeln und Quellenangabe gibt es keinen forensischen Weg, den Widerspruch zu verstehen.

**Stille Überschreibkaskaden.** Agent A aktualisiert einen Datensatz. Agent B schreibt mit einem veralteten Lesevorgang sein eigenes Update, das implizit die Änderung von Agent A rückgängig macht. In einer veränderlichen Datenbank ist dies nahezu nicht erkennbar. In einem Nur-Anhang-Protokoll mit Hash-verknüpften Beobachtungen ist dies strukturell unmöglich.

**Zusammenbruch der Vertrauensgrenze.** Gemeinsamer Status bedeutet, dass jeder Agent den Schreibvorgängen des anderen vertraut. Agenten verfügen jedoch über unterschiedliche Fähigkeiten, Eingabeaufforderungskontexte und Fehlerprofile. Ein spezialisierter Finanzanalyseagent und ein Allzweck-Supportagent sollten wahrscheinlich nicht die gleiche Schreibberechtigung für denselben Entitätsstatus haben. In einer flachen Datenbank ohne Schemaeinschränkungen, wer was schreiben darf, tun sie dies.

## Die vier Phasen

Die Branche durchläuft einen vorhersehbaren Bogen.

### 1. „Verwenden Sie einfach Postgres“ (oder [verwenden Sie einfach eine Markdown-Datei](/posts/the-markdown-memory-ceiling))

Manus, Claude Code und OpenClaw verwenden alle reine Textdateien als Speicher. Konvergente Evolution, kein gemeinsames Spielbuch. Wenn ein Team nach einer Datenbank greift, wird der Speicher an das gebunden, was bereits vorhanden ist: RAG über Postgres mit pgvector, Redis für den Sitzungsstatus, Einbettungen in Pinecone. Für einfache Anwendungsfälle funktioniert jeder Pfad. Das mentale Modell besagt, dass Agenten sich Dinge merken müssen, Dateien oder Datenbanken Dinge speichern, wenn das Problem gelöst ist.

### 2. Abrufoptimierung

Produkte wie Mem0, Zep und MemPalace akzeptieren, dass Agenten eine dedizierte Speicherabstraktion benötigen, beschreiben das Problem jedoch als Abrufqualität. Wie man den richtigen Kontext zur richtigen Zeit in die Eingabeaufforderung einfügt. Dies löst ein Problem, das Entwickler bereits spüren: schlechter Rückruf, aufgeblähte Kontextfenster, irrelevante Abrufe. In dieser Phase bleibt der Schreibpfad jedoch ungeprüft. Was auch immer das LLM extrahiert, wird als Grundwahrheit behandelt.

Diese Phase wird in den nächsten ein bis zwei Jahren dominieren, da der Apportierschmerz lesbar ist. Entwickler bemerken, wenn der Agent das Falsche vergisst oder abruft. Schreibfehler sind unleserlich. Der Agent handelt selbstbewusst bei einem schlechten Zustand und niemand merkt es, bis die nachgelagerten Konsequenzen ans Licht kommen.

### 3. Die Vertrauenskrise

Dies geschieht, wenn Agenten von einfachen Assistenten zu hochkarätigen Akteuren werden, die Geld verwalten, Beschaffungsentscheidungen treffen, Compliance-Workflows abwickeln und über Tage oder Wochen autonom agieren. Die Frage verlagert sich von „Hat der Agent das Richtige abgerufen?“ zu „Kann ich beweisen, was der Agent wusste, wann er es wusste und ob dieses Wissen legitim war?“

Auffällige Ausfälle, bei denen Agenten auf einen beschädigten Speicherstatus reagierten, werden diese Verschiebung erzwingen. Unternehmenskäufer werden Prüfprotokolle verlangen. Regulierungsbehörden im Finanz- und Gesundheitswesen benötigen eine deterministische Herkunft.

### 4. Die Gabelung

Die Branche spaltet sich. Pfad A: Vorhandene Datenbanken fügen Agentenprimitive hinzu. Postgres erhält Erweiterungen für die Beobachtungsprotokollierung und die Entitätsauflösung. Supabase oder PlanetScale liefern eine Produktschicht „Agentenspeicher“. Dies erfasst viele Anwendungsfälle, bei denen die Vertrauensanforderungen moderat sind.

Pfad B: speziell entwickelte Agenten-Status-Infrastruktur für Agenten, die über Vertrauensgrenzen hinweg arbeiten, einen langfristigen autonomen Status aufrechterhalten oder eine kryptografische Herkunft benötigen. Die wichtigsten Invarianten (nur Anhängen, Hash-verknüpft, schemabeschränkt, deterministische Entitätsauflösung) sind architektonische Verpflichtungen, die nicht zuverlässig als Datenbankerweiterungen nachgerüstet werden können.

Auf diesem Weg entfalten Agentensysteme ihr volles Potenzial. Agenten, die ihrem eigenen Zustand vertrauen, ihre eigenen Überlegungen verfolgen und sich ohne stille Korruption mit anderen Agenten koordinieren können, sind qualitativ leistungsfähiger als Agenten, die mit Best-Effort-Speicher arbeiten.

Die Schreibintegrität ist keine nachträglich eingebaute Sicherheitsfunktion. Es ist die Grundlage, die den autonomen Betrieb ermöglicht.

## Wie Multiagentensysteme tatsächlich aufgebaut werden

Die meisten werden nicht als Multiagentensysteme konzipiert sein. Sie werden sich vermehren.

**Hub-and-Spoke mit einem menschlichen Hub** ist das derzeit vorherrschende Muster. Ein primärer Agent steht dem Benutzer gegenüber und delegiert Unteraufgaben an spezialisierte Agenten. Der freigegebene Status ist das Kontextfenster des primären Agenten. Das Risiko der Schreibintegrität ist gering. Diese Topologie hat jedoch eine harte Obergrenze: Der Hub-Agent hat Engpässe und kann den Kontext über lang laufende Arbeitsabläufe hinweg nicht aufrechterhalten. Dies entspricht den Phasen 1 und 2: „Einfach Postgres verwenden“ oder eine Abrufebene funktioniert einwandfrei, da ein Agent den Status steuert.

Als nächstes kommen **Pipeline-Agenten**. Sequentielle Übergaben, bei denen jeder Agent ein Arbeitselement verarbeitet und anreichert. Führen Sie die Qualifizierung von der Unternehmensrecherche über die Ausarbeitung von Outreach-Maßnahmen bis hin zur Besprechungsplanung. Hier kommt es auf die Schreibintegrität an. Wenn der Research-Agent falsche Unternehmensdaten speichert, kalibriert jeder nachgelagerte Agent falsch. Hier beginnen die Teams, von Phase 2 in Phase 3 zu gleiten: Der Abruf funktioniert immer noch, aber unter der Oberfläche baut sich eine Vertrauenskrise auf.

**Ereignisgesteuerte Agenten mit gemeinsamem Kontext** folgen. Mehrere Agenten abonnieren Ereignisse aus einer gemeinsamen Umgebung (CRM, Codebasis, Kommunikationskanal), behalten ihre eigenen Perspektiven bei und schreiben Beobachtungen zurück in einen gemeinsamen Speicher. Kein Orchestrator. Dies ist Phase 3 in vollem Umfang: gleichzeitige Schreibvorgänge von Agenten mit unterschiedlichen Interpretationsrahmen, kein Koordinator, der Widersprüche erkennt, und die Schreibintegrität wird wirklich gefährlich.

**Persistente autonome Agenten mit Langzeitstatus** sind der Endstatus. Agenten laufen kontinuierlich, pflegen sich entwickelnde Weltmodelle und synchronisieren sich regelmäßig mit anderen Agenten oder einem gemeinsamen Wahrheitsspeicher. Kontextfenster können nicht als Speicher dienen. Diese Agenten benötigen einen dauerhaften Speicher mit echten Integritätsgarantien. Dies ist Phase 4: die Gabelung. Entweder ist Ihre Infrastruktur dafür ausgelegt oder nicht.

Ein Hauptproblem besteht darin, dass viele Entwickler ihren Speicher für die Topologien eins und zwei wählen, bei denen das Shared-State-Risiko gering ist. Sie wählen die Datenbank aus, die sie bereits haben, und fügen eine Speichertabelle hinzu. Wenn sie die Topologien drei und vier erreichen, sind die architektonischen Verpflichtungen fest verankert. Die Migration vom veränderlichen in den Nur-Anhängen-Zustand ist kein Bibliothekswechsel. Es ist eine Neuarchitektur.

## Die Integrationsoberfläche, auf die es ankommt

Die erfolgreiche Architektur besteht wahrscheinlich nicht darin, „Ihre Datenbank zu ersetzen“, sondern „zwischen Ihren Agenten und Ihrer Datenbank zu sitzen“.

Agenten schreiben Beobachtungen in eine Schreibintegritätsschicht: nur anhängen, schemabeschränkt, herkunftsverfolgt. Diese Ebene verwaltet den vom Agenten lesbaren Status. Die bestehende Datenbank des Entwicklers bleibt das Aufzeichnungssystem für Geschäftsdaten, Kundendatensätze, Transaktionen und Produktkataloge. Aber der vom Agenten generierte Zustand, Beobachtungen, Schlussfolgerungen, Entitätsauflösungen und Entscheidungen leben in einer speziell dafür geschaffenen Schicht.

In der Praxis kommunizieren die beiden Schichten miteinander. Ein Agent liest einen Kundendatensatz aus Postgres, führt eine Analyse durch und schreibt seine Beobachtungen (Gesundheitsbewertung, Abwanderungsrisiko, empfohlene Maßnahmen) mit einem Verweis zurück auf den Quelldatensatz in die Schreibintegritätsschicht. Ein zweiter Agent fragt die Integritätsschicht nach allen Beobachtungen zu diesem Kunden ab, erhält einen konsistenten Schnappschuss mit Herkunft und reagiert darauf. Wenn etwas schief geht, verfolgen Sie die Kette: Welcher Agent hat was wann geschrieben, basierend auf welchen Quelldaten? Die Geschäftsdatenbank wird niemals durch vom Agenten generierte Zustände verunreinigt, und die Agentenschicht verliert nie den Überblick darüber, woher ihre Beobachtungen stammen.

Die Unterscheidung zwischen „von Menschen geschriebenen Geschäftsdaten“ und „von Agenten geschriebenen Beobachtungsdaten“ ist der klarste Rahmen dafür, warum eine neue Datenschicht erforderlich ist. Sie ersetzen nicht ihre Datenbank. Sie fügen eine Ebene für eine Datenkategorie hinzu, die nicht existierte, bevor Agenten mit dem autonomen Schreiben begannen.

## Was ich baue

Das ist es, was [Neotoma](https://github.com/markmhendrickson/neotoma) tut. Nur anhängende Beobachtungen. Hash-verknüpfte Herkunft. Schemabeschränkte Schreibvorgänge. Deterministische Entitätsauflösung. Jede Beobachtung, die ein Agent schreibt, ist vom ersten Tag an nachvollziehbar, überprüfbar und konsistent.

Ich habe damit meinen eigenen Agenten-Stack laufen lassen. Mehrere Agenten (E-Mail-Triage, Aufgabenverwaltung, Finanzen, Inhaltsplanung), die alle an denselben Shop schreiben. Das Multi-Agent-Shared-State-Problem ist für mich nicht hypothetisch. Es ist das, worauf ich jede Woche stoße, wenn die Extraktion eines Agenten im Widerspruch zu der eines anderen steht oder wenn ein veralteter Lesevorgang eine nachgelagerte Aktion bei einem fehlerhaften Zustand auslöst.

Die Kosten für das Warten auf die Einführung der Schreibintegrität sind keine technischen Schulden, die Sie später abbezahlen können. Es handelt sich um eine Lücke in Ihrem Prüfungsverlauf. Alles vor der Migration ist eine Black Box. Diese Lücke ist dauerhaft.