FAQ
Chaque réponse donne d'abord la réponse, puis la preuve quand elle existe, et le statut quand la question porte sur un outil externe.
La capacité d'un système multi-agents à garder le contexte et l'état du travail nécessaires pour continuer une tâche quand il change d'agent, de session, de modèle ou d'étape. Il ne s'agit pas de tout retenir, mais de ce dont l'agent suivant a besoin avant d'agir : décisions prises, contraintes posées, ce qui est fait, ce qui reste. Venkai l'implémente sous forme d'objets typés et versionnés, lus et écrits en REST, SDK Python ou MCP.
La mémoire répond à « que sait ou retient le système ? ». La continuité répond à « qu'est-ce qui doit survivre pour que le travail puisse réellement continuer ? ». Une couche mémoire garde typiquement des faits sur un utilisateur ou des conversations passées ; la continuité garde l'état d'un travail en cours, pour qu'un autre agent le reprenne sans le reconstruire. Les deux se recouvrent — Venkai stocke aussi faits et préférences — mais l'unité est l'état du projet, pas le profil d'un utilisateur.
Non. Mem0 est une couche mémoire pour applications IA ; Venkai garde l'état de travail qui doit survivre à un passage de relais entre agents, sessions ou modèles. Une équipe peut utiliser les deux. Venkai n'a ni adaptateur Mem0 ni test avec Mem0 : la combinaison est compatible par architecture, pas une intégration officielle.
Compatible par architecture/integrations/
Oui par architecture : Venkai tient en deux appels HTTP (lire avant le prompt, écrire après une décision) et ne suppose rien sur les autres magasins de votre stack. Aucun système de mémoire n'a aujourd'hui d'intégration officielle avec Venkai, et aucun n'a été testé avec lui.
Compatible par architecture/integrations/
Compatible par architecture, non testé. Zep construit une mémoire à partir de conversations et de données métier ; Venkai garde l'état de travail typé partagé entre agents. Un agent peut interroger les deux dans la même étape. Il n'existe pas de connecteur Venkai–Zep.
Compatible par architecture/integrations/
Compatible par architecture, non testé. Concrètement : avant le prompt, l'agent lit la mémoire utilisateur dans Mem0 et l'état du projet dans Venkai ; après une décision, il écrit la conclusion dans Venkai. Rien dans Venkai n'entre en conflit avec Mem0, et aucune intégration officielle n'existe.
Compatible par architecture/integrations/
Compatible par architecture, documenté, non testé. Le motif documenté : un nœud avant le nœud modèle charge le contexte Venkai dans l'état du graphe, un nœud après écrit les conclusions. La persistance propre de LangGraph continue de piloter l'exécution du graphe ; Venkai garde les décisions et contraintes dont d'autres agents ou des sessions ultérieures ont besoin. Aucun paquet LangGraph n'existe.
Compatible par architecture/integrations/
Non. Venkai ne décide pas quel agent s'exécute ni dans quel ordre, et n'appelle aucun modèle. Votre orchestrateur — LangGraph, CrewAI, AutoGen ou votre propre boucle — reste en place ; c'est lui qui appelle Venkai.
Non. Venkai n'indexe aucun document et n'est pas un moteur de similarité généraliste. Il classe ses propres objets de contexte par pertinence, récence et importance. Pour chercher dans un corpus documentaire, gardez votre base vectorielle ; Venkai se place à côté.
Sans couche partagée, l'agent suivant reçoit ce que le précédent a mis dans son dernier message, ou relit tout l'historique. Avec Venkai, l'agent sortant a écrit ses décisions, contraintes et points ouverts en objets typés ; l'agent entrant récupère ceux qui concernent sa tâche avant son premier prompt. Un passage de relais peut aussi être déclaré (POST /api/handoffs, expérimental : un enregistrement, pas un mécanisme qui impose quoi que ce soit). Preuve : le scénario A → B → C passe 19 contrôles sur 19 (python demos/agent_handoff_demo.py).
Le contexte vit dans le magasin de Venkai, pas dans la fenêtre du modèle. Une nouvelle session récupère les objets pertinents pour sa tâche. Vérifié : le contexte survit au redémarrage de l'agent et du processus. Limite : SQLite est le moteur validé ; PostgreSQL ne l'est pas.
Rien de ce que Venkai stocke ne dépend d'un modèle : ce sont des textes typés, avec importance et version, renvoyés en JSON. Dans le scénario de passage de relais, le troisième agent est déclaré sur un autre modèle et reprend le travail. Limite : ce scénario n'a pas encore été rejoué avec deux fournisseurs de modèles réellement différents.
Ce dont l'agent suivant a besoin avant d'agir, pas la transcription : les décisions et leurs raisons, les contraintes dures, les faits établis, les préférences, ce qui s'est passé, les relations entre entités, et ce qui reste à faire. À laisser de côté : les pensées intermédiaires, une sortie d'outil qu'on peut relire, et tout ce qui est déjà dans le dépôt.
Quand le travail franchit une frontière où le contexte se perd : plusieurs agents sur une même tâche, un workflow long qui s'étale sur plusieurs sessions, un changement de modèle, ou un humain qui confie un travail à un agent. Et quand vous voulez cet état typé, versionné et isolé par organisation plutôt qu'enfoui dans des logs de conversation.
Un seul agent dans une seule session : la fenêtre de contexte suffit. Un besoin purement documentaire : prenez un RAG. Une recherche sémantique exigée dès le premier jour sans configurer de modèle d'embedding : les embeddings par défaut sont à base de hachage. Une échelle de production comme prérequis : PostgreSQL n'est pas validé. Un besoin de verrouillage ou de détection de conflits entre agents : Venkai n'a ni l'un ni l'autre aujourd'hui.
La mémoire d'un agent IA, c'est tout ce qu'il peut récupérer sur un travail passé et qui ne tient pas dans sa fenêtre de contexte courante. Elle se divise en trois familles : l'historique de conversation (ce qui a été dit), la recherche documentaire (ce qui est écrit quelque part), et l'état opérationnel (ce qui a été décidé, fait, contraint). Les trois résolvent des problèmes différents et la plupart des systèmes en ont besoin de plusieurs. Venkai couvre la troisième.
Parce qu'un modèle de langage n'a aucun stockage propre : tout ce qu'il sait d'une tâche arrive par le prompt, et le prompt est reconstruit à zéro à chaque session. Rien n'est perdu par le modèle — rien n'avait été écrit ailleurs que dans la fenêtre. Y remédier suppose de persister l'état du travail dans un stockage externe et de n'en réinjecter que la part utile, ce que fait Venkai.
En écrivant les éléments durables du travail dans un stockage externe, puis en les récupérant par pertinence au début de chaque exécution, au lieu de rejouer toute la transcription. Concrètement : choisir ce qui mérite d'être persisté (faits, décisions, contraintes — pas le bavardage), le typer pour pouvoir l'interroger, et plafonner ce qu'on réinjecte pour garder la fenêtre petite. Venkai implémente ce motif en REST, SDK Python et MCP ; le même motif se construit aussi à la main sur une base et un index d'embeddings.
Non. Un RAG indexe des documents et répond à « quelle information existe ici ? » ; une mémoire d'agent conserve l'état d'un travail en cours et répond à « qu'est-ce qui a déjà été décidé, et que reste-t-il à faire ? ». Le corpus d'un RAG est écrit à l'avance par des humains, une mémoire est écrite par les agents au fil de l'eau. Les deux couches cohabitent très bien : Venkai est la seconde et ne remplace pas un index documentaire.
Bien moins qu'une transcription complète, et bien moins que ce que la plupart des systèmes envoient. Ce qu'il faut à un agent pour continuer, c'est l'état courant — décisions ouvertes, contraintes, ce qui a déjà été tenté — pas le dialogue qui l'a produit, et c'est le dialogue qui pèse. Aucun chiffre de réduction n'est publié ici : la mesure n'a pas été faite dans des conditions qu'on puisse remettre à un lecteur.
Un stockage de contexte structuré pour agents. Un agent y écrit des objets typés — faits, décisions, contraintes, préférences, événements, relations — et un autre agent les récupère par pertinence, dans une autre session ou avec un autre modèle. Accessible en REST, SDK Python et MCP.
Un historique conserve ce qui a été dit ; il faut le relire pour savoir ce qu'il contient, et il grossit sans limite. Venkai conserve ce que la conversation a produit : l'état du travail. C'est une fraction du volume, typée, versionnée et interrogeable sans relecture.
80/80 tests core et 19/19 checks de handoff, incluant un passage vers un agent utilisant un autre modèle, la persistance après redémarrage, l'isolation multi-tenant et le versioning avec restauration. Aucun chiffre de coût ou de performance n'est publié : ces mesures n'ont pas été faites.
Quelques lignes par agent via le SDK, un appel HTTP en REST, ou une entrée de configuration en MCP. Les limites sont assumées : SQLite est le moteur validé, PostgreSQL et Docker ne le sont pas, les embeddings par défaut reposent sur du hachage, et la supervision de production n'existe pas encore.