Kein Firmen-Brain. Memory klein halten.
Fehler im Memory wiederholen sich nicht. Sie vermehren sich: Aus einem falschen Fakt wird geschlossen, und die Schlüsse werden als neues Memory zurückgeschrieben. Diesen Mechanismus nehmen wir in Ein Gedächtnis, das ein KI-Agent prüfen kann im Detail auseinander. Dieser Beitrag zieht die architektonische Konsequenz: Die Grösse eines Memory ist die Grösse seines Risikos. Die Antwort ist kein Brain, das alles weiss, sondern viele kleine, isolierte Memories, je auf einen kohärenten Use Case zugeschnitten.
Scoping verkleinert die Reichweite eines Fehlers; es macht einen Record nicht wahr. Hash oder Retrieval-Quittung können helfen, Integrität und Provenienz zu prüfen. Die fachliche Validierung bleibt ein eigener Schritt. Der aktuelle MEMA-Evidenzstatus trennt zudem öffentlichen Source, interne Implementierung und geplante Betriebsfähigkeiten.
Die verführerische Variante: ein Firmen-Brain
Der Pitch schreibt sich von selbst: alles Wissen der Firma in ein Memory, und jeder Agent kann aus allem schöpfen. Preise neben HR, Verträge neben Support-Tickets, Lohn neben der Produkt-Roadmap.
Das Problem ist derselbe Mechanismus, der Memory wertvoll macht. Ein Memory, in das alles schreibt, hat eine riesige Fläche, auf der Halluzinationen entstehen können. Ist eine drin, kann jeder Use Case, der aus dem gemeinsamen Speicher liest, sie aufnehmen, daraus schliessen und neue Fehler zurückschreiben. Ein falscher Fakt bekommt eine firmenweite Reichweite. Und weil der Speicher riesig ist, kann ihn realistisch niemand prüfen, weder ein Mensch noch ein automatischer Check.
Die robuste Variante: ein Memory je Use Case
Die Alternative leiht sich zwei alte, langweilige, bewährte Ideen aus dem Software- und dem Schiffsbau.
Die erste ist der Bounded Context: eine bewusst gezogene Grenze, innerhalb derer Begriffe eine klare Bedeutung haben und das Wissen zusammengehört. Onboarding ist ein Kontext. Preisgestaltung ein anderer. Ein Memory, das auf einen Bounded Context beschränkt ist, bleibt klein und kohärent: wenige genug Fakten, dass ein Mensch oder eine Prüfung beim Schreiben sie tatsächlich verifizieren kann.
Die zweite ist das Schott: die wasserdichte Wand zwischen den Abteilungen eines Schiffs. Eine Abteilung kann volllaufen, ohne dass das Schiff sinkt. Auf Memory übertragen: Die Zellen sind isoliert, nichts liest oder schreibt über die Wand hinweg. Kommt doch ein Fehler hinein, wird er innerhalb einer Zelle gefangen, und seine Reichweite endet an der Zellgrenze.
Nebeneinander gestellt:
- Ein Firmen-Brain: riesige Fläche, auf der Halluzinationen entstehen, firmenweite Reichweite für jeden Fehler, und zu gross, um es von Hand oder per Check zu prüfen.
- Isolierte Memories je Use Case: klein und kohärent genug, um sie wirklich zu prüfen, begrenzte Reichweite, weil ein Fehler nicht über Zellen springt, und weniger Memory, das kippen kann, also weniger, das sich aufschaukelt.
Wie man die Zellen schneidet
Die Methode hat drei Schritte, und den ersten überspringen die meisten Projekte:
- Architektur hinterfragen. Bevor irgendetwas ein Memory bekommt: Ist der Use Case selbst sauber geschnitten? Ein Memory an einem vagen Use Case erbt die Vagheit.
- Hohe Kohäsion, lose Kopplung. Innerhalb einer Zelle soll alles zusammengehören; zwischen Zellen sollen Abhängigkeiten selten und explizit sein. Dieselbe Regel, die Software wartbar macht, macht Memory prüfbar.
- Ein Memory je Bounded Context. Dann, und erst dann, bekommt jeder Use Case ein kleines, prüfbares Memory, mit eigener Governance und eigener Audit-Spur.
Memory klein zu halten ist keine Beschränkung der Ambition. Es macht Review und Eindämmung praktikabel: Mehrere abgegrenzte Stores lassen sich leichter prüfen als ein gemeinsamer Store mit firmenweiter Fehlerreichweite. Architektur und Grenzen ansehen →