Un léger retard pour cette dernière partie de la série des 19 systèmes, mais mieux vaut tard que jamais.
Les six schémas universels des 19 systèmes que j'ai analysés constituent l'épine dorsale de cette série. Investissement de qualité au moment de l'écriture. Provenance qui accompagne le fait. Recherche hybride fusionnée par RRF. Stockage hiérarchisé avec promotion basée sur la chaleur. Budgets de contexte explicites. Outils, pas d'injections, à la surface de l'agent. Chacun a mérité son propre article parce que trois systèmes ou plus sont arrivés indépendamment à la même discipline.
Les schémas universels s'arrêtent ici. À partir de là, les schémas émergents commencent.
Cet article porte sur huit schémas qui se situent en dessous du seuil, présents dans un ou deux systèmes, où l'implémentation répond si clairement à un problème réel qu'il est difficile de croire qu'ils resteront rares. Sept apparaissent dans exactement un système. Un apparaît dans deux et est à une adoption de passer à la catégorie supérieure. Le premier reçoit le traitement le plus approfondi car c'est le plus important.
Être précoce signifie que certains de ces schémas ne deviendront pas universels. Être tardif est pire : vous construisez un système en 2026 qui est livré sans autorisation au niveau du stockage parce qu'une synthèse l'a qualifié de bizarrerie isolée, et vous obtenez une démonstration d'injection de prompt sur Hacker News en 2027.
Le moteur de stockage est la seule autorité qui tienne
L'article précédent soutenait que l'agent devrait détenir les outils. Donnez-lui un outil SQL et la question devient immédiate : qu'est-ce qui l'empêche d'interroger la table qu'il ne devrait pas ?
Les approches naïves sont bien connues et toutes erronées.
Instruction au niveau du prompt : « Vous n'êtes pas autorisé à lire la table des conversations. » Fonctionne contre un modèle coopératif. Échoue contre tout modèle qui interprète mal l'instruction, décide que l'interdiction ne s'applique pas à sa tâche actuelle, ou fonctionne sous une jailbreak.
Filtre au niveau de l'application : l'outil sql_query encapsule le SQL du modèle, l'analyse pour détecter les références de tables interdites, rejette la requête avant de la transmettre à la base de données. Fonctionne contre un modèle naïf. Échoue contre tout modèle qui cite les noms de tables, utilise ATTACH, exploite une divergence d'analyse entre l'encapsuleur et la base de données, ou achemine via une vue définie ailleurs.
Accès uniquement via ORM : l'agent ne touche jamais au SQL brut, il appelle des méthodes typées. Fonctionne jusqu'à ce que le système développe un outil de débogage, un outil d'analyse, un outil de migration, ou une fonctionnalité « laissez l'agent joindre deux tables », moment auquel la règle se brise et la rupture passe inaperçue.
En clair : aucun de ces éléments n'est une application. Ce sont des indices. Un système qui veut un véritable isolement des sous-agents doit demander au moteur de stockage lui-même de refuser la lecture, pas à la couche supérieure. C'est la discipline que la sécurité basée sur les capacités impose aux ressources du système d'exploitation : le noyau dit non, pas l'application. C'est aussi la discipline que la sécurité au niveau des lignes de PostgreSQL impose aux SaaS multi-locataires : la politique vit dans la base de données, pas dans l'ORM, car « l'ingénieur qui a construit le nouveau microservice a oublié d'appliquer le filtre de locataire » est une classe de bogues que seule une politique du moteur de stockage peut exclure.
second-brain est le premier exemple concret du corpus. Sa base de données délimitée a trois couches, chacune nécessaire, aucune suffisante en soi.
Une nouvelle connexion SQLite en mémoire par agent délimité. Le constructeur ouvre :memory: et attache la base de données réelle en mode lecture seule. La connexion de l'agent n'a pas de schéma principal réel, il n'y a rien à lire sauf ce que la couche suivante y place.
Des VUES TEMPORAIRES dans le schéma principal redirigeant vers les tables autorisées dans la source. Les définitions de vues proviennent du profil de l'agent et peuvent encoder une rédaction au niveau des colonnes ou des filtres au niveau des lignes. Un validateur de nom de vue empêche l'injection de noms de tables malveillants via le profil.
Un hook d'autorisation de l'API C de SQLite refusant toute lecture du schéma source qui ne passe pas par une vue. Le hook se déclenche pour chaque lecture que SQLite s'apprête à effectuer, avant même que l'optimiseur ne résolve le nom de la table. Une lecture à l'intérieur d'un corps de vue est autorisée, la vue est le filtre de périmètre. Une lecture de niveau supérieur est vérifiée par rapport à l'ensemble des noms de vues créées par le périmètre. Toute lecture directe du schéma source est refusée sans exception.
Le LLM peut écrire tout le SQL qu'il veut. Il peut citer des noms de tables, utiliser UNION, utiliser ATTACH, utiliser toute la grammaire de SQLite. Il ne peut pas réussir à lire une ligne d'une table qui n'est pas dans la liste d'autorisation, car l'autoriseur intercepte la lecture au niveau C avant que le nom de la table ne soit résolu. Le filtre au niveau de l'application peut être contourné. L'autorisation du moteur de stockage, non.
Environ 50 lignes de Python de la bibliothèque standard. Aucune dépendance supplémentaire, aucun processus supplémentaire, aucune migration de schéma. Le surcoût par requête est d'un callback C par lecture, invisible par rapport au coût de la requête elle-même. Le schéma se compose proprement avec tout le reste : le registre d'outils de l'agent peut toujours être limité par fonctionnalité, les définitions de vues peuvent toujours encoder une rédaction au niveau des colonnes, l'historique des conversations peut toujours être rédigé au moment de l'écriture. Aucune de ces couches n'est affaiblie par l'application au niveau du stockage. Elles en sont renforcées.
Le cadrage est important. Tous les autres schémas de sécurité dans les 19 systèmes sont des indices. Le moteur de stockage est l'autorité.
Trois autres qui méritent d'être nommés
Protection contre les conditions de concurrence lors du nettoyage asynchrone (llm-wiki)
La maintenance de la mémoire en arrière-plan est fondamentalement en conflit avec les actions utilisateur au premier plan. Un balayage qui a commencé contre le projet A et se termine contre le projet B a corrompu les deux. Il a déplacé les décisions de A dans le magasin de révision de B, ou a marqué les éléments de B comme résolus avec les données de A. C'est une classe de bogues facile à introduire, difficile à détecter et impossible à corriger proprement car l'état corrompu semble légitime.
llm-wiki exécute une boucle de révision en arrière-plan en deux étapes et, à chaque point de rendement, revérifie deux signaux de protection contre les conditions de concurrence : un signal d'abandon déclenché par le gestionnaire de changement de projet, et une comparaison de chemin avec le projet actuel dans le magasin de l'interface utilisateur. Si l'une ou l'autre vérification échoue, le balayage revient en vol sans appliquer les décisions. La poignée de main du changement de projet du côté de la file d'attente complète le tableau : elle vide l'état du projet actif sur le disque avant d'effacer la mémoire, remet les éléments en traitement en attente, abandonne à la fois l'appel LLM en vol et le jugement de balayage en vol, et seulement ensuite écrit dans le chemin du projet en pause.
Le méta-schéma est le point à retenir : déterministe là où vous le pouvez, LLM là où vous devez, interrompable partout. La structure en deux étapes maintient le LLM en dehors des cas que de simples vérifications d'existence peuvent gérer. La protection contre les conditions de concurrence maintient les deux étapes interrompables. La combinaison est un modèle pour toute boucle de maintenance de mémoire en arrière-plan dans n'importe quel système.
Le constructeur no-op auto-dégradé (graymatter)
La conception d'API de bibliothèque a une tension récurrente. Le « hello world » le plus simple veut que la bibliothèque fonctionne simplement, une ligne pour construire, une pour appeler. La posture de production la plus défendable veut qu'elle échoue bruyamment à la construction avec une erreur structurée que l'appelant ne peut pas ignorer.
graymatter choisit l'échec silencieux, mais avec une discipline qui rend le compromis productif. Le constructeur ne renvoie jamais d'erreur. Si l'initialisation échoue, bbolt est verrouillé, le répertoire de données n'est pas accessible en écriture, le magasin de vecteurs ne peut pas être ouvert, il enregistre sur stderr et renvoie une mémoire dégradée dont les méthodes sont toutes des no-op. Les appelants en production vérifient via Healthy() avant de faire confiance au handle. La bibliothèque est go get-able, importable en trois lignes et fonctionne dans la démo. Healthy() est la taxe de discipline de production.
Le schéma rend la bibliothèque sûre à intégrer dans des harnais d'agents qui ont leur propre cérémonie de démarrage. Un harnais d'agent qui appelle [graymatter.New](https://graymatter.new/)(...) pendant le démarrage, ignore le chemin d'erreur car il n'y a pas de chemin d'erreur, et continue, obtient une couche mémoire fonctionnelle dans le chemin heureux et un repli sans mémoire lorsque le répertoire de données est en lecture seule. Dans les deux cas, le harnais démarre. C'est un type spécifique de composition défensive que les constructeurs à échec bruyant ne peuvent pas offrir sans une gestion explicite des erreurs à chaque site d'intégration.
Détection des doublons en mode shadow (mem9)
Chaque système qui implémente la suppression des doublons doit choisir un seuil de similarité cosinus. Au-dessus de 0,95, c'est presque certainement un doublon. En dessous de 0,7, ce ne l'est presque certainement pas. L'espace entre les deux est contesté, et la bonne coupure dépend du modèle d'embedding, du domaine, de la distribution des requêtes et du coût des faux positifs par rapport aux faux négatifs dans ce système particulier.
La tentation est écrasante d'en choisir un basé sur l'intuition et de livrer. mem9 ne le fait pas. Il exécute la requête de détection des doublons pour chaque fait, enregistre le score cosinus dans un histogramme Prometheus et ne prend aucune mesure. Le seuil est reporté jusqu'à ce que les données de production le justifient. « Livrez l'observation, pas l'heuristique. »
La même logique s'applique à chaque décision seuillée dans chaque système mémoire. Seuil de reranking. Seuil de confiance de rappel. Seuil de chaleur de promotion de niveau. Seuil de similarité de fusion d'insight. La plupart des systèmes dans les 19 livrent ces valeurs devinées. mem9 livre avec la valeur reportée. La discipline est rare et le résultat est meilleur.
Quatre autres, plus serrés
Isolement physique de la base de données par locataire (mem9).
Au lieu d'un filtre WHERE tenant_id = ? sur un magasin partagé, mem9 provisionne un cluster TiDB séparé par locataire via TiDB Zero. L'isolement est du côté du moteur de stockage. L'application ne peut pas accidentellement interroger plusieurs locataires car il n'y a pas de magasin partagé à interroger. C'est une version plus grossière du même état final que l'autorisation au niveau du stockage : un isolement appliqué par le moteur, pas par l'application. Le coût d'infrastructure qui rendait cela historiquement impraticable a disparu. TiDB Zero s'auto-provisionne. Neon fait de même pour PostgreSQL. Cloudflare D1 fait de même pour SQLite.
Décoration des tours de source avec un budget de contexte explicite (mem9).
Une mémoire récupérée est une chaîne. « L'utilisateur préfère Postgres. » Correct, concis, impossible à ancrer sans contexte. mem9 attache les tours de conversation d'origine comme décoration, notés par rapport à la requête et plafonnés par un triple budget : score minimum, limite par mémoire, limite totale. L'agent lisant « L'utilisateur préfère Postgres » obtient le tour où l'utilisateur a dit « nous avons essayé MongoDB mais les jointures nous ont tués, donc je suis passé à Postgres le trimestre dernier. » Aucun deuxième appel d'outil requis. L'ancrage est dans le résultat. Les prérequis sont déjà universels : provenance plus recherche hybride. La plupart des systèmes dans les 19 pourraient implémenter cela en deux jours.
purpose.md comme quatrième fichier (llm-wiki).
Le modèle LLM Wiki de Karpathy a trois fichiers canoniques : les sources brutes, l'ensemble de travail du wiki et schema.md pour les règles structurelles. llm-wiki en ajoute un quatrième : purpose.md, rempli par l'utilisateur, intégré dans chaque appel LLM que le système effectue. Chaque prompt d'ingestion, chaque prompt de génération, chaque récupération de chat le lit. L'effet est un a priori directionnel stable qui conditionne chaque comportement en aval. Le LLM va de toute façon lire le prompt système. Ajouter l'intention de l'utilisateur ne coûte rien et améliore tout. L'absence dans la plupart des autres systèmes est plus difficile à expliquer que sa présence dans llm-wiki.
AGENTS.md comme contrat d'agent faisant autorité (Tolaria, OpenContext). La plupart des référentiels avec un AGENTS.md ou CLAUDE.md le traitent comme un fichier d'indice. Tolaria et OpenContext le traitent comme un contrat, soutenant chaque clause contraignante avec une vérification mécanique qui fait échouer la construction si l'agent la viole. « Ne sautez pas les hooks de pré-commit » n'est pas une demande polie, c'est une règle que le CI applique. « La couverture de test doit rester au-dessus du seuil » n'est pas une directive, c'est une barre sur laquelle l'exécuteur de test s'arrête. Un indice peut être ignoré. Un contrat soutenu par une vérification ne le peut pas. Deux systèmes le font déjà. Un de plus et il passe à la catégorie supérieure.
Lesquels deviendront universels ensuite
L'autorisation au niveau du stockage deviendra universelle en premier. C'est la prédiction la plus confiante de l'analyse des sources. Chaque système mémoire qui donne à un sous-agent un accès SQL est à une injection de prompt d'une violation de confidentialité sans application au niveau du stockage. L'infrastructure est déjà en place. SQLite a set_authorizer depuis le début des années 2000. PostgreSQL RLS est courant. LanceDB et ClickHouse ont leurs propres hooks de politique. La barrière n'est pas technique, c'est la sensibilisation. second-brain a fourni l'exemple concret. La prochaine génération d'API gérées copiera la discipline car l'alternative est indéfendable.
La décoration des tours de source deviendra universelle en deuxième. Les prérequis sont déjà universels. L'implémentation est de deux requêtes plus un budget. Le gain d'informations du côté de l'agent est suffisamment important pour que celui qui le livre en premier dans une API gérée soit visiblement meilleur pour ancrer les réponses dans le dialogue source que celui qui le livre en deuxième. La pression pour copier est élevée. graymatter a la source par fait. supermemory a la lignée. Hindsight a une provenance conversationnelle complète. N'importe lequel d'entre eux est à une PR du schéma.
Le constructeur no-op auto-dégradé deviendra universel en troisième, et dans un langage différent. Les conditions culturelles de Go rendent le schéma sûr. Le prochain adoptant ne sera probablement pas Python, la culture est trop friande d'exceptions, mais pourrait être Rust. C'est un choix de conception d'API de bibliothèque, pas un choix de mémoire, et il se propagera partout où « esthétique de démo plus discipline de production » est le bon compromis.
Le déploiement en mode shadow est le cheval noir. Techniquement trivial, culturellement difficile. Si un deuxième système instrumente un seuil avant de le verrouiller, le schéma passe immédiatement à la catégorie supérieure, et le troisième et le quatrième suivent dans un cycle de publication car l'ergonomie d'ingénierie est irréfutable une fois démontrée.
Les quatre restants sont chacun conditionnés par une forme de déploiement spécifique devenant plus courante. La protection contre les conditions de concurrence devient universelle lorsque davantage de systèmes développent un parallélisme multi-conversation. L'isolement physique par locataire devient universel lorsque les clients d'entreprise réglementés commencent à le demander. purpose.md devient universel lorsque le paradigme LLM Wiki de Karpathy obtient sa troisième ou quatrième implémentation. AGENTS.md en tant que contrat devient universel lorsque le cadrage « les agents sont des collègues » devient la métaphore de harnais dominante. Aucun n'est invraisemblable. Aucun n'est certain.
Une conclusion
Le fil conducteur de tous les huit est la même position : la couche applicative n'est pas une frontière d'isolement fiable. L'autorisation au niveau du stockage est l'expression par agent. Les bases de données physiques par locataire sont l'expression par locataire. AGENTS.md en tant que contrat est l'expression par comportement d'agent. La prochaine itération de ce corpus contiendra, selon cette prédiction, un nouveau schéma universel de ce nom.
L'article précédent plaidait en faveur de l'agent détenant les outils et décidant quoi récupérer. Celui-ci porte sur ce qui tient lorsque l'agent tourne ces outils vers un endroit auquel vous ne vous attendiez pas. Les six schémas universels sont un consensus. Les huit ici sont les indicateurs avancés de l'endroit où le consensus se déplace ensuite. L'autorisation au niveau du stockage est la pointe avancée de la pointe avancée, et le coût de la manquer est le genre de coût qui apparaît sur Hacker News.
