La mémoire personnelle de Louis Cléon, en graphe, exposée à des assistants IA via un unique serveur MCP. Principe de conception : une erreur doit être détectable et corrigeable.
https://mnemo-mcp.sevenbirds.workers.dev/mcp
Mnemo stocke des assertions qualifiées — chaque mémoire porte sa provenance, sa confiance, sa sensibilité, sa discrétion et ses bornes temporelles — dans un graphe Neo4j, ancrées sur des entités (personnes, organisations, objets) et des domaines de vie. Les agents lisent en temps réel via huit outils MCP ; ils n'écrivent jamais directement : leurs propositions passent par une inbox qu'un curateur LLM, encadré par des gardes-fous déterministes, traite chaque nuit. Le journal des mémoires est append-only : une correction ne modifie rien, elle contrepasse — comme en comptabilité.
mnemo-mcp
Un seul fichier JavaScript, zéro dépendance. Serveur OAuth complet (DCR, PKCE, refresh) + les 8 outils MCP. Toute la sécurité vit ici : scopes, filtres de sensibilité et de discrétion, budget de réponse, journal de service. Le KV Cloudflare stocke clients, codes et tokens.proposed uniquement:Memory append-only + projection d'entités régénérable + journal :ServiceLog.needs_louis.Deux boucles distinctes : la boucle de lecture (un agent demande, réponse en millisecondes) et la boucle d'écriture (un agent propose → inbox → commit nocturne). Aucun agent ne touche le graphe directement — le single-writer n'est pas une règle, c'est une absence de route dans le code.
https://mnemo-mcp.sevenbirds.workers.dev/mcp. Rien à provisionner côté serveur : l'agent s'enregistre tout seul (Dynamic Client Registration).Toute ma mémoire est accessible en lecture et en écriture via le
connecteur MCP « mnemo ». Avant de répondre, demande-toi si tu dois la
consulter (mem_profile puis mem_recall / mem_context_pack) ; après avoir
répondu, demande-toi si tu as appris quelque chose à y écrire
(mem_remember / mem_correct). Ne te fie jamais à une autre mémoire.Chaque outil reçoit son propre couple access/refresh token, stocké côté serveur : la révocation se fait outil par outil, sans toucher aux autres.
| Scope | Sensibilité max servie | Usage type |
|---|---|---|
private-full | S3 — tout, y compris santé | L'assistant principal de Louis |
work-context | S2 — ajoute finances, famille, couple léger | Outils de travail de confiance |
assistant-standard | S1 — contexte courant | Assistants généralistes |
third-party | S0 — public uniquement | Services tiers |
| Outil | Rôle |
|---|---|
mem_profile | Carte du graphe : domaines, catalogue d'entités, règles universelles |
mem_context_pack | Pack de démarrage de conversation : règles applicables + faits pertinents, budget strict |
mem_recall | Recherche ciblée — plein texte + traversée du graphe depuis les entités reconnues |
mem_path | Chemin le plus court entre deux entités |
mem_remember | Proposer une nouvelle mémoire (→ inbox) |
mem_correct | Proposer une correction — contrepassation, jamais de modification (→ inbox) |
mem_retract | Proposer un retrait (→ inbox) |
mem_gates | Gouvernance : résultats de curation, arbitrages ouverts, doublons, revues d'ancres |
À chaque appel : authentification et résolution du scope, puis recherche de candidats (plein texte + expansion de graphe sur 1–2 sauts depuis les ancres reconnues — la raison d'être de Neo4j). Ensuite, les filtres durs s'appliquent avant tout scoring :
| Garantie | Mécanisme |
|---|---|
| Cloisonnement | sensitivity ≤ scope du token — une mémoire S3 n'atteint jamais un outil S1 |
| Discrétion | Deux axes distincts : une mémoire on_demand est retrouvable mais ne surgit jamais d'elle-même ; on_request_only exige d'être visée nommément |
| Fraîcheur | Bitemporalité lue : une assertion dont la validité est close n'est plus servie ; les retracted / superseded / proposed sont exclues |
| Sobriété | Budget dur : ≤ 12 mémoires par pack, ≤ 2 par ancre, ≤ 1 par événement |
| Neutralité | Classement = pertinence, puis provenance, puis confiance. La récence n'est qu'un départage ; ni longueur ni charge émotionnelle ne pèsent |
| Auditabilité | Chaque élément part avec son mem:id (contrat de citation) et chaque appel est journalisé en :ServiceLog pour l'audit mensuel |
mem_remember / mem_correct / mem_retract créent une proposition stampée proposed_by, et rien d'autre. Réponse immédiate : « proposé, en attente de curation ». Chaque nuit, le curateur :
| Étape | Nature |
|---|---|
| Classer (kind, sensibilité, salience, discrétion) et résoudre les entités contre le registre | LLM |
| Rejeter : salience dérivée, inférence santé/psy, entité hors registre… | code |
Dédoublonner (texte + ancres + domaines), router les conflits en arbitrage needs_louis | code |
| Invariants, réconciliation ledger ↔ projection, audit mensuel anti-saillance | code |
Le ledger ne se corrige jamais : une correction crée une nouvelle :Memory reliée par SUPERSEDES. La projection (entités et relations), elle, se régénère depuis le ledger — comme une comptabilité depuis ses écritures. Le résultat de chaque proposition (committed, duplicate, rejected, needs_louis, error) est consultable via mem_gates.
OAuth 2.1 complet (DCR + PKCE S256 + refresh tokens), tokens à durée de vie limitée en KV, révocation par outil. Le graphe n'a aucune exposition publique. Aucune assertion de santé ne peut être inférée par un agent ou par le curateur : elle n'entre que sur déclaration directe attestée.