EverOS : une mémoire d'agent en Markdown, avec ses limites

Le problème visé : une mémoire qui survit au changement d'outil

Un agent qui travaille dans un assistant de code, puis dans une application métier, puis dans un workflow automatisé, perd son contexte à chaque changement de plateforme. Les bibliothèques de mémoire d'agent classiques stockent leur état dans une API, une base vectorielle, un graphe ou un tableau de bord. Le README d'EverOS range ces approches dans une colonne intitulée Other Agent Memory Libraries et leur oppose des fichiers .md canoniques, lisibles, éditables, comparables et versionnables avec Git.

La cible est explicite : développeurs et makers qui utilisent Python. Le projet se présente comme une bibliothèque et un runtime de mémoire local-first, avec une licence Apache-2.0. La promesse de portabilité ne vient pas d'un connecteur universel mais du format de stockage lui-même. Si la source de vérité est un fichier Markdown, n'importe quel outil capable de lire un fichier peut s'y brancher, y compris un éditeur de texte.

Deux pistes séparées : épisodes d'un côté, compétences de l'autre

EverOS distingue deux surfaces de premier niveau. Côté utilisateur, les episodes et le profile. Côté agent, les cases et les skills. Le README insiste sur le fait que ces deux pistes sont distinctes et non fusionnées dans un historique de conversation unique. C'est un choix de conception qui a des conséquences pratiques : on peut faire évoluer le profil d'un utilisateur sans toucher aux compétences de l'agent, et inversement.

La récupération est décrite comme orthogonale. La recherche peut se faire par user_id, agent_id, app_id, project_id et session_id. Ces identifiants ne forment pas une hiérarchie imposée, ce qui permet de croiser les axes. Une même mémoire peut être retrouvée par projet sans être filtrée par application. Les bibliothèques qui raisonnent en espace de noms, en tenant ou en fil de discussion obligent souvent à choisir un axe unique au moment de l'écriture.

S'y ajoute une Knowledge Wiki : des pages Markdown adossées à des sources, avec taxonomie, API CRUD et recherche par sujet. Le README précise que ces pages sont éditables et reliées aux fichiers d'origine, contrairement aux wikis enfermés dans un tableau de bord.

Trois couches locales, et ce qu'elles impliquent

L'architecture tient en trois éléments : Markdown, SQLite et LanceDB. Le README affirme qu'aucun MongoDB, Elasticsearch ou Redis n'est nécessaire. C'est l'argument le plus concret du projet. Une pile de mémoire qui tient dans un répertoire utilisateur se sauvegarde, se copie et s'inspecte avec les outils déjà présents sur la machine.

Le flux décrit par la démonstration est ingest, extract, index, recall. Les conversations, fichiers et trajectoires entrent, sont extraits vers du Markdown, indexés dans SQLite et LanceDB, puis rappelés. Le README mentionne un cascade watcher : si vous éditez un fichier .md directement, la synchronisation d'index se déclenche. C'est ce qui rend l'édition manuelle crédible plutôt que théorique.

Un point mérite d'être dit franchement : SQLite et LanceDB ne jouent pas le même rôle, mais le README ne détaille pas la répartition exacte entre recherche par mots-clés et recherche vectorielle. Il indique seulement qu'avec la configuration minimale, la recherche par mots-clés fonctionne. La couche LanceDB est présente dans la pile, son activation dépend de la configuration d'embedding, non documentée dans l'extrait fourni.

Installation : quatre commandes et un fichier TOML

Les prérequis annoncés sont Python 3.12 ou supérieur et une clé API OpenRouter. L'installation se fait avec uv pip install everos, ou pip install everos.

Avant toute clé, la démonstration autonome se lance avec everos demo. Le README précise qu'aucune clé ni serveur n'est requis, et qu'on peut saisir une information à mémoriser puis poser une question liée pour observer le trajet ingest, extract, index, recall. Si le dépôt a été cloné sans environnement activé, la commande équivalente est uv run everos demo.

L'initialisation passe par everos init. Elle crée ~/.everos/everos.toml et ~/.everos/ome.toml. Le fichier everos.toml contient un bloc [llm] avec model, api_key et base_url. Le README indique que le modèle et l'URL OpenRouter générés sont déjà corrects et qu'il suffit de remplacer la valeur vide de api_key. Pour changer l'emplacement de la mémoire, everos init --root <path>, en repassant le même --root aux commandes suivantes.

Le serveur se lance avec everos server start, puis se vérifie depuis un second terminal avec curl http://127.0.0.1:8000/health. La réponse attendue contient "status":"ok". Selon le README, capabilities.llm vaut true avec cette configuration à une clé, tandis qu'embedding et rerank restent false jusqu'à configuration supplémentaire.

La recherche sémantique n'est pas dans l'installation par défaut

C'est la limite la plus nette du matériel fourni. Après everos init, embedding et rerank sont à false. La recherche annoncée pour ce niveau, que le README appelle Tier 1, est une recherche par mots-clés. Le document s'interrompt d'ailleurs au milieu de la phrase expliquant comment activer ces capacités : la procédure de configuration des embeddings n'est pas disponible dans l'extrait.

Quiconque a besoin de similarité sémantique dès le premier jour devra donc chercher cette configuration dans la documentation en ligne, à l'adresse docs.evermind.ai, et non dans le README. C'est un point à vérifier avant de s'engager.

Deuxième limite : la configuration par défaut dépend d'OpenRouter. Le modèle openai/gpt-4.1-mini et l'URL base_url pointent vers un service distant. Le stockage est local, l'appel de modèle ne l'est pas. Le terme local-first décrit le lieu de conservation des données, pas l'absence de réseau. Une équipe qui travaille hors ligne ou qui refuse tout appel sortant devra examiner ce point de près.

Troisième limite : la réflexion, présentée comme une évolution hors ligne de la mémoire qui fusionne des clusters d'épisodes et affine profils et compétences entre les sessions, n'est décrite que par cette phrase. Aucun déclencheur, aucune commande, aucun paramètre n'apparaît dans le matériel fourni. On ne peut donc pas dire quand elle s'exécute ni comment la contrôler.

Ce qu'EverOS fait différemment d'une base vectorielle

Prenons une alternative réelle : une base vectorielle adossée à un serveur, du type de celles que le README range dans la colonne opposée. Dans ce modèle, vous écrivez via un SDK ou une API, l'état vit dans la base, et vous inspectez le contenu avec un tableau de bord ou une requête. Corriger une entrée erronée signifie écrire du code.

EverOS déplace la source de vérité vers le fichier. Vous ouvrez le .md, vous corrigez la phrase, le cascade watcher resynchronise les index. La différence n'est pas cosmétique : elle change qui peut intervenir. Un rédacteur technique ou un utilisateur peut ajuster une mémoire sans passer par l'équipe qui maintient l'intégration. En contrepartie, vous héritez des problèmes des fichiers : conflits de fusion, doublons, absence de transactions entre le Markdown et les index. Le README ne traite pas ces cas.

Autre différence : la séparation entre piste utilisateur et piste agent. Une base vectorielle classique range tout dans un même espace et compte sur les métadonnées pour trier. EverOS en fait deux surfaces nommées, avec des fichiers distincts. C'est plus lisible, c'est aussi plus de structure à maintenir.

Licence, maintenance et coût de mise à jour

Le dépôt est publié sous Apache-2.0. Cette licence est permissive : elle autorise l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de copyright et le texte de la licence, et elle inclut une concession de brevet. Elle n'impose pas de publier vos modifications. Ce paragraphe décrit la licence, il ne constitue pas un avis juridique.

Le rythme de publication est soutenu : v1.3.1 le 8 septembre 2026, v1.3.0 la veille, v1.2.3 le 7 août 2026. Deux versions en deux jours, puis un mois de calme. Le numéro de correctif indique des changements limités, mais l'écart entre 1.2.3 et 1.3.0 signale une évolution de fond. Le dépôt n'est pas archivé et le dernier envoi de code date du 9 septembre 2026.

Cette cadence a un coût concret. Un format de mémoire qui évolue entre mineures peut demander une migration des fichiers .md ou des index SQLite et LanceDB. Le matériel fourni ne mentionne aucune commande de migration, aucun numéro de version de schéma, aucune note sur la compatibilité ascendante. Avant de confier des mois d'historique à ce format, c'est le point à élire : que se passe-t-il lors d'une montée de version majeure sur un répertoire ~/.everos existant ?

Conclusion éditoriale

EverOS convient aux développeurs Python 3.12+ qui veulent une mémoire d'agent lisible et versionnable dans Git, éditable à la main, sans MongoDB ni Redis. Il ne convient pas à qui attend une recherche sémantique dès l'installation : embedding et rerank restent à false après everos init, et le README ne documente pas la configuration correspondante. Avant d'adopter, lancez everos demo sans clé, puis vérifiez le contenu réel de ~/.everos/everos.toml et le schéma des fichiers .md produits.

Sources officielles

1. EverMind-AI/EverOS on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases