J’ai vu trop d’ingénieurs confier à un agent les clés de toute leur base de connaissances, puis tomber des nues quand il mettait le feu à la maison.
C’est toujours le même scénario. Quelqu’un connecte un modèle capable avec un accès au système de fichiers, le pointe sur un dossier plein de notes, de code, de contrats ou de recherches, et le lâche dans la nature. Pendant un moment, c’est magique. Puis un jour, l’agent décide que la meilleure façon de « corriger » un document, c’est de l’écraser. Ou il refactorise en toute confiance un fichier qu’il n’a pas complètement lu. Ou il fait la bonne chose, mais sur la mauvaise copie du fichier. Le travail qui disparaît est rarement celui qu’on aurait choisi de perdre.
Mais le problème de fond est structurel, et il ne concerne pas vraiment la mauvaise journée d’un seul agent. Trois modes d’échec reviennent systématiquement chez les équipes à qui je parle (malheureusement, c’est en généralaprèsqu’elles ont déjà perdu des données).
Écritures destructives. Celle décrite ci-dessus. Un agent avec un large accès en écriture traite votre dossier de référence comme un établi. Les utilisateurs indiquent à l’agent « ce qu’il peut toucher », sans définir de vraie frontière lecture/écriture, et l’agent ne sait pas quels fichiers sont sacrés parce que rien ne le lui a dit, le contexte a été compacté et les instructions ont disparu, ou il s’est simplement convaincu lui-même que « rm ~/Pictures/Wedding » est la façon la plus efficace d’« organiser mes photos s’il te plaît ».
Dépendance fournisseur. Une équipe se laisse convaincre d’adopter la fonctionnalité « mémoire » livrée avec son produit IA du moment. Six mois plus tard, elle veut changer de modèle, changer de harness, ou simplement emporter son contexte ailleurs, et c’est impossible. La mémoire vit à l’intérieur du produit d’un tiers et ne lui a jamais vraiment appartenu.
Mémoire boîte noire. Même quand l’agent se souvient de choses, personne ne peut auditercequ’il retient. Impossible de faire un diff. Impossible de revenir en arrière. Impossible de demander « que croit actuellement l’agent à propos de la politique de remboursement ? » et d’obtenir une réponse claire. La mémoire n’est pas un artefact ; c’est plutôt une « vibe » informe qui vit « quelque part ».
Chacun de ces problèmes, pris isolément, peut se corriger. Ensemble, ils constituent une erreur de catégorie. On a traité la mémoire d’un agent comme une fonctionnalité de l’agent. Ce n’en est pas une. C’est un substrat sur lequel l’agent s’exécute, et pour l’instant, presque personne ne possède le sien.
Pourquoi vous devriez contrôler la couche mémoire de votre agent
Si vous ne retenez qu’une chose de cet article, que ce soit celle-ci :la couche mémoire de votre agent doit être quelque chose que vous pouvez tenir dans la main.
Locale. Portable. Inspectable. À vous.
C’est une forme différente de ce que la plupart des produits vous vendent. Les harnesses propriétaires qui se disputent aujourd’hui le rôle de mémoire de votre agent ont un intérêt réel à garder votre contexte chez eux. Une fois que vos connaissances vivent dans leur format, dans leur cloud, derrière leur compte, vous avez bien moins de raisons de partir. Le discours, c’est « on va retenir les choses pour vous ». La seconde moitié, non dite, c’est « et on préférerait que vous ne puissiez pas les emporter ».
Vous n’êtes pas obligé d’accepter ce deal. Et vous n’avez pas à me croire sur parole, jene suis pas le seul à le dire.
Agent Library
La Agent Library est la couche mémoire qu’on voulait sans l’avoir. C’est un fichier SQLite local avec recherche hybride sémantique et par mots-clés, capable d’ingérer du texte, du code, des PDF et des images, qui parle MCP nativement et tourne entièrement sur votre machine. Aucun compte cloud. Aucun fournisseur qui voit vos documents. Plus besoin de ré-indexer les mêmes docs dans cinq outils différents.
Nous le publions en open source aujourd’hui. Le dépôt est sur https://github.com/ArcadeAI/agent-library, et il y a unevidéo de démo qui montre concrètement ce que ça fait de l’utiliser. J’y présente :
- Comment configurer une nouvelle Agent Library
- Comment ajouter des sources
- Comment maintenir la Library indexée
- Comment l’utiliser dans plusieurs harnesses d’agents
- Comment l’utiliser dans le CLI
- Comment rechercher du contenu dans la library
- Comment gérer le contenu à l’intérieur
Pour tous les détails, allez regarder la vidéo.
La frontière lecture/écriture
La décision de conception la plus importante dans Agent Library, c’est que, du point de vue d’un agent,la library est principalement en lecture.
L’essentiel de ce dont un agent a besoin d’une couche mémoire, c’est l’accès en lecture : rechercher dans la library, récupérer le bon passage, ancrer la réponse. Le serveur MCP de l’Agent Library expose un petit ensemble d’outils de lecture (search_library read_from_libraryet consorts) qui couvrent ces 90 % de cas. Il expose aussi des outils d’écriture (add_to_library update_library_doc remove_from_library) pour les cas où vous voulez que l’agent tienne ses propres notes, mais ceux-ci sontopt-in.
Si vous démarrez de zéro,n’exposez que les outils de lecture. Une library configurée ainsi ne peut pas, par construction, supprimer vos notes, écraser votre code ou corrompre vos PDF. L’agent peut interroger votre base de connaissances toute la journée ; il ne peut pas la modifier.
Quand quelque chose tourne mal (et ça arrivera tôt ou tard), la deuxième propriété entre en jeu : l’état complet de l’Agent Library est un seul fichier SQLite qui vous appartient. Vous pouvezcple copier avant de lâcher un agent. Vous pouvez comparer deux versions. Vous pouvez revenir à l’index de mardi dernier. Vous pouvez l’ouvrir dans n’importe quel navigateur SQLite et voir, octet par octet, ce que l’agent sait actuellement. C’est une relation différente à la « mémoire » qu’une boîte noire dans le cloud d’un tiers, et c’est la relation que vous voulez la première fois qu’un agent vous surprend.
Pour être tout à fait clair,l’Agent Library est un outil tranchant. Il réduit le rayon d’explosion, mais ne l’élimine pas. Si vous donnez à un agent un accès shell, un accès en écriture au système de fichiers et Librarian en même temps, l’Agent Library ne peut pas vous sauver. L’agent peut quand mêmerm -rfse frayer un chemin à travers votre système, peu importe la prudence de l’Agent Library. L’idée, c’est que lacouche mémoirede l’agent ne devrait pas être ce qui vous trahit, et pour trop de gens en ce moment, c’est le cas.
Pourquoi cette forme
L’Agent Library a des partis pris, et ils appartiennent à notre CTO, Sam Partee, qui l’a construite.
Le choix local-first, la séparation lecture/écriture, la surface MCP-native, SQLite plutôt qu’une base vectorielle hébergée, l’insistance pour que l’index soit un fichier qu’on peut tenir en main. Ce sont tous ses choix, et ils ne sont pas arbitraires. Ils viennent d’années passées à regarder des équipes déployer des agents en production et découvrir, à la dure, quels coins peuvent être coupés et lesquels ne peuvent pas l’être. La mémoire fait partie des seconds.
C’est aussi pourquoi nous le publions en open source. Agent Library n’est pas un composant du produit Arcade, mais un building block pour agents. Le genre de chose qu’on a construite pour nous-mêmes parce qu’on en avait besoin, et qu’on pense utile à suffisamment de monde pour ne pas rester dans un dépôt privé.
Les building blocks agentiques d’Arcade
Agent Library est le premier de plusieurs éléments qu’on va open-sourcer de cette façon. Des choses qu’on a construites pour nous-mêmes, avec des partis pris intégrés, qu’on pense utiles par elles-mêmes. Indépendamment de tout contact avec le reste de ce qu’on fait.
Si vous construisez des agents et que vous avez rencontré l’un des modes d’échec évoqués en début d’article,récupérez-le ici, pointez-le sur un dossier et essayez-le. Commencez par les outils en lecture seule. Faites un snapshot du fichier SQLite avant toute opération ambitieuse. Et si quelque chose explose quand même, dites-le nous, ou mieux encore, ouvrez une issue ou une PR. C’est comme ça que le prochain building block devient plus affûté.
La mémoire de votre agent ne devrait pas vivre dans le produit de quelqu’un d’autre. Maintenant, ce n’est plus obligatoire.
FAQ
En quoi c’est différent des autres produits mémoire ?
La plupart des produits « mémoire » cherchent à extraire des faits sur vous depuis votre historique de chat (« l’utilisateur préfère Python », « l’entreprise de l’utilisateur est Arcade ») pour les réinjecter dans les sessions futures. Agent Library ne fait pas ça. Il indexe un corpus que vous avez déjà (notes, code, PDF, images) et donne à l’agent un moyen de le rechercher. La différence, c’est où vit la mémoire. Votre index est un seul fichier SQLite sur votre disque. Vous pouvez le copier, le comparer, en faire un snapshot, l’ouvrir dans n’importe quel navigateur SQLite, le déplacer d’une machine à l’autre. La mémoire est vraiment à vous, au sens littéral.
C’est juste du RAG ?
La forme de récupération est du RAG, recherche hybride sémantique et par mots-clés sur des documents découpés en chunks. Mais le RAG est une technique, et Agent Library est une position sur l’endroit où cette technique doit s’exécuter. La contribution n’est pas dans les embeddings ni dans le découpage. Elle est dans lafrontière(une surface d’outils principalement en lecture qu’un agent ne peut pas facilement corrompre), lesubstrat(un seul fichier qu’on peut tenir en main), et l’interface(MCP-native, pour que n’importe quel harness puisse l’utiliser sans glue sur mesure). Vous pourriez reconstruire la partie récupération d’Agent Library en une après-midi. L’essentiel, c’est tout ce qui l’entoure.
Qu’est-ce qui reste vraiment sur ma machine ?
Par défaut, tout. L’index, les embeddings, les sections, et bien sûr les documents que vous aviez déjà en local. Le fournisseur d’embeddings par défaut est sentence-transformers en local, aucun appel réseau. La seule soupape est le endpoint d’embeddings compatible OpenAI : si vous en configurez un, ce endpoint voit le texte qu’il traite. Nous pointons le nôtre vers un serveur local compatible OpenAI, ce qui garde les données sur la machine. Si vous le pointez vers une API hébergée, c’est un choix que vous faites explicitement.
Quel est le lien avec le produit Arcade ?
Agent Library est construit surarcade-mcp-serverle framework MCP open source d’Arcade, de la même façon qu’une application Python est construite sur ses bibliothèques. Il ne nécessite pas de compte Arcade, ni de clé API, ni de service hébergé. Le produit Arcade est une chose séparée. Agent Library fonctionne en standalone.
Est-il prêt pour la production ?
C’est la couche mémoire qu’on fait tourner en local nous-mêmes, et les décisions de conception sont arrêtées : la séparation lecture/écriture, le substrat SQLite, la surface MCP ne vont pas changer. Mais c’est du open source au premier jour. Attendez-vous à des aspérités, à ce que l’API se resserre au fur et à mesure que les gens l’utilisent de façons qu’on n’avait pas anticipées, et attendez-vous à ce qu’on corrige les choses plus vite si vous nous dites ce qui a cassé. Je commencerais par les outils en lecture seule et ferais un snapshot du fichier SQLite avant toute opération ambitieuse.
