Kleine Verzögerung bei diesem letzten Teil der 19-Systeme-Reihe, aber besser spät als nie.
Die sechs universellen Muster in den 19 Systemen, die ich durchgearbeitet habe, sind das Rückgrat dieser Reihe. Qualitätsinvestition zur Schreibzeit. Herkunftsnachweis, der mit der Tatsache reist. RRF-fusionierte hybride Retrieval. Abgestufte Speicherung mit hitzebasierter Promotion. Explizite Kontextbudgets. Tools-nicht-Injektionen an der Agentenoberfläche. Jedes hat seinen eigenen Artikel verdient, weil drei oder mehr Systeme unabhängig voneinander zur gleichen Disziplin gelangt sind.
Die universellen Muster hören hier auf. Von dort beginnen die aufkommenden.
Dieser Artikel handelt von acht Mustern, die unterhalb der Schwelle liegen, in einem oder vielleicht zwei Systemen vorkommen, bei denen die Implementierung so eindeutig ein echtes Problem adressiert, dass es schwer zu glauben ist, dass sie selten bleiben. Sieben kommen in genau einem System vor. Eines kommt in zweien vor und ist eine Adoption davon entfernt, zu graduieren. Das erste wird am tiefsten behandelt, weil es das wichtigste ist.
Früh zu sein bedeutet, dass einige davon nicht universell werden. Zu spät zu sein ist schlimmer: Du baust 2026 ein System, das ohne Speicherschicht-Autorisierung ausgeliefert wird, weil eine Synthese es als einmalige Eigenheit bezeichnet hat, und 2027 bekommst du eine Prompt-Injection-Demo auf Hacker News.
Die Speicher-Engine ist die einzige Autorität, die hält
Im vorherigen Artikel wurde argumentiert, dass der Agent die Tools halten sollte. Gib ihm ein SQL-Tool, und die Frage wird sofort aktuell: Was hindert ihn daran, die Tabelle zu abzufragen, die er nicht abfragen sollte?
Die naiven Ansätze sind ausgetreten und alle falsch.
Prompt-Level-Anweisung: "Du darfst die Tabelle 'conversations' nicht lesen." Funktioniert gegen ein kooperatives Modell. Scheitert gegen jedes Modell, das die Anweisung falsch liest, entscheidet, dass das Verbot nicht für seine aktuelle Aufgabe gilt, oder unter einem Jailbreak läuft.
Anwendungs-Level-Filter: Das sql_query-Tool wrapt das SQL des Modells, parst es auf verbotene Tabellenreferenzen, lehnt die Abfrage ab, bevor sie an die Datenbank weitergegeben wird. Funktioniert gegen ein naives Modell. Scheitert gegen jedes Modell, das Tabellennamen in Anführungszeichen setzt, ATTACH verwendet, einen Parsing-Unterschied zwischen dem Wrapper und der Datenbank ausnutzt oder über eine anderswo definierte View routet.
Nur ORM-vermittelter Zugriff: Der Agent berührt nie rohes SQL, er ruft typisierte Methoden auf. Funktioniert, bis das System ein Debugging-Tool, ein Analyse-Tool, ein Migrationstool oder eine "lass den Agenten zwei Tabellen joinen"-Funktion bekommt, woraufhin die Regel bricht und die Fehlerhaftigkeit unbemerkt bleibt.
Klar gesagt: Keines davon ist Durchsetzung. Es sind Hinweise. Ein System, das echte Sub-Agenten-Isolation will, muss die Speicher-Engine selbst bitten, den Lesevorgang zu verweigern, nicht die Schicht darüber. Dies ist die Disziplin, die die capability-basierte Sicherheit Betriebssystemressourcen auferlegt: Der Kernel sagt nein, nicht die Anwendung. Es ist auch die Disziplin, die PostgresSQLs Row-Level Security Multi-Tenant-SaaS auferlegt: Die Policy lebt in der Datenbank, nicht im ORM, weil "der Ingenieur, der den neuen Mikroservice gebaut hat, vergessen hat, den Tenant-Filter anzuwenden" eine Bug-Klasse ist, die nur eine Speicher-Engine-Policy ausschließen kann.
second-brain ist das erste funktionierende Beispiel im Korpus. Seine bereichsbezogene Datenbank hat drei Schichten, jede notwendig, keine allein ausreichend.
Eine frische In-Memory-SQLite-Verbindung pro bereichsbezogenem Agenten. Der Konstruktor öffnet :memory: und hängt die echte Datenbank im Read-Only-Modus an. Die Verbindung des Agenten hat kein echtes Hauptschema, es gibt nichts zu lesen außer dem, was die nächste Schicht dort ablegt.
TEMP VIEWs im Hauptschema, die auf erlaubte Tabellen in der Quelle umleiten. Die View-Definitionen kommen aus dem Profil des Agenten und können Spalten-Level-Redaktion oder Zeilen-Level-Filter kodieren. Ein View-Name-Validator verhindert die Einschleusung bösartiger Tabellennamen durch das Profil.
Ein SQLite-C-API-Authorizer-Hook, der jedes Lesen des Quellschemas verweigert, das nicht durch eine View geht. Der Hook feuert für jeden Lesevorgang, den SQLite ausführen wird, bevor der Optimierer überhaupt den Tabellennamen auflöst. Ein Lesevorgang innerhalb eines View-Bodys ist erlaubt, die View ist der Bereichsfilter. Ein Lesevorgang auf oberster Ebene wird gegen die Menge der View-Namen geprüft, die der Bereich erstellt hat. Jedes Lesen des Quellschemas direkt wird ohne Ausnahme verweigert.
Das LLM kann jedes SQL schreiben, das es will. Es kann Tabellennamen in Anführungszeichen setzen, UNION verwenden, ATTACH verwenden, die gesamte Grammatik von SQLite nutzen. Es kann nicht erfolgreich eine Zeile aus einer Tabelle lesen, die nicht in der Allowlist steht, weil der Authorizer den Lesevorgang auf der C-Ebene abfängt, bevor der Tabellenname aufgelöst wird. Der Anwendungs-Level-Filter ist umgehbar. Die Speicher-Engine-Autorisierung ist es nicht.
Etwa 50 Zeilen stdlib Python. Keine zusätzliche Abhängigkeit, kein zusätzlicher Prozess, kein Schema-Migration. Der Overhead pro Abfrage ist ein C-Callback pro Lesevorgang, unsichtbar gegenüber den Kosten der Abfrage selbst. Das Muster komponiert sauber mit allem anderen: Das Tool-Register des Agenten kann immer noch feature-gated sein, die View-Definitionen können immer noch Spalten-Level-Redaktion kodieren, der Gesprächsverlauf kann immer noch zur Schreibzeit redigiert werden. Keine dieser Schichten wird durch die Durchsetzung auf Speicher-Engine-Ebene geschwächt. Sie werden dadurch gestärkt.
Der Rahmen ist wichtig. Jedes andere Sicherheitsmuster in den 19 Systemen ist ein Hinweis. Die Speicher-Engine ist die Autorität.
Drei weitere, die eine Erwähnung wert sind
Async-Cleanup-Race-Schutz (llm-wiki)
Hintergrundspeicherwartung ist grundsätzlich racy mit Aktionen des Benutzers im Vordergrund. Ein Sweep, der gegen Projekt A gestartet wurde und gegen Projekt B beendet wird, hat beide korrumpiert. Es hat A's Entscheidungen in B's Review-Speicher verschoben oder B's Elemente als gelöst markiert, basierend auf A's Daten. Dies ist eine Bug-Klasse, die leicht einzuführen, schwer zu erkennen und unmöglich sauber zu beheben ist, weil der korrumpierte Zustand legitim aussieht.
llm-wiki führt eine zweistufige Hintergrund-Review-Schleife aus und überprüft an jedem Yield-Punkt zwei Race-Schutz-Signale: ein Abbruchsignal, das vom Projektwechsel-Handler ausgelöst wird, und einen Pfadvergleich mit dem aktuellen Projekt im UI-Store. Wenn eine der Prüfungen fehlschlägt, kehrt der Sweep mitten im Flug zurück, ohne Entscheidungen anzuwenden. Der Projektwechsel-Handshake auf der Queue-Seite vervollständigt das Bild: Er spült den Zustand des aktiven Projekts auf die Festplatte, bevor er den Speicher löscht, stellt verarbeitete Elemente wieder auf "ausstehend" zurück, bricht sowohl den laufenden LLM-Aufruf als auch das laufende Sweep-Urteil ab, und schreibt erst dann in den Pfad des pausierten Projekts.
Das Meta-Muster ist die Erkenntnis: deterministisch, wo du kannst, LLM, wo du musst, überall abbrechbar. Die zweistufige Struktur hält das LLM aus Fällen heraus, die einfache Existenzprüfungen erledigen können. Der Race-Schutz hält beide Stufen abbrechbar. Die Kombination ist eine Vorlage für jede Hintergrundspeicherwartungsschleife in jedem System.
Der automatisch degradierte No-Op-Konstruktor (graymatter)
Das API-Design von Bibliotheken hat eine wiederkehrende Spannung. Das einfachste "Hallo Welt" will, dass die Bibliothek einfach funktioniert, eine Zeile zum Konstruieren, eine zum Aufrufen. Die defensivste Produktionshaltung will, dass sie beim Konstruieren laut scheitert, mit einem strukturierten Fehler, den der Aufrufer nicht ignorieren kann.
graymatter wählt "fail-silent", aber mit einer Disziplin, die den Trade produktiv macht. Der Konstruktor gibt nie einen Fehler zurück. Wenn die Initialisierung fehlschlägt, bbolt gesperrt ist, das Datenverzeichnis nicht beschreibbar ist, der Vektor-Store nicht geöffnet werden kann, loggt es nach stderr und gibt einen degradierten Memory zurück, dessen Methoden alle No-Ops sind. Produktionsaufrufer überprüfen via Healthy(), bevor sie dem Handle vertrauen. Die Bibliothek ist go get-bar, in drei Zeilen importierbar und funktioniert in der Demo. Healthy() ist die Produktionsdisziplin-Steuer.
Das Muster macht die Bibliothek sicher in Agenten-Harnischen einzubetten, die ihre eigene Startzeremonie haben. Ein Agenten-Harnisch, der graymatter.New(...) während des Bootens aufruft, den Fehlerpfad ignoriert, weil es keinen Fehlerpfad gibt, und fortfährt, bekommt eine funktionierende Speicherschicht im Happy Path und einen No-Memory-Fallback, wenn das Datenverzeichnis schreibgeschützt ist. In beiden Fällen bootet der Harnisch. Das ist eine spezifische Art von defensiver Komposition, die "fail-loud"-Konstruktoren ohne explizite Fehlerbehandlung an jeder Einbettungsstelle nicht bieten können.
Schattenmodus-Duplikaterkennung (mem9)
Jedes System, das Duplikatunterdrückung ausliefert, muss einen Cosinus-Ähnlichkeitsschwellwert wählen. Über 0,95 ist fast sicher ein Duplikat. Unter 0,7 ist es fast sicher nicht. Der Raum dazwischen ist umstritten, und der richtige Schnitt hängt vom Einbettungsmodell, der Domäne, der Abfrageverteilung und den Kosten von falsch Positiven gegenüber falsch Negativen in diesem speziellen System ab.
Die Versuchung ist überwältigend, einen auf Basis von Intuition zu wählen und auszuliefern. mem9 tut das nicht. Es führt die Duplikaterkennungsabfrage für jede Tatsache aus, zeichnet den Cosinus-Score in einem Prometheus-Histogramm auf und ergreift keine Maßnahme. Der Schwellwert wird hinausgezögert, bis Produktionsdaten ihn rechtfertigen. "Liefere die Beobachtung aus, nicht die Heuristik."
Die gleiche Logik gilt für jede mit Schwellwert versehene Entscheidung in jedem Speichersystem. Rerank-Schwellwert. Recall-Konfidenz-Cutoff. Tier-Promotion-Hitzegrenze. Insight-Merge-Ähnlichkeitsgrenze. Die meisten Systeme in den 19 liefern diese Werte geschätzt aus. mem9 liefert mit dem Wert verzögert aus. Die Disziplin ist selten und das Ergebnis ist besser.
Vier weitere, enger gefasst
Physische Datenbankisolation pro Mandant (mem9).
Anstelle eines WHERE tenant_id = ?-Filters auf einem gemeinsamen Store provisioniert mem9 einen separaten TiDB-Cluster pro Mandant über TiDB Zero. Isolation ist auf Speicher-Engine-Seite. Die Anwendung kann nicht versehentlich über Mandanten hinweg abfragen, weil es keinen gemeinsamen Store zum Abfragen gibt. Es ist eine grobkörnigere Version desselben Endzustands wie die Speicherschicht-Autorisierung: Isolation, die auf der Engine durchgesetzt wird, nicht auf der Anwendung. Die Infrastrukturkosten, die dies historisch unpraktisch machten, sind weg. TiDB Zero auto-provisioniert. Neon macht dasselbe für PostgreSQL. Cloudflare D1 macht dasselbe für SQLite.
Quell-Gesprächsrunde-Dekoration mit explizitem Kontextbudget (mem9).
Ein abgerufener Speicher ist ein String. "Benutzer bevorzugt Postgres." Korrekt, knapp, unmöglich ohne Kontext zu verankern. mem9 hängt die ursprünglichen Gesprächsrunden als Dekoration an, bewertet gegen die Abfrage und gedeckelt durch ein Budget-Tripel: Mindestpunktzahl, Limit pro Speicher, Gesamtlimit. Der Agent, der "Benutzer bevorzugt Postgres" liest, bekommt die Runde, in der der Benutzer sagte: "Wir haben MongoDB ausprobiert, aber die Joins haben uns umgebracht, also bin ich letztes Quartal zu Postgres gewechselt." Kein zweiter Tool-Aufruf erforderlich. Die Verankerung liegt im Ergebnis. Die Voraussetzungen sind bereits universell: Herkunft plus hybrides Retrieval. Die meisten Systeme in den 19 könnten dies in zwei Tagen implementieren.
purpose.md als vierte Datei (llm-wiki).
Das Karpathy-LLM-Wiki-Muster hat drei kanonische Dateien: rohe Quellen, das Wiki-Arbeitsset und schema.md für strukturelle Regeln. llm-wiki fügt eine vierte hinzu: purpose.md, ausgefüllt vom Benutzer, in jeden LLM-Aufruf eingebunden, den das System tätigt. Jeder Ingest-Prompt, jeder Generierungs-Prompt, jeder Chat-Retrieval liest sie. Der Effekt ist eine stabile, richtungsweisende Priorität, die jedes nachgelagerte Verhalten konditioniert. Das LLM wird den System-Prompt ohnehin lesen. Das Hinzufügen der Benutzerabsicht kostet nichts und hebt alles an. Das Fehlen in den meisten anderen Systemen ist schwerer zu erklären als seine Anwesenheit in llm-wiki.
AGENTS.md als autoritativer Agentenvertrag (Tolaria, OpenContext). Die meisten Repositories mit einer AGENTS.md oder CLAUDE.md behandeln sie als Hinweisdatei. Tolaria und OpenContext behandeln sie als Vertrag, wobei sie jede bindende Klausel mit einer mechanischen Prüfung hinterlegen, die den Build fehlschlagen lässt, wenn der Agent sie verletzt. "Überspringe Pre-Commit-Hooks nicht" ist keine höfliche Bitte, es ist eine Regel, die CI durchsetzt. "Testabdeckung muss über der Schwelle bleiben" ist keine Richtlinie, es ist eine Hürde, bei der der Test-Runner abbricht. Ein Hinweis kann ignoriert werden. Ein Vertrag, der durch eine Prüfung hinterlegt ist, kann nicht. Zwei Systeme tun es bereits. Noch eines und es graduiert.
Welche werden als nächstes universell?
Speicherschicht-Autorisierung wird zuerst universell werden. Dies ist die sicherste Vorhersage in der Quellenanalyse. Jedes Speichersystem, das einem Sub-Agenten SQL-Zugriff gibt, ist eine Prompt-Injection von einer Vertraulichkeitsverletzung entfernt, ohne Speicherschicht-Durchsetzung. Die Infrastruktur ist bereits vorhanden. SQLite hat set_authorizer seit den frühen 2000ern. PostgreSQL RLS ist Mainstream. LanceDB und ClickHouse haben eigene Policy-Hooks. Die Hürde ist nicht technisch, es ist Bewusstsein. second-brain hat das funktionierende Beispiel geliefert. Die nächste Generation von verwalteten APIs wird die Disziplin kopieren, weil die Alternative unhaltbar ist.
Quell-Gesprächsrunde-Dekoration wird als zweites universell werden. Die Voraussetzungen sind bereits universell. Die Implementierung sind zwei Abfragen plus ein Budget. Der Informationsgewinn auf Agentenseite ist groß genug, dass derjenige, der es zuerst in einer verwalteten API ausliefert, sichtbar besser darin sein wird, Antworten in Quell-Dialogen zu verankern als derjenige, der es als zweites tut. Der Druck zum Kopieren ist hoch. graymatter hat die Quelle pro Tatsache. supermemory hat Abstammung. Hindsight hat vollständige Gesprächsherkunft. Jedes davon ist einen PR vom Muster entfernt.
Der automatisch degradierte No-Op-Konstruktor wird als drittes universell werden, und zwar in einer anderen Sprache. Gos kulturelle Bedingungen machen das Muster sicher. Der nächste Adoptierende wird wahrscheinlich nicht Python sein, die Kultur ist zu eifrig in Bezug auf Ausnahmen, aber könnte Rust sein. Es ist eine Bibliotheks-API-Design-Entscheidung, keine Speicherentscheidung, und es wird sich dort verbreiten, wo "Demo-Ästhetik plus Produktionsdisziplin" der richtige Trade ist.
Schattenmodus-Bereitstellung ist der Außenseiter. Technisch trivial, kulturell schwierig. Wenn ein zweites System einen Schwellwert instrumentiert, bevor es ihn als Tor verwendet, graduiert das Muster sofort, und das dritte und vierte folgen innerhalb eines Release-Zyklus, weil die technischen Ergonomien unwiderlegbar sind, sobald demonstriert.
Die verbleibenden vier sind jeweils von einer bestimmten Bereitstellungsform abhängig, die häufiger wird. Race-Schutz wird universell, wenn mehr Systeme Multi-Konversations-Parallelität bekommen. Physische Isolation pro Mandant wird universell, wenn regulierte Unternehmenskunden danach fragen. purpose.md wird universell, wenn das Karpathy-LLM-Wiki-Paradigma seine dritte oder vierte Implementierung bekommt. AGENTS.md als Vertrag wird universell, wenn der Rahmen "Agenten sind Kollegen" zur dominanten Harnisch-Metapher wird. Keines ist unwahrscheinlich. Keines ist sicher.
Ein Fazit
Der verbindende Faden über alle acht hinweg ist die gleiche Position: Die Anwendungsschicht ist keine vertrauenswürdige Isolationsgrenze. Speicherschicht-Autorisierung ist der Ausdruck pro Agent. Physische Datenbanken pro Mandant sind der Ausdruck pro Mandant. AGENTS.md als Vertrag ist der Ausdruck pro Agentenverhalten. Die nächste Iteration dieses Korpus wird, so die Vorhersage, ein neues universelles Muster mit diesem Namen enthalten.
Der vorherige Artikel hat argumentiert, dass der Agent die Tools halten und entscheiden sollte, was abgerufen wird. Dieser hier handelt davon, was hält, wenn der Agent diese Tools dorthin richtet, wo du es nicht erwartet hast. Die sechs universellen Muster sind Konsens. Die acht hier sind die Frühindikatoren dafür, wohin sich der Konsens als nächstes bewegt. Speicherschicht-Autorisierung ist die Spitze der Spitze, und die Kosten, sie zu verpassen, sind die Art von Kosten, die auf Hacker News auftauchen.
