FAVA Trails : une mémoire partagée native Git pour les agents IA (MCP)

À qui cela s'adresse

FAVA Trails (Federated Agents Versioned Audit Trail) est un système de mémoire natif Git exposé aux agents IA via MCP : les idées, décisions et observations produites par les agents sont écrites sous forme de fichiers Markdown avec frontmatter YAML dans un dépôt Git de données que vous contrôlez, et non dans une boîte noire hébergée sur les serveurs d'autrui. Le système sépare les « brouillons » des « observations visibles par tous les agents » en deux niveaux, avec une porte de promotion entre les deux ; les agents ne voient en temps normal que les outils de mémoire eux-mêmes et ne touchent jamais aux commandes de gestion de versions — la version est gérée par le moteur au sein du dépôt, et tout l'historique reste consultable dans les commits.

• Profil adapté : équipes ou personnes qui veulent que plusieurs agents partagent et accumulent une mémoire de travail — par exemple conserver les conclusions d'une investigation technique ou le contexte des décisions d'une session à l'autre en observations réutilisables ; utilisateurs qui veulent une mémoire versionnée, traçable et directement consultable sous forme de fichiers ; personnes qui gèrent déjà leurs actifs avec Git et ne s'opposent pas à entretenir un dépôt de données de plus.
• Prérequis : pip doit pouvoir installer en local ; la configuration doit fournir le chemin du dépôt de données FAVA_TRAILS_DATA_REPO ; pour promouvoir un brouillon en observation visible par tous les agents, il faut configurer une clé API OpenRouter.
• À peser : si vous ne voulez pas entretenir de dépôt de données ni demander de clé OpenRouter, réfléchissez à deux fois — le parcours central de la mémoire partagée entre agents dépend des deux à la fois.
• Inconnu : les preuves ne précisent pas quels clients MCP sont pris en charge, quelles versions d'OS et de Python sont requises, ni si le moteur de stockage Jujutsu (JJ) doit être installé séparément.

Première tentative en 3 minutes

Il n'y a qu'un chemin principal recommandé : installer le moteur depuis PyPI, puis l'enregistrer dans la configuration des serveurs du client MCP. Deux prérequis : décidez d'abord de l'emplacement du dépôt de données, car FAVA_TRAILS_DATA_REPO dans la configuration y pointe ; et pour aller jusqu'à l'étape de promotion, il faut une clé API OpenRouter.

Première étape, installer ce serveur MCP sans état sous licence Apache-2.0 :

pip install fava-trails

Deuxième étape, ajouter l'extrait d'enregistrement officiel à la configuration du client et remplacer le chemin du dépôt par votre emplacement réel :

"fava-trails": {
  "command": "fava-trails-server",
  "env": {
    "FAVA_TRAILS_DATA_REPO": "/path/to/fava-trails-data",
    "OPENROUTER_API_KEY": "sk-or-v1-..."
  }
}

Troisième étape, faire exécuter une seule fois par l'agent l'écriture à la portée minimale : enregistrer une observation comme brouillon avec save_thought.

save_thought(trail_name="myorg/eng/my-project", content="My finding about X", source_type="observation")

Signal de réussite : le brouillon apparaît dans le répertoire drafts/ du dépôt de données. Qualifiez bien l'opération : cette étape est une écriture locale, le fichier atterrit dans votre propre dépôt, ce n'est pas une consultation en lecture seule ; aucune méthode officielle de suppression ou d'annulation d'un brouillon n'est documentée, écrivez donc un contenu inoffensif au premier essai. Côté moteur, Jujutsu (JJ) sert de moteur de stockage aux côtés de Git en mode colocate ; le dépôt reste un dépôt Git standard, et vous n'avez à toucher à aucune commande de gestion de versions à cette étape. Notez aussi la frontière de la clé API OpenRouter : elle figure déjà dans ce modèle de configuration officiel, et le tableau officiel précise qu'elle est requise pour propose_truth, alimentant les revues LLM du Trust Gate via OpenRouter ; un premier essai peut s'arrêter à l'étape du brouillon, inutile d'enchaîner sur une promotion.

Cas d'usage

Cas un : conserver la conclusion d'une investigation comme mémoire de projet. Scénario : un agent vient de terminer une investigation et sa conclusion mérite d'être réutilisée lors des sessions suivantes. Marche à suivre : appeler save_thought avec trail_name, content et source_type — l'appel d'exemple officiel ci-dessus fonctionne tel quel. Résultat attendu : un fichier brouillon apparaît dans drafts/, le contenu n'atterrit que dans votre dépôt, les autres agents ne le voient pas encore et personne n'est impacté ; le brouillon est un fichier ordinaire, que l'on peut ouvrir directement dans le dépôt.

Cas deux : promouvoir un brouillon vérifié en observation partagée, puis vérifier par recherche. Scénario : une observation a été validée et vous voulez que tous les agents suivants la retrouvent. Marche à suivre : confirmez d'abord que la clé API OpenRouter est valide, appelez propose_truth(trail_name="myorg/eng/my-project", thought_id=thought_id) pour promouvoir le brouillon vers observations/, puis interrogez avec recall(trail_name="myorg/eng/my-project", query="X"). Résultat attendu : recall retrouve l'idée promue, et les autres agents connectés au même dépôt de données la retrouvent avec la même requête. Point de contrôle : le résultat de la promotion est visible par tous les agents et aucune annulation officielle n'est documentée — vérifiez que le contenu mérite d'être partagé avant d'exécuter ; pousser la modification vers un dépôt distant est une action distincte, qui demande un appel séparé à l'outil sync ou à jj git push.

Limites d'utilisation

• Nature lecture/écriture : save_thought crée un brouillon dans le dépôt de données, et propose_truth promeut un brouillon vers observations/, visible par tous les agents — ce sont deux écritures ; recall recherche les idées promues. Les écritures ont lieu dans votre propre dépôt, et la promotion atterrit d'abord en local ; pousser vers un distant doit se faire séparément via l'outil MCP sync ou jj git push, et la synchronisation reste votre décision. Aucun chemin officiel d'annulation ou de suppression n'existe — ne considérez pas une écriture comme une opération toujours réversible.
• Identifiants et configuration : FAVA_TRAILS_DATA_REPO désigne l'emplacement du dépôt de données, et OPENROUTER_API_KEY alimente la revue LLM lors de la promotion ; tous deux figurent dans la section env du modèle de configuration officiel, et la documentation officielle dit explicitement que cette dernière est requise pour propose_truth. Le fonctionnement de save_thought et recall sans cette clé n'est pas documenté dans les preuves.
• Exécution et stockage des données : le moteur de stockage est Jujutsu (JJ), en mode colocate aux côtés de Git ; le dépôt reste un dépôt Git standard, et GitHub comme la CI/CD voient des commits normaux. Tout le contenu vit sous forme de fichiers Markdown avec frontmatter YAML dans le dépôt que vous contrôlez.
• Points non confirmés : quotas de capacité, limites de taille en multi-dépôts, détails de confidentialité et de localisation des données sont absents des preuves ; les critères d'évaluation du Trust Gate et la gestion des échecs ne sont pas décrits non plus, pas plus qu'il n'est dit si jj doit être installé séparément ni quels clients et versions de Python sont pris en charge. Ne lisez pas « aucune documentation vue » comme « aucun risque » — évaluez ce que vous écrivez en partant du principe que cela restera durablement dans votre dépôt.