Cas d'usage
Cinq endroits où le contexte se perd.
Chaque cas porte son statut avant son argument : un seul est démontré, les quatre autres sont des hypothèses de travail. Aucun résultat chiffré n'est avancé — rien n'a encore été mesuré en production.
01 · Démontré
Handoff entre agents
Statut : démontré
19 checks sur 19, dont un passage vers un agent déclaré sur un autre modèle. Rejouable : `python demos/agent_handoff_demo.py`.
Problème
L'agent A a compris le dossier. Il se termine. L'agent B redémarre avec un prompt et, au mieux, une transcription à relire.
Avec Venkai
A écrit ses décisions et contraintes au fil de l'eau. B appelle recall() et reçoit ce qui compte, ordonné, sans relire l'historique.
Pourquoi c'est important
C'est le seul des cinq cas qui ne repose pas sur une projection : le relais a été exécuté, pas supposé.
02 · Hypothèse
Workflows longs
Statut : hypothèse
Les briques sont testées (persistance hors session, versioning). Aucun workflow de plusieurs jours n'a encore été mesuré de bout en bout chez un client.
Problème
Un workflow qui s'étale sur plusieurs jours traverse des interruptions, des reprises et des fenêtres de contexte saturées.
Avec Venkai
L'état vit en dehors de la session. La reprise consiste à demander la progression et les prochaines actions, pas à reconstruire l'historique.
Pourquoi c'est important
Une fenêtre de contexte plus grande repousse la limite ; elle ne survit pas à la fin de la session.
03 · Hypothèse
Ingénierie logicielle multi-agents
Statut : hypothèse
Le stockage d'une décision et de sa raison est testé. Qu'il empêche effectivement un agent de défaire le travail d'un autre reste à démontrer sur un dépôt réel.
Problème
Un agent choisit une bibliothèque, un autre la remplace trois étapes plus loin sans savoir pourquoi la première avait été retenue.
Avec Venkai
La décision et sa raison sont écrites comme un objet typé. L'agent suivant peut demander les décisions d'architecture avant d'en prendre une.
Pourquoi c'est important
Le coût d'un contexte perdu n'est pas le token dépensé, c'est le travail défait.
04 · Hypothèse
Continuité humain → agent
Statut : hypothèse
Rien ne distingue techniquement une contrainte écrite par un humain d'une contrainte écrite par un agent. L'usage, lui, n'a pas été observé en équipe.
Problème
Un humain cadre le travail en réunion ou en revue. L'agent qui exécute n'a accès qu'à ce qu'on a pensé à recopier dans son prompt.
Avec Venkai
Les contraintes et préférences posées par l'humain sont écrites une fois et lues par chaque agent qui intervient ensuite.
Pourquoi c'est important
La contrainte humaine est celle qui coûte le plus cher quand elle disparaît, parce que personne ne la reformule.
05 · Hypothèse
RAG et contexte opérationnel
Statut : hypothèse
La séparation est un choix d'architecture, pas un résultat de mesure. Aucune comparaison chiffrée contre un RAG seul n'a été produite.
Problème
Le RAG retrouve ce que disent les documents. Il ne sait pas ce que le système a déjà décidé ni ce qu'il reste à faire.
Avec Venkai
Le RAG reste la source de connaissance ; Venkai conserve l'état du travail mené avec cette connaissance. Les deux se lisent séparément.
Pourquoi c'est important
Écrire l'état du travail dans l'index documentaire mélange deux natures d'information et dégrade les deux.
Construire une couche de continuité pour vos agents.
Un scan gratuit de votre site en quelques minutes, puis le X-Ray : 3 à 5 opportunités chiffrées, le workflow avant/après et la première action. Gratuit, livré par email, sans carte bancaire ni appel.
Obtenir mon X-Ray