MIRA : mémoire et identité intégrées pour tes agents LLM

J'ai créé MIRA après avoir répété trop souvent les mêmes décisions à mes agents. Une session se terminait, j'en ouvrais une autre, et il fallait rappeler pourquoi le projet utilisait telle base de données, quelle convention suivre ou quel bug ne surtout pas réintroduire.

Le modèle n'avait pas vraiment oublié. Il n'avait simplement plus accès à l'information.

MIRA garde cette mémoire sur la machine et ne remet dans le contexte que ce qui peut servir à la question en cours. Il peut aussi conserver les habitudes de travail et les contraintes qui doivent rester stables quand le client ou le modèle change.

Quand chaque session repart de zéro

L'historique d'une conversation n'est pas une mémoire de projet. Il devient trop long, coûte des tokens et finit par mélanger les décisions importantes avec les essais abandonnés.

Dans mon usage, les mêmes ennuis revenaient :

je répétais des choix techniques déjà tranchés ;
l'agent retrouvait un détail, mais pas la raison qui allait avec ;
un nouveau modèle répondait avec un style différent et oubliait certaines contraintes de travail.

Une mémoire utile doit retrouver une décision sans envoyer tout l'historique au modèle. Elle doit aussi permettre de vérifier et de corriger ce qui a été enregistré.

Ce que MIRA conserve

MIRA est un serveur MCP local et open source écrit en Go. Il fournit des outils pour enregistrer, rechercher, rappeler et modifier des souvenirs de travail.

Un souvenir est conservé sous plusieurs formes :

Niveau	Contenu	Usage
T0 : verbatim	Le texte d'origine	Relire le détail exact
T1 : fingerprint	Les faits, entités et décisions	Résumer avec peu de tokens
T2 : embedding	Une représentation vectorielle	Retrouver les souvenirs proches

MIRA commence par la forme compacte et remonte au texte original quand il apporte une précision utile. Une décision peut donc revenir dans une nouvelle session sans recopier la conversation entière.

Retrouver une décision sans charger tout le projet

Le rappel tient compte de la question, de la récence, des doublons et du budget de tokens. Ce budget est pratique pour éviter qu'une mémoire persistante ne devienne une deuxième fenêtre de contexte pleine de bruit.

Si je demande pourquoi PostgreSQL a été retenu pour une version du projet, je veux retrouver la décision et ses raisons, pas toutes les discussions sur les bases de données :

{
  "tool": "mira_recall",
  "arguments": {
    "query": "Pourquoi PostgreSQL pour la v2 ?",
    "wing": "mon-projet",
    "budget": 1200
  }
}

La recherche croise plusieurs signaux. Si l'index vectoriel est indisponible pendant une reconstruction, le stockage local garde un chemin de secours pour continuer à interroger les souvenirs.

Garder les souvenirs dans le bon projet

J'organise la mémoire avec des wings et des rooms. Un wing peut correspondre à un dépôt ou à une équipe. Une room sépare ensuite les décisions, les incidents et les préférences générales.

Pour enregistrer une décision :

{
  "tool": "mira_store",
  "arguments": {
    "content": "On garde PostgreSQL pour la v2 : transactions, JSONB et compétences déjà présentes dans l'équipe.",
    "wing": "mon-projet",
    "room": "decisions",
    "type": "decision"
  }
}

Cette organisation évite de faire remonter une règle propre à un dépôt dans une autre conversation. Elle rend aussi les exports, les sauvegardes et les suppressions ciblées plus simples.

La continuité de l'agent

Certaines informations décrivent le projet. D'autres décrivent la manière de travailler : répondre directement, respecter un format, rester concis ou suivre une méthode de revue.

MIRA peut conserver cette continuité avec le reste de la mémoire. Elle est versionnée, rappelable et corrigeable au même endroit que les décisions techniques. Quand je change de modèle, je peux donc rappeler les contraintes de collaboration sans prétendre obtenir deux fois la même réponse.

Cela ne bloque pas l'évolution du comportement. Cela me donne plutôt un point de comparaison pour voir ce qui a changé et décider si le nouvel agent reste adapté au projet.

Installer MIRA

Avec Go :

go install github.com/benoitpetit/mira/cmd/mira@latest

Dans le projet qui doit porter sa mémoire :

mira init
mira doctor

init crée le stockage local. doctor vérifie la base, les migrations, l'index et la configuration.

Pour le connecter à Codex :

mira setup --client codex --automatic-memory --memory-wing mon-projet

Ou à Claude Code :

mira setup --client claude-code --scope local --automatic-memory --memory-wing mon-projet

Le démarrage local en stdio ressemble à ceci :

mira --config .mira/config.yaml start

Les réglages à surveiller

La configuration générée suffit pour commencer. Je vérifie surtout le chemin de stockage et le budget de rappel :

storage:
  path: ".mira"
  sqlite:
    journal_mode: WAL
    encryption_key: "" # fournir la clé par variable d'environnement

embeddings:
  current_model: "sentence-transformers/all-MiniLM-L6-v2"
  dimension: 384

allocator:
  default_budget: 4000

agent_memory:
  enabled: true

mcp:
  transport: "stdio"

Le dossier .mira peut contenir des conversations et des décisions privées. Je le garde hors du dépôt et je protège les sauvegardes. Une base PostgreSQL peut convenir à plusieurs processus ; pour un poste de travail, SQLite reste plus simple à déplacer et à relire.

Mon usage

Je me sers de MIRA comme d'un carnet de décisions qui sait chercher. Je n'y copie pas toutes mes conversations. Les wings séparent les projets et le budget m'oblige à limiter ce qui revient dans le contexte.

La mémoire devient vraiment utile quand elle permet de reprendre un travail sans réexpliquer les raisons d'un choix. Je garde quand même le contrôle : les commandes de diagnostic, les exports, les mises à jour et les suppressions doivent rester accessibles. Une information fausse ne doit pas continuer à influencer l'agent simplement parce qu'elle a été enregistrée une fois.

J'ai détaillé les niveaux T0/T1/T2 et le fonctionnement du rappel dans l'article consacré à la construction de MIRA. Ici, l'idée est plus directe : MIRA évite à l'agent de redécouvrir le même projet à chaque session.

Pour aller plus loin

Si tu testes le projet, ouvre une issue avec un cas de rappel concret. On voit tout de suite ce que MIRA retrouve, ce qu'il ignore et si le budget est bien choisi.

Et si mes outils te sont utiles, tu peux aussi me soutenir via Liberapay ou Buy Me a Coffee.

Article co-écrit avec l'IA · Images générées avec l'IA.