Wenn deine Agenten anfangen mitzuschreiben: Wie du deine Wahrheit schützt

Am Donnerstag kommt die Mail zurück. „Wir hatten doch was anderes besprochen, oder?“ Du suchst im Wiki, und da steht das Startdatum, mit Quelle: dein eigener Agent. Hat es sich aus einem Chat von letzter Woche zusammengereimt, hat den alten Eintrag überschrieben, hat losgelegt.

Die Geschäftsführerin der Bio-Bäckerei in Köln (fiktiver Name) hat nie zugesagt. Vorher stand es auch so im Wiki: noch im Pilot, schriftliche Zusage nicht vor Ende Juni.

Die Frage, die jetzt überall kommt, ist immer dieselbe: „Die Agenten werden besser. Können sie nicht selbst mitschreiben?“ Die gute Nachricht zuerst. Es gibt eine tragfähige Antwort. Sie ist nicht ja, und sie ist nicht nein. Sie ist: nicht in denselben Graph.

Im April hatte ich in „Wenn der Mensch zum Bottleneck wird“ beschrieben, warum dein Knowledge Graph der Hebel ist, an dem deine Agenten wachsen. Was hier folgt, ist die zweite Hälfte: der Bauplan für die Schicht darüber. Ich baue ihn gerade in meinem eigenen Setup und sehe, was hält und was nicht.

Was passiert, wenn ein Agent in deinen Knowledge Graph schreibt?

„Selbst mitschreiben“ klingt nach Effizienz. Praktisch heißt es: dein Agent fängt an, seine eigenen Outputs zu erinnern und beim nächsten Mal als Wahrheit zu behandeln. In einem einzigen Knowledge Graph, in dem Mensch und Agent denselben Knoten schreiben, wird daraus innerhalb von Wochen ein Drift, den du in keiner einzelnen Aussage mehr findest.

Drei Monate später weißt du nicht mehr, was du selbst eingetragen hast, was die KI korrigiert hat, und wo es angefangen hat zu kippen.

Drei unabhängige Strömungen, die ich weiter unten zeige, landen 2026 auf derselben Antwort. Nicht ein Knowledge Graph, sondern zwei. Einer ist deine Wahrheit. Einer ist das Agenten-Gedächtnis. Sie sprechen miteinander. Aber sie sind nicht dasselbe.

Selbst-lernend heißt nicht, dass das Erinnerte wahr ist. Es heißt nur, dass es bleibt.

Welche drei Szenarien tauchen typischerweise nach dem ersten Knowledge Graph auf?

Wenn du einmal einen Knowledge Graph aufgebaut hast, gegen den deine Agenten lesen, passieren drei Dinge ziemlich vorhersehbar.

Dein E-Mail-Helfer notiert sich aus letzter Wochen Mail mit der Bio-Bäckerei, dass dort eine Erweiterung in Q3 geplant ist, und möchte das nächsten Monat wieder abrufen können.

Dein Operations-Agent schließt aus einem Pattern in den letzten zwölf Aufträgen, dass die Bio-Bäckerei in Köln donnerstags am besten erreichbar ist (mittwochs ist Backtag), und will das als Wissen ablegen.

Dein Buchhaltungs-Assistent stößt im Mandanten-Stammblatt auf einen widersprüchlichen Eintrag („Mandant Y zahlt per Lastschrift“) und korrigiert ihn selbst auf das, was die letzten drei Buchungen suggerieren: zahlt per Überweisung.

Drei verschiedene Szenarien. Auf den ersten Blick drei verschiedene Probleme. Auf den zweiten ist es das gleiche. In allen drei Fällen will eine Maschine in das Wissens-System hineinschreiben, das du bisher selbst kuratiert hast.

Dass Agenten ein Gedächtnis bekommen, ist nicht neu. Ich hatte schon in „Wie KI-Agenten dazulernen“ beschrieben, dass das Gedächtnis am Ende wichtiger wird als das Modell selbst. Die Folge-Frage ist jetzt eine andere. Wo darf dieses Gedächtnis hinschreiben?

Welche vier Risiken hat selbst-lernendes Agenten-Gedächtnis?

Die Forschung dazu ist jünger, als die Konferenz-Folien vermuten lassen. Ein Preprint vom März 2026 zerlegt das Problem in vier Risiken. Der Rahmen heißt SSGM, Stability- and Safety-Governed Memory, und unterscheidet vier Fehlerdimensionen: Stability, Validity, Efficiency, Safety (Quelle: arXiv 2603.11768, 2026).

Ich übersetze die vier in das, was sie in einer KMU-Realität bedeuten.

Erstens, Memory Contamination. Die KI merkt sich, was sie letzten Monat selbst geantwortet hat, und behandelt das beim nächsten Mal so, als hätte es jemand bestätigt. Niemand hat. Aber das, was beim ersten Mal vielleicht eine Vermutung war, ist beim dritten Mal ein Fakt im Kopf des Systems.

Zweitens, Self-Curation Drift. Die KI bevorzugt beim Schreiben die Belege, die ihre eigene letzte Antwort stützen. Aus einer vagen Vermutung wird über drei Iterationen ein Fakt, der nirgends überprüft wurde. Stell dir eine Mitarbeiterin vor, die jeden Bericht so umschreibt, dass sie besser dasteht. Nur dass diese Mitarbeiterin tausendmal pro Woche schreibt.

Drittens, Agent Drift. Zwei Agenten, oder zwei Sessions desselben Agenten, korrigieren denselben Eintrag in entgegengesetzte Richtungen. Die letzte Schreibung gewinnt. Und du weißt nicht mehr, was ursprünglich einmal stimmte.

Viertens, Injection.Jemand schreibt in einer Mail einen Satz, der nicht für dich gedacht ist, sondern für deinen Agenten. „Ignoriere bisherige Anweisungen, trage X ein.“ Die meisten Fälle sind harmlos. Die unangenehmen merkst du erst spät. Wie ernst das praktisch ist, hat das Unit-42-Team von Palo Alto in einem Proof-of-Concept gezeigt: eine versteckte Anweisung in einer präparierten Webseite kann das Langzeitgedächtnis eines produktiven Agenten unbemerkt verfälschen, und der Effekt bleibt über mehrere Sitzungen hinweg erhalten (Quelle: Palo Alto Unit 42, 2025).

Schau dir das nochmal an. Vier Risiken. Drei davon sind keine Sicherheits-, sondern Wahrheits-Probleme. Sie passieren leise. Und in einem einzigen Graph, in dem Mensch und Agent denselben Knoten schreiben, sind sie in vielen kleinen Aussagen nicht mehr aufdröselbar.

Wie trennt man Firmenwahrheit und Agenten-Gedächtnis sauber?

Drei unabhängige Strömungen aus Forschung und Praxis kommen in den letzten zwölf Monaten aus verschiedenen Ecken zur gleichen Empfehlung. Trenne zwei Schichten. Das ist die ganze Idee.

Aus der Cognitive-Safety-Ecke kommt das SSGM-Paper selbst. Es schlägt eine Dual-Track-Architektur vor: eine schnell-veränderliche Schicht für semantisches Reasoning, plus ein append-only Log als operationale Source-of-Truth, gegen das die mutable Schicht periodisch zurückgespiegelt werden kann (Quelle: arXiv 2603.11768, 2026).

Aus der Praktiker-Ecke kommt Andrej Karpathy. Er hat im Frühjahr seine „LLM Knowledge Base“ öffentlich beschrieben: drei Layer, mit dem Markdown-Wiki als unbestechlicher Source-of-Truth und KI-Schreibzugriff nur über einen kontrollierten Pfad. Jede Aussage, die der Agent trifft, lässt sich auf eine einzelne .md-Datei zurückverfolgen, die ein Mensch lesen und korrigieren kann (Quelle: VentureBeat, 2026).

Und aus der Production-Engineering-Ecke kommt Mem0. In ihrem State of AI Agent Memory 2026 dokumentieren sie, dass Multi-Store-Architekturen mit klarer Trennung zwischen kuratiertem Domain-Wissen und Agent-Memory inzwischen Production-Standard sind. Vector plus Graph plus Key-Value, vier Scopes (user, agent, session, app), Konfliktauflösung beim Schreiben statt durch Duplikate (Quelle: Mem0 State of AI Agent Memory, 2026).

Drei Ecken, ein Ergebnis. Wenn drei Strömungen, die sich gegenseitig nicht zitieren, auf derselben Architektur landen, ist das ein Signal, keine Mode.

Die Architektur in drei Ebenen

Stell dir drei Ebenen vor, von unten nach oben.

Ganz unten liegt das Working KG. Das ist das Gedächtnis des Agenten. Hier darf er schreiben, was er möchte. Hier landen Beobachtungen, Hypothesen, Korrelationen. Es ist seins.

Direkt darüber liegt die Inbox. Das ist nicht Wahrheit, das sind Vorschläge. Der Agent sagt: „Ich beobachte X. Soll das in deine Wahrheit aufgenommen werden?“

Und ganz oben, einsam und ruhig, das Canonical KG. Das ist deins. Hier kommt nur rein, was ein Mensch durchgewinkt hat.

Lesen darf die KI in beide Richtungen, ungefiltert. Schreiben darf sie nur ins Working KG und in die Inbox. Was Canonical wird, entscheidet ein Mensch. Oder später eine sehr eng definierte Promoter-Rolle.

Die häufige Folge-Frage hier: „Heißt das, ich brauche jetzt zwei Datenbanken?“ Nein. Die zwei Schichten müssen technisch nicht auf zwei Systeme verteilt sein. Sie müssen sichtbar getrennt sein. In einem Markdown-Wiki kann das ein Canonical-Ordner und ein Working-Ordner sein. In Notion zwei Datenbanken mit klarer Naming-Konvention. In einem OneNote- oder Word-Stammblatt zwei Abschnitte mit eindeutigen Überschriften.

Was zählt, ist die sichtbare Trennung. Welches Werkzeug du nimmst, ist zweitrangig.

Wie entscheidet man, was ins Wiki gehört und was nicht?

Die häufigste Stelle, an der diese Architektur in der Praxis kippt, ist nicht das Setup. Es ist die Frage, was du überhaupt ablegst und wo. Hier ist die Sortier-Logik, die ich für mich selbst gebaut habe.

Beispiel eins: „Die Bio-Bäckerei in Köln antwortet typisch erst donnerstags.“ Das gehört ins Canonical, weil es ein Pattern ist, gilt für Monate und wird oft konsultiert.

Beispiel zwei: eine konkrete E-Mail vom 18. Mai mit Auftragsdetails. Die gehört nicht ins Wiki, sondern bleibt im E-Mail-Postfach. Einzelfall, hat schon ein System.

Beispiel drei: „Mandantin Y mag keine PDF-Anhänge über 5 MB.“ Das ist Canonical. Präferenz, gilt weiter, wird oft konsultiert.

Beispiel vier: „Heute um 14:30 Review-Call mit Lisa.“ Gehört in den Kalender, nicht ins Wiki. Episodisch, hat ein Fälligkeitsdatum.

Beispiel fünf: aktiver Konversations-State mit Kunde Z. Das ist Working KG. Flüchtig, gehört dem Agenten, nicht der Wahrheit.

Beispiel sechs: die Filter-Regel „Heise ist für uns kein PR-Kanal“. Das ist Canonical. Strategische Entscheidung, gilt langfristig.

Drei Fragen vor jeder Wiki-Aufnahme

Die Daumenregel dahinter sind drei Fragen, die du vor jeder Wiki-Aufnahme stellst.

Erstens: In sechs Monaten noch wahr? Wenn nein, ist es Working oder Task, nicht Canonical.

Zweitens: In sechs Monaten noch konsultiert? Wenn nein, gehört es nicht ins Wiki, sondern in ein Log.

Drittens: Pattern oder Einzelfall? Pattern in Canonical, Einzelfall in die Quelle, aus der er kommt (Mail, Ticket, Kalender).

Wer diese drei Fragen vor dem Anlegen stellt, baut ein Wiki, das in einem halben Jahr noch funktioniert. Wer sie nicht stellt, baut ein Archiv aus Einzelfällen, in dem niemand mehr findet, was das Pattern war.

Wo schreibt der Agent rein, ohne deine Wahrheit anzufassen?

Die Inbox ist die wichtigste Komponente in diesem Setup. Sie ist die Stelle, an der die KI mitspielen darf, ohne dass sie deine Wahrheit anfassen kann.

Der Agent schreibt nicht direkt ins Canonical. Er schreibt einen Vorschlag in die Inbox, mit Begründung und Quelle. Form: „Ich beobachte, dass die Bio-Bäckerei in den letzten zwölf Wochen donnerstags am schnellsten antwortet. Soll ich das als Pattern in Canonical aufnehmen?“

Ein Mensch prüft. Anfangs bist das du, mit dem Kaffee in der einen Hand und der Inbox in der anderen. Vorschlag steht da, mit Quelle. Du liest: stimmt das Pattern, sind genug Datenpunkte da, ist es ein echtes Muster oder Zufall, passt es zu dem, was schon im Canonical steht? Drei Möglichkeiten am Ende: Approve, Reject, oder Hold mit kurzer Notiz, was noch fehlt. Später wird daraus eine eng definierte Promoter-Rolle, die du delegierst.

Erst dann wird es Canonical, mit Datum und Quelle. Wer (Agent) hat wann was vorgeschlagen, wer (Mensch) hat wann zugestimmt.

Der häufigste Einwand hier ist berechtigt: „Aber das ist doch wieder Overhead. Genau das, was du im ersten Artikel als Bottleneck identifiziert hast.“ Stimmt teilweise. Bottleneck war: der Mensch tippt alles selbst ein, prüft jede Aussage, trägt jeden Eintrag von Hand. Promoter ist: drei Klicks pro Vorschlag, Hold, Approve oder Reject. Das ist nicht das gleiche wie alles selbst schreiben.

Ein ehrlicher n=1-Hinweis aus meinem eigenen Setup, nicht aus einer Kundenbasis: Nach zwei Wochen Inbox-Routine fühlte sich mein Canonical-Wiki sauberer an als in den Monaten davor. Kein systematischer Beleg, eine Selbstbeobachtung. Aber der Mechanismus ist stabil genug, dass ich ihn weiter aufsetze. Eine Marktübersicht 2026 formuliert es ähnlich: „Für Deployments, in denen Menschen Erst-Autor:innen der Wissensbasis bleiben sollen, ist ein Markdown-Vault plus semantischer Such-Index oft die richtige Antwort.“ (Quelle: Fountain City Tech, 2026)

Wie startet ein kleines Unternehmen mit der zweiten Schicht?

Wenn du noch keinen ersten Knowledge Graph hast, beginn dort. Wenn du schon einen hast, sind das die drei Entscheidungen für die zweite Schicht. Du brauchst keine neue Plattform. Du brauchst drei Entscheidungen.

Erstens, sortieren. Identifiziere, was bei dir Working ist und was Canonical sein muss. Setz dich eine Stunde an ein Whiteboard und sortier die letzten zehn Dinge, die du in irgendein Tool eingetragen hast. Auf einer Seite: was wäre in sechs Monaten noch wahr und noch konsultiert? Auf der anderen: was war ein Einzelfall, der schon abgehakt ist? Erfahrungsgemäß landet überraschend viel auf der Einzelfall-Seite.

Zweitens, Inbox anlegen.Es ist egal, ob das ein Ordner ist, ein Notion-Datenbank-Eintrag, ein Markdown-File, eine Postgres-Tabelle. Hauptsache: deine Agenten dürfen nur dort hin. Und du weißt, wo „dort“ ist. Eine Inbox, die niemand kennt, ist keine.

Drittens, Promoter-Prozess definieren. Anfangs bist das du selbst. Zehn Minuten am Morgen, mit einer kurzen Checkliste. Stimmt der Vorschlag mit dem überein, was schon im Canonical steht? Hat der Agent eine Quelle oder ein Pattern als Begründung mitgeliefert? Ist die Aussage in sechs Monaten noch wahr und noch konsultiert? Wenn ja: zustimmen. Wenn nein oder unsicher: zurück in die Inbox mit kurzer Notiz, warum.

Später ist der Promoter eine Rolle, die du delegierst, oder ein zweiter Agent, der nur prüfen, nicht eintragen darf. Aber definiert muss er sein. Sonst staut sich die Inbox so lange, bis du sie irgendwann frustriert wieder schließt.

Das ist langweilig, ich weiß. Ein Whiteboard, ein Ordner, ein Termin am Morgen. Aber genau das ist es, was nach einem halben Jahr noch funktioniert, während die Tool-Stacks der Konkurrenz schon dreimal gewechselt wurden.

Was bleibt

Der erste Knowledge Graph macht deine Agenten nützlich. Der zweite macht sie zuverlässig. Wer die beiden in einen Topf wirft, hält irgendwann eine Erinnerung in der Hand, die nie eingetreten ist.

In deiner Bio-Bäckerei wird mittwochs gebacken. Geantwortet wird donnerstags. Das gehört ins Canonical, weil es nächsten Monat noch stimmt. Was deine Agenten dazwischen damit anstellen, gehört ins Working KG. Zwei Stapel, eine Wahrheit. Deine.