Plugin d’architecture génératrice d’agents qui résout le bruit et la décroissance de la mémoire des agents (open source)

La plupart des configurations d’agents gèrent mal la mémoire. Soit elles écrivent tout directement dans la mémoire à long terme, qui se remplit alors de bruit et de contradictions, soit elles oublient tout dès qu’une session se termine et il faut repartir de zéro à chaque fois. Je publie une architecture d’agents open source conçue avec une attention particulière portée à la mémoire (Apache-2.0). La même configuration fonctionne telle quelle dans Claude Code, Codex et Gemini CLI, sans être liée à un outil particulier.
L’idée centrale est que l’agent ne doit pas être un prompt, mais un repo. Le résultat prend la forme de vrais fichiers (AGENTS.md, agents/, skills/, .agentlas/), que les trois runtimes peuvent tous lire, et vous pouvez continuer à utiliser le modèle que vous utilisiez déjà. Après une installation en une ligne, il suffit de dire ce que vous voulez pour qu’un team d’agents installable soit généré en bloc.
3 modes générés

Agent unique : un worker avec des skills, des règles de mémoire, des adaptateurs de runtime et des étapes de validation. Sans le faire évoluer en team, on peut aussi lui ajouter des boucles de self-evolution et de research-refresh.
Team multi-agents : orchestrateur/HQ, PM Soul, Memory Curator, Policy Gate, workers, eval judge, passerelles QA/preuves, ainsi que les handoffs entre eux. C’est le mode « crée-moi une entreprise pour ce workflow ».
Repackaging : organise vos agents ou workspaces existants (Claude/Codex/local) en package portable. Il inclut aussi un plugin public et une installation en une ligne, tout en retirant les chemins locaux, secrets et logs privés pour rendre la publication sûre.

Comment la mémoire fonctionne réellement (il ne s’agit pas d’une simple liste de rôles, mais de fichiers inclus dans le résultat)

Mémoire basée sur des tickets : rien n’est écrit directement dans la mémoire à long terme. Quand un worker émet un bloc ## Memory Events, il est d’abord accumulé dans memory-tickets.jsonl sous forme de tickets (id, scope, trust label, evidence, status), puis seulement promu ensuite.
Memory Curator : examine les tickets avant le commit et consigne les décisions dans le registre curator-decisions. La mémoire ne se remplit donc pas de bruit ni de contradictions.
PM Soul : gère la continuité au niveau du projet. Il conserve les intentions, les décisions et les tâches non résolues, ce qui permet de se souvenir non seulement de « quelle décision a été prise », mais aussi de « pourquoi cette décision a été prise ».
Policy Gate : la mémoire partagée par l’équipe doit passer une étape d’approbation avant d’être promue. Cela empêche un seul agent de contaminer tout le contexte.
Self-evolution vérifiée : l’agent peut créer de nouvelles skills et proposer lui-même des modifications, mais les nouvelles skills ne sortent que comme candidates et ne peuvent être rappelées comme first-class qu’après être passées par un registre de preuves d’essai, une revue du Curator et une approbation de la politique. L’agent peut donc s’améliorer sans se dégrader silencieusement. Les auto-modifications suivent aussi une logique proposal-first, sans écrasement non autorisé.
Scan de sécurité pour la publication : avant de publier un package, il bloque les chemins machine, tokens, JSON de service account et les formats de secrets courants.