Architecture
Une couche, pas un système.
Venkai se pose à côté de ce que vous faites tourner déjà. Il ne décide pas quel agent parle, n'appelle aucun modèle et n'indexe aucun document.
Position
Où Venkai se branche
- 01Votre framework d'agentsorchestration, outils, modèles — inchangés
- 02Venkai — API / SDK / MCPécriture et lecture d'objets de contexte typés
- 03Contexte structuréfait · décision · contrainte · préférence · événement · relation
- 04Stockage persistantisolé par organisation, versionné à chaque écriture
L'appel est synchrone et sans effet de bord sur votre flux : un agent écrit quand il a produit quelque chose qui doit survivre, et lit quand il a besoin de savoir où en est le travail. Rien n'oblige un agent à passer par Venkai pour fonctionner ; ce qui passe par Venkai est ce qui doit être retrouvé plus tard.
Responsabilités
Ce que Venkai prend en charge
Typage du contexte
Six types, choisis à l'écriture. Un agent peut demander « toutes les décisions » sans relire le reste.
Récupération classée
Une requête renvoie les objets ordonnés par similarité, récence, importance et fréquence d'accès.
Isolation
Clé API → organisation. Chaque lecture et chaque écriture sont filtrées par cette chaîne.
Versioning
Toute mise à jour crée un instantané de l'état précédent, restaurable par API.
Cycle de vie des accès
Clés API rotables et révocables, JWT pour les sessions navigateur.
Sortie des données
Export complet et suppression en cascade au niveau organisation.
Frontières
Ce que Venkai ne fait pas
Cette liste est aussi importante que la précédente. Un composant dont on ne connaît pas les bords ne s'intègre pas.
Il n'orchestre pas
Venkai ne décide pas quel agent s'exécute, ni dans quel ordre. Votre orchestrateur reste le vôtre.
Il n'appelle pas de modèle
Aucun appel LLM n'est émis par Venkai. Il ne résume pas, ne reformule pas, n'invente pas.
Il n'indexe pas vos documents
Ce n'est pas un RAG. Il stocke des objets de contexte produits par des agents, pas des chunks de documents.
Il n'est pas une base vectorielle
Le classement utilise une similarité, mais l'unité stockée est un objet typé avec son historique, pas un vecteur nu.
Il ne supprime pas les hallucinations
Si un agent écrit une décision fausse, Venkai la conserve fidèlement. Il rend l'erreur visible et réversible, il ne l'empêche pas.
Il ne juge pas la qualité de l'écriture
Ce qu'un agent B retrouve dépend de ce que l'agent A a pris la peine d'écrire.
État réel
Les limites de la mise en œuvre actuelle
- VERIFIED
SQLite
Le moteur validé aujourd'hui. Mono-processus : la concurrence est bornée.
- PLANNED
PostgreSQL
Le code est configurable et les migrations Alembic sont écrites, mais rien n'a été testé en conditions réelles.
- LIMIT
Embeddings par défaut
Basés sur du hachage, donc sans généralisation sémantique aux synonymes. Un vrai modèle d'embeddings est requis pour cela.
- PLANNED
Déploiement Docker
Dockerfile et compose existent ; le build n'a jamais été exécuté dans cet audit.
- LIMIT
Supervision
La télémétrie est en processus, sans export externe ni alerting.
- EXPERIMENTAL
Client MCP externe
Le serveur MCP passe ses tests, mais n'a pas encore été branché à un client tiers réel.
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 workflowLe système
Ce qui se passe entre un workflow et un meilleur workflow.
Forge fait tourner les agents. Venkai retient ce qu'ils établissent. Cervelet regarde ce qui a marché. Mutation change le workflow. Puis ça recommence — et c'est la boucle, pas l'exécution, qui est le produit.
La sortie revient à l'entrée. C'est ça, la boucle.
Diagramme, pas capture d'écran : il décrit l'architecture, il ne montre pas une exécution réelle.