Ça fait un moment que je planche sur des systèmes d’agents à grande échelle, entre des projets clients et mes propres systèmes expérimentaux.
Un mode de panne récurrent : la plupart des piles de « mémoire d’agent » sont en fait des architectures centrées sur des bases de données qui jouent à être de la mémoire.
Ça marche au début.
Mais ensuite, le système grossit, devient plus concurrent, gère plus d’états et devient plus agentique. C’est là que les fissures apparaissent : couplage caché à des services externes, propriété ambiguë lors d’écritures concurrentes, frontières floues entre l’état canonique et la projection de recherche, et des scénarios de récupération ou de débogage presque impossibles à analyser proprement.
Un noyau de mémoire durable
Kilo est un type de couche mémoire différent.
Je l’ai écrit comme un SDK Go intégrable pour un état de mémoire durable et auditable dans des systèmes multi-agents. Plus précisément, c’est un noyau de mémoire à propriétaire unique et structuré en journal, avec des couches de projection reconstruisables.
Cette frontière est délibérée.
Kilo conserve la vérité canonique sous forme de flux de mutations en ajout seul, matérialise l’état actuel à partir de ce journal, et traite la recherche et les index comme des projections secondaires avec une sémantique explicite de fraîcheur et de watermark.
Les choix d’ingénierie fondamentaux sont intentionnellement conservateurs : sémantique de stockage à propriétaire unique, avec ErrStoreLocked plutôt qu’une ambiguïté multi-écrivain ; enregistrements de métadonnées compacts avec stockage du corps long format par morceaux ; hiérarchie et provenance comme primitives de premier ordre ; points de contrôle du projecteur et obsolescence visible ; et une API privilégiant le SDK pkg/kilo, avec le CLI/HTTP comme adaptateurs d’inspection optionnels plutôt que comme runtime principal.
Garder la récupération au-dessus du substrat
Ce dernier point est important.
Kilo a une frontière étroite : il fournit un substrat durable, en ajout seul, pour un état de type mémoire.
Les frameworks d’agents, les politiques de workflow, le middleware d’authentification, l’infrastructure de routage et la recherche vectorielle vont au-dessus de cette couche, pas dedans.
L’architecture n’est pas une « infrastructure magique prête pour l’IA ». C’est une couche de stockage durable conventionnelle avec des propriétés de récupération explicites, conçue pour des systèmes où la mémoire doit survivre à la concurrence, à l’inspection, au retard de projection et aux workflows d’agents de longue durée.
Alors, pour répondre directement à la question habituelle :
Est-ce que Kilo est une base de données vectorielle ?
Non.
Les vecteurs ne sont pas la source de vérité. Les vecteurs sont une surface de projection pour la récupération. L’autorité canonique réside dans l’historique durable des mutations et l’état matérialisé.
Pour les systèmes d’agents gourmands en récupération, le gain se trouve dans cette frontière.
La durabilité et le déterminisme vont dans le substrat. La stratégie de requête va dans une couche remplaçable au-dessus.
Cette séparation change le mode de panne.
Au lieu de demander à la couche de recherche de se comporter comme de la mémoire, Kilo permet à la mémoire de rester durable, auditable et rejouable, tandis que la récupération reste assez flexible pour évoluer.
C’est la ligne architecturale dont j’avais systématiquement besoin dans des systèmes réels.
Alors, je l’ai construite.
Si vous travaillez sur des agents, des systèmes gourmands en récupération ou des infrastructures à long horizon, j’espère que vous trouverez ça utile :