Pourquoi Venkai
Venkai et votre stack IA existante résolvent des problèmes différents.
La mémoire dit ce que le système sait. La continuité dit ce qui doit survivre pour que le travail continue. Ce ne sont pas des concurrents, et un système multi-agents a souvent besoin des deux.
Votre stack IA
Mémoire, RAG, orchestration, continuité : quatre questions
Venkai ne demande de remplacer ni votre mémoire, ni votre retrieval, ni votre orchestrateur, ni vos modèles.
| Couche | Question | Exemples | Relation avec Venkai |
|---|---|---|---|
| Mémoire | Que doit retenir le système sur un utilisateur, une conversation, une entité ? | Mem0, Zep, Letta, mémoire d'assistant | Complémentaire. Venkai ne la remplace pas. |
| RAG | Quelle information le système doit-il aller chercher dans des documents ? | Bases vectorielles, index documentaires | Complémentaire. Venkai n'indexe aucun document. |
| Orchestration | Comment les agents et les étapes sont-ils coordonnés ? | LangGraph, CrewAI, AutoGen, boucle maison | Reste en place. Venkai ne décide pas qui s'exécute. |
| Continuité | Quel contexte et quel état du travail doivent survivre pour que l'agent, la session, le modèle ou l'étape suivante puisse continuer ? | Venkai | La couche que Venkai couvre. |
Les couches se recouvrent en partie : Venkai stocke aussi des faits et des préférences, mais rattachés à l'état d'un travail en cours, pas au profil d'un utilisateur.
Où il se branche
À côté de ce qui tourne déjà
- 01ApplicationVotre produit, inchangé.
- 02Agents et étapesVotre orchestrateur, vos modèles, votre mémoire et votre RAG restent en place.
- 03Venkai — REST · SDK · MCPAppelé par l'agent, à côté de ces systèmes et pas en dessous : lecture avant le prompt, écriture après la décision.
- 04État de travail typéFait, décision, contrainte, préférence, événement, relation — versionné, isolé par organisation.
- 05Suite du travailL'agent, la session ou le modèle suivant reprend à partir de cet état.
Le principe
Ne pas tout stocker
Un historique complet est facile à produire et coûteux à utiliser : il faut le relire pour savoir ce qu'il contient, et il grossit plus vite que la capacité à le traiter. La tentation est alors de tout envoyer à l'agent suivant sous forme de dump, ce qui déplace le travail de compréhension au lieu de le supprimer.
Venkai part de l'hypothèse inverse. Ce qui doit survivre à un changement d'agent n'est pas la conversation, c'est ce qu'elle a produit : les faits établis, les décisions prises, les contraintes posées, ce qui a changé et ce qui reste à faire. C'est une fraction du volume, et c'est la partie que l'agent suivant doit connaître avant d'agir.
L'écriture est donc un geste explicite. Un agent décide de conserver quelque chose, avec un type et une importance. Cela demande un peu de discipline côté agent, et c'est la contrepartie assumée : la qualité de ce qu'un agent retrouve dépend de ce que le précédent a pris la peine d'écrire.
Honnêteté
Quand Venkai n'est pas la bonne réponse
Un seul agent, une seule session
S'il n'y a ni passage de relais ni interruption, la fenêtre de contexte suffit.
Le besoin est documentaire
Si la question est « que dit ce document ? », il faut un RAG, pas Venkai.
La recherche doit être sémantique dès le premier jour
Les embeddings par défaut reposent sur du hachage ; sans modèle d'embeddings, les synonymes ne sont pas rapprochés.
L'échelle de production est un prérequis
SQLite est le moteur validé aujourd'hui. PostgreSQL est prévu mais non éprouvé.
Construire une couche de continuité pour vos agents.
Décrivez votre workflow multi-agents et l'endroit où le contexte se perd. Nous répondons avec un périmètre de pilote, ou avec la raison pour laquelle Venkai n'est pas la bonne pièce.
Décrivez votre workflow