SOLENTA : une mémoire commune pour tous vos agents de code
⏱️ Temps de lecture estimé : 4 minutes
https://github.com/currentbits/solenta
📌 SOLENTA est une application de bureau local-first qui pilote vos agents de code — Claude Code, Codex, Cursor, Kimi, Grok et OpenCode — et leur donne une mémoire partagée. Vous installez vos propres CLI, vous gardez vos abonnements, et chaque nouvelle session repart avec ce que les précédentes ont déjà appris.
Le problème est connu de quiconque fait tourner plusieurs agents sur un même dépôt. Chaque session démarre à blanc. Vous recopiez le même contexte, vous réexpliquez les mêmes décisions, et la dixième conversation n’en sait pas plus que la première — elle coûte juste plus cher. Solenta attaque ce point de front : un serveur de mémoire local est injecté automatiquement dans chaque session, sans qu’il y ait quoi que ce soit à câbler par agent.
Derrière, c’est du SQLite sur le disque, avec recherche plein texte et vectorielle, exposé en HTTP et MCP, en localhost uniquement et protégé par jeton. Un registre d’hypothèses transmet à la session suivante ce que la précédente a déjà écarté. Chaque entrée garde sa provenance et un score de confiance, avec des citations fichier:ligne, thread ou commit vérifiées contre l’arbre de travail courant : une entrée contredite est invalidée. Des embeddings repèrent les doublons proches et les contradictions, memory_distill condense les entrées brutes en notes de stratégie, et un index de symboles par dépôt est construit une fois puis glissé dans chaque prompt envoyé à un nouveau worker.
L’application ne se limite pas à la mémoire. Elle fait tourner les agents dans un vrai environnement de travail : un worktree Git par thread, un bouton « action suivante » qui enchaîne commit, push, PR, checks puis merge, des badges CI en direct, un itinéraire de revue qui classe le diff par risque. Les PR trop grosses sont refusées par défaut au-delà de 400 lignes, avec une proposition de découpage empilé. Les projets Jujutsu sont gérés, et les merge requests GitLab cohabitent avec les PR GitHub. Un pane terminal persiste dans le worktree du thread, et un navigateur embarqué sur votre serveur de dev permet de capturer une page directement dans le composeur.
Ce qui me convient, c’est la cohérence entre les morceaux. Le planboard, ce sont vos issues GitHub ou GitLab, pas une base locale : les agents les mettent à jour via gh, et vos coéquipiers voient le même tableau sans rien installer. La vérification n’est pas déclarative — un thread ne passe au vert que quand sa commande de vérification sort en 0, et elle est rejouée 24 heures après le merge. Les skills, serveurs MCP et paquets qu’un agent tente d’installer sont scannés localement et classés en sûr, douteux ou bloqué. Un diff qui sort du périmètre impliqué par la tâche est signalé comme blast radius.
Quelques repères avant d’essayer :
- 🧠 Mémoire partagée injectée dans toutes les sessions, SQLite local en HTTP + MCP
- 🌿 Un worktree Git par thread, avec enchaînement commit → push → PR
- 📋 Planboard branché sur vos issues GitHub ou GitLab, pas sur une base locale
- ✅ Un thread ne se termine que si sa commande de vérification sort en 0
- 🔒 Clés chiffrées, aucun cloud Solenta, seul trafic réseau : la vérification de mise à jour
Il faut être clair sur les limites. Le projet est jeune, bouge vite, et son auteur prévient lui-même : attendez-vous à des aspérités. macOS n’est servi qu’en Apple Silicon, sans build Intel ; Windows arrive en zip portable sans installateur, et Linux en tarball pour desktop glibc x64. Solenta ne fournit aucun CLI : il pilote ceux que vous avez déjà installés, et ne revend jamais de jetons.
Je trouve l’approche juste. La plupart des interfaces pour agents empilent des onglets ; Solenta leur ajoute une mémoire, un tableau et un verdict, sans jamais sortir de la machine. Si vous jonglez entre plusieurs agents sur un même dépôt, c’est exactement le chaînon qui manquait.
Sources
