Agentis Memory : un stockage compatible Redis avec recherche vectorielle et embeddings locaux

Agentis Memory avance une idée simple, mais importante pour le marché des agents IA : une mémoire de travail partagée qu'on utilise comme un Redis ordinaire. Au lieu d'une base vectorielle distincte, d'une API d'embeddings externe et de SDK sur mesure, le projet réunit dans un seul processus un stockage clé-valeur, la recherche sémantique et le calcul local des embeddings. Pour les équipes qui conçoivent des systèmes multi-agents, c'est une tentative de régler l'un de leurs problèmes les plus douloureux : échanger du contexte entre agents sans couches réseau ni latence superflues.

Le problème est apparu dans un cas réel : l'investigation d'incidents en production. Lorsque plusieurs agents spécialisés examinent en parallèle les logs, les métriques, les échanges et l'historique des pannes passées, chacun ne voit que son fragment du tableau. Un agent peut trouver OOMKilled dans les logs et, de fait, remonter à la cause racine, tandis que les autres continuent de bâtir leurs propres versions : pic de CPU, déploiement récent ou toute autre corrélation.

Au final, le synthétiseur récupère plusieurs hypothèses contradictoires, dont certaines ne sont que du bruit. Stocker ces trouvailles dans un fichier markdown partagé n'aide pas : conflits d'écriture, pas de TTL, pas de structure et pas de recherche par le sens. Pour un système d'agents, cela ne suffit plus.

L'étude des solutions existantes a révélé le même problème sous un autre angle. Mem0 et Zep se présentent déjà comme une couche de mémoire pour agents IA, mais traînent avec eux une API REST, des SDK distincts, un stockage vectoriel et des services externes pour les embeddings. Redis Stack se rapproche davantage du modèle recherché, car il reste compatible avec les clients Redis, mais il laisse le calcul des vecteurs en dehors du serveur.

C'est tolérable pour du RAG à long terme, mais trop lourd pour une mémoire de travail, où un agent enregistre un fait et un autre doit le retrouver en quelques millisecondes. Chaque saut réseau supplémentaire nuit à la fois à la latence et à la fiabilité.

La première hypothèse d'ingénierie était évidente : prendre Redis lui-même, le forker et y intégrer ONNX Runtime et un index vectoriel. En pratique, cette voie a vite buté sur le travail complexe avec C, les bibliothèques natives, la gestion de la mémoire et l'instabilité face aux requêtes concurrentes. Après l'échec du prototype, le projet a été réécrit de zéro en Java 25 avec GraalVM native-image.

Il en résulte un unique binaire natif d'environ 150 Mo, avec le modèle d'embeddings déjà intégré. En interne, il s'appuie sur la Java Vector API pour l'accélération SIMD de la similarité cosinus, sur Project Loom pour les threads virtuels, sur ONNX Runtime pour l'inférence locale du modèle all-MiniLM-L6-v2 et sur la bibliothèque jvector pour la recherche des plus proches voisins HNSW.

Vu de l'extérieur, Agentis Memory se comporte comme un serveur Redis familier. Il prend en charge plus de 90 commandes standard, le TTL, SCAN et un pub/sub de base, et l'on s'y connecte avec des clients ordinaires comme redis-py, Jedis, ioredis ou go-redis. La différence essentielle tient à quatre commandes mémoire supplémentaires.

MEMSAVE reçoit un texte, le découpe en chunks par phrase, calcule des vecteurs de 384 dimensions et les indexe de manière asynchrone, généralement en 5–10 millisecondes par chunk. MEMQUERY reçoit une requête en langage naturel et renvoie les entrées les plus proches par similarité cosinus. MEMSTATUS indique si l'index est prêt pour une clé donnée, et MEMDEL supprime les données à la fois de la couche clé-valeur et de l'index vectoriel.

Pour le développeur, cela ressemble à une extension minimale du modèle Redis qu'il connaît, et non à une plateforme distincte avec un nouvel écosystème.

Côté performances, l'histoire est aussi parlante. La première version Java était environ deux fois plus lente que Redis. Après le passage à GraalVM native-image et la réécriture du hot path avec la Vector API, la situation s'est inversée : les opérations sur chaînes sont passées d'environ 60 mille à 168 mille ops/sec, soit environ 1,36x Redis.

Sur une charge mixte, le résultat atteint environ 1,40x. Avec une profondeur de pipeline de 100, le système a atteint 3,19 millions d'opérations par seconde, soit environ 1,71x Redis, grâce à une architecture multithread sans boucle d'événements mono-thread. Mais un compromis demeure : sur la latence p99 des chaînes, Redis reste devant, avec 3,82 millisecondes contre 6,27 pour Agentis Memory, le prix à payer pour le garbage collection.

L'accent est mis sur la confidentialité et le coût. Les embeddings sont calculés localement via ONNX Runtime au sein même du processus, sans clé d'API, sans appel à des services externes et sans envoi de logs, de métriques ni d'échanges internes vers le cloud. Pour des systèmes qui traitent des incidents et de l'infrastructure interne, ce n'est pas une amélioration cosmétique, mais une décision d'architecture importante. L'inférence locale prend environ 2–5 millisecondes par chunk, évite une facture d'embeddings distincte et supprime la dépendance à la disponibilité d'un tiers. Plus les données sont sensibles et plus la fréquence des requêtes est élevée, plus l'avantage de cette approche se fait sentir.

De façon plus large, Agentis Memory illustre l'évolution de l'infrastructure autour des agents IA. Il ne suffit plus au marché de brancher un LLM, des outils et un orchestrateur. Le prochain terrain de concurrence, c'est la mémoire partagée, la vitesse de synchronisation du contexte et la capacité du système à écarter vite les fausses hypothèses. Si le modèle compatible Redis avec embeddings locaux s'impose sur des charges réelles, ces solutions pourraient devenir pour les systèmes d'agents ce que Redis est depuis longtemps pour le développeur backend classique : une couche rapide de coordination, de cache et de mémoire de travail partagée.

*Meta est reconnue comme organisation extrémiste et interdite en Fédération de Russie.