Le runtime de mémoire pour agents EverOS adopte Markdown comme source de vérité
EverMind a publié EverOS, un runtime de mémoire pour agents open source, le 29 juin 2026, en le positionnant comme une solution Markdown-first pour doter les agents IA d'une mémoire persistante d'une session à l'autre. Cela compte, car la plupart des stacks d'agents échouent de manière banale et coûteuse dès que le contexte disparaît: les tentatives de réexécution se multiplient, les transferts deviennent chaotiques et chaque tâche repart de zéro. Selon le rapport de MarkTechPost du 29 juin sur EverOS, EverOS est distribué sous licence Apache 2.0 et combine des fichiers Markdown, SQLite et LanceDB pour une mémoire persistante.
EverMind publie EverOS pour doter les agents IA d'une mémoire persistante
Du point de vue de l'implémentation, EverOS ne cherche pas à être un framework d'agents complet. C'est une bibliothèque Python et un runtime local-first que l'on peut intégrer dans une boucle existante, exposer via FastAPI et connecter à des backends de modèles compatibles avec le protocole OpenAI. Cette portée plus restreinte est ce qui rend cette sortie digne d'intérêt.
Le problème qu'il résout est familier. Dans un prototype client sur lequel j'ai travaillé le mois dernier, le modèle gérait bien un flux de support pendant les 20 premières minutes, puis oubliait les préférences spécifiques au client lors de la deuxième session et commençait à demander des informations qu'il avait déjà vues. Le modèle n'était pas en cause; la couche mémoire était trop fine. EverOS vise exactement cette lacune: une mémoire persistante pour les agents IA sans forcer tout le système dans un unique stockage vectoriel.
MarkTechPost reformule clairement la proposition: EverOS traite la mémoire comme des fichiers modifiables plutôt que comme des enregistrements de base de données cachés. C'est une distinction pratique, pas seulement une préférence de design. Si la mémoire est un fichier, un ingénieur peut l'inspecter, le comparer, le versionner et le réparer sans avoir à inventer une autre interface d'administration.
Markdown devient la source de vérité pour la mémoire des agents
La partie inhabituelle est la source de vérité. EverOS écrit les enregistrements de mémoire sous forme de fichiers .md simples, tandis qu'une bibliothèque complémentaire, EverAlgo, gère la logique d'extraction. Cela signifie que les profils, épisodes, faits, prévisions, cas et skills sont tous représentés dans un format qu'un humain peut ouvrir directement. Si votre équipe utilise déjà Git, des outils en ligne de commande ou des systèmes de prise de notes comme Obsidian, le modèle opérationnel est immédiatement compréhensible.
J'apprécie cela plus que prévu. En production, les bugs de mémoire ne sont souvent pas d'abord des bugs de récupération; ce sont des bugs de forme de l'état. Une préférence a été fusionnée deux fois. Une clé d'identité utilisateur a dérivé. Une étape d'extraction a surappris une phrase. Cacher ces problèmes dans des embeddings les rend plus longs à diagnostiquer. Stocker l'état canonique en Markdown offre aux équipes un chemin de débogage plus simple.
Il y a tout de même un indexage sous-jacent. EverOS utilise la surveillance de fichiers et une cascade de synchronisation pour que les modifications apportées aux Markdown ne laissent pas la recherche obsolète. C'est la partie que je testerais intensivement lors d'un pilote, surtout si plusieurs agents ou workers peuvent écrire en même temps. Le local-first semble élégant jusqu'à ce que les écritures concurrentes, les échecs partiels et les retards de file d'attente apparaissent.
Un choix de design connexe est l'isolation de portée. Les recherches peuvent être limitées par user_id, agent_id, app_id, project_id et session_id. Pour l'automatisation en entreprise, c'est indispensable. Si je devais intégrer cela dans un flux en production, je revérifierais ces limites avant toute courbe de benchmark.
Les équipes qui évaluent comment cela s'intègre dans une stack de livraison plus large se soucieront probablement moins de la nouveauté Markdown que de la rapidité avec laquelle cela peut être intégré dans des flux réels. C'est là qu'un service comme l'automatisation des processus métier par l'IA est le plus adapté: EverOS semble le plus utile lorsque la mémoire est un composant au sein d'un processus automatisé plus large, et non un projet de recherche isolé.
Comment EverOS combine SQLite, LanceDB, BM25 et les vecteurs
Sous le capot, la stack de stockage est volontairement légère. Markdown est la source de vérité. SQLite gère l'état et les files d'attente. LanceDB gère les vecteurs, BM25 et le filtrage scalaire. Comparé à des stacks de mémoire plus lourdes qui intègrent Redis, Elasticsearch, Kafka et une base de données vectorielle séparée, c'est une empreinte plus légère pour une petite équipe.
La promesse clé de récupération est la recherche hybride en une seule requête: BM25 pour la précision des mots-clés, vecteurs denses pour la similarité sémantique, et filtres scalaires pour les limites de métadonnées. Si vous avez déjà vu une récupération purement vectorielle manquer un code produit exact ou un nom de client parce que l'embedding classait un concept plus général plus haut, vous savez pourquoi BM25 reste important. La recherche hybride BM25 + vecteurs n'est pas spectaculaire, mais elle corrige des modes de défaillance très réels.
Selon l'article source, EverMind désigne ce chemin combiné comme la génération augmentée par récupération multimodale, ou mRAG. La mécanique importe plus que l'étiquette. La question est de savoir si vos requêtes sont principalement sémantiques, principalement lexicales, ou mixtes. Dans les journaux de support, les textes de conformité et le dépannage technique, elles sont généralement mixtes.
C'est aussi là qu'EverOS semble plus solide qu'une mémoire basée uniquement sur les prompts. Ajouter plus d'historique dans la fenêtre de contexte fonctionne jusqu'à ce que le coût, la latence ou la décroissance de l'attention commencent à poser problème. Une couche de récupération avec correspondance exacte de termes et recherche à portée limitée vieillit généralement mieux que simplement augmenter la taille du prompt.
Les cas se transforment en Skills dans EverOS
La fonctionnalité la plus intéressante est la mémoire procédurale. EverOS stocke les tâches accomplies comme des Cas, puis distille les motifs réussis répétés en Skills réutilisables. Je décrirais cela moins comme de la magie d'auto-amélioration et plus comme de la compression de flux de travail. Si un agent résout répétitivement la même classe de tâches, préserver le chemin réussi est plus utile que de stocker des transcriptions brutes indéfiniment.
Cela dit, c'est là que je serais le plus sceptique. Les pipelines de distillation peuvent dériver. Ils peuvent sur-généraliser à partir d'un petit échantillon, préserver des étapes fragiles, ou transmettre une mauvaise décision qui avait l'air réussie dans un contexte donné. EverOS version 1.1.0 ajoute des composants de cycle de vie tels que les Knowledge APIs et la Reflection pour affiner les profils, épisodes et skills entre les sessions, ce qui est la bonne direction. Mais je voudrais quand même des audits sur la manière dont un Cas devient un Skill et sur la facilité de revenir en arrière.
L'article source résume simplement le modèle de mémoire: la mémoire épisodique trace ce qui s'est passé, la mémoire de profil trace qui est l'utilisateur, et la mémoire procédurale trace comment une tâche est accomplie. C'est une séparation utile. La plupart des équipes commencent par l'historique de conversation, puis réalisent trop tard que la mémoire de tâche et la mémoire utilisateur ne devraient pas être fusionnées dans un journal indifférencié.
Où se positionne EverOS face au RAG naïf et aux fenêtres de contexte complètes
EverOS semble le mieux adapté aux équipes qui ont déjà une boucle d'agent et ont besoin d'un sous-système de mémoire plus petit qu'elles peuvent inspecter. Face au RAG naïf, le gain n'est pas seulement les vecteurs plus BM25. C'est la combinaison d'un état lisible par l'humain, d'un cadrage par métadonnées et d'une couche de mémoire procédurale. Face aux approches en contexte complet, le gain est la persistance et la sélectivité.
Mais les compromis sont réels. La vérité basée sur des fichiers est plus facile à inspecter, mais elle peut devenir plus difficile à gouverner si la nomenclature, les schémas et la discipline d'écriture sont négligents. SQLite maintient la stack compacte, mais vous devez quand même réfléchir aux limites de concurrence et aux procédures de récupération. LanceDB réduit la dispersion de la stack, mais vous vous engagez tout de même à faire fonctionner l'indexage et la qualité de la récupération au fil du temps.
Du côté positif, le runtime semble facile à tester en pilote. MarkTechPost mentionne Python 3.12+, une démo locale, un serveur FastAPI et des points de terminaison compatibles OpenAI qui peuvent être redirigés vers OpenAI, OpenRouter, vLLM, Ollama ou DeepInfra avec un simple changement d'URL de base. Cela réduit le coût d'intégration pour les équipes qui veulent tester la mémoire sans replateformer d'abord la couche modèle.
Ce que les équipes devraient vérifier avant d'adopter EverOS
Les chiffres de benchmark sont prometteurs mais pas encore suffisants pour prendre une décision seuls. L'article source cite des scores rapportés par EverMind de 93,05% sur LoCoMo, 83,00% sur LongMemEval, 93,04% sur HaluMem, et une latence de récupération p95 inférieure à 500 ms. Je considérerais cela comme un point de départ, pas comme une preuve. Exécutez les mêmes tests sur votre propre forme de charge de travail, surtout si vos données incluent de longs fils techniques, des limites de location strictes ou des sessions à forte écriture.
Ce que je surveillerais ensuite, c'est si les premiers adoptants publient des rapports d'échec aussi bien que des cas de succès. Si EverOS maintient la couche mémoire inspectable sous une charge multi-agents réelle, le design Markdown-first pourrait s'imposer. Sinon, l'idée pourrait tout de même influencer la manière dont les équipes construiront la prochaine génération de runtimes de mémoire pour agents, même si elles remplacent certaines parties de la stack.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation