Tencent lance Team Memory pour partager la mémoire des agents IA en équipe, sans garde-fou en cas d'erreur

Tencent open-source TencentDB Agent Memory : un pipeline mémoire local à 4 niveaux pour agents IA

Tencent a publié en open source TencentDB Agent Memory, un système de mémoire pour agents IA conçu pour résoudre deux problèmes chroniques des agents de longue durée : l'explosion du contexte et l'échec de rappel. Distribué sous licence MIT, le projet repose sur une architecture à quatre niveaux et une mémoire symbolique court terme, sans nécessiter d'API externe grâce à un backend SQLite local via l'extension sqlite-vec. Le système s'intègre à OpenClaw comme plugin npm (@tencentdb-agent-memory/memory-tencentdb, Node.js 22.16+) et à l'agent Hermes via une image Docker avec passerelle TDAI. La mémoire long terme est organisée en pyramide sémantique à quatre couches : L0 Conversation (dialogues bruts), L1 Atom (faits atomiques), L2 Scenario (blocs de scènes), et L3 Persona (profil utilisateur en Markdown). Les couches hautes sont interrogées en premier ; on ne descend vers les faits bruts que si le détail est nécessaire. Les logs d'outils sont déchargés dans des fichiers externes sous refs/*.md, et les transitions d'état sont encodées en syntaxe Mermaid dans un canvas léger, permettant à l'agent de raisonner sur un graphe symbolique plutôt que sur des logs verbeux. Les gains de performance mesurés par Tencent sur des sessions continues sont significatifs. Sur WideSearch, le taux de réussite passe de 33 % à 50 % (amélioration relative de 51,52 %) et la consommation de tokens chute de 221,31 millions à 85,64 millions, soit une réduction de 61,38 %. Sur SWE-bench, testé en sessions de 50 tâches consécutives pour simuler l'accumulation de contexte, le taux de succès monte de 58,4 % à 64,2 % pendant que les tokens passent de 3 474 millions à 2 375 millions (-33 %). Sur le benchmark de mémoire personnalisée PersonaMem, la précision bondit de 48 % à 76 %. La récupération combine par défaut recherche BM25 et embeddings vectoriels via Reciprocal Rank Fusion, avec support du chinois (jieba) et de l'anglais. Une extraction de mémoire L1 se déclenche toutes les cinq interactions, un persona utilisateur est généré tous les 50 nouveaux souvenirs, et un timeout de cinq secondes évite de bloquer la conversation en cas d'échec de rappel. Ces résultats s'inscrivent dans une course plus large à la résolution du problème de mémoire pour les agents IA autonomes. La plupart des systèmes actuels fragmentent les données dans des stores vectoriels plats, rendant le rappel aveugle et peu structuré. L'approche de Tencent, qui sépare structure symbolique et texte brut tout en maintenant une hiérarchie sémantique, représente une alternative architecturale concrète. Le projet étant open source sous MIT et autosuffisant localement, il s'adresse directement aux développeurs qui construisent des agents de production sans vouloir dépendre d'une API mémoire tierce. Le modèle par défaut est DeepSeek-V3.2 de Tencent Cloud, mais tout modèle compatible OpenAI peut être substitué, ce qui élargit considérablement le périmètre d'adoption potentielle.

💬 La réduction de 61% des tokens sur WideSearch, ça ne s'invente pas. Tencent a fait ce que la plupart des frameworks négligent encore : séparer la structure symbolique du texte brut et organiser la mémoire en hiérarchie, plutôt que de tout jeter dans un store vectoriel plat et prier pour que le rappel fonctionne. Open source MIT, autosuffisant en local, compatible n'importe quel modèle OpenAI-compatible, les ingrédients sont là.

Les agents IA d'Asana partagent la mémoire dans l'entreprise, mais pas vos secrets

Lors d'une conversation avec Sam Witteveen de VentureBeat au VB Transform 2026, Arnab Bose, directeur produit d'Asana, a détaillé la construction d'Agentic Work Management (AWM), un nouveau système conçu pour transformer les agents IA en coéquipiers capables d'apprendre et de collaborer plutôt qu'en simples assistants individuels. AWM s'appuie sur le Work Graph, l'architecture de données vieille de 18 ans d'Asana, organisée selon une structure que l'entreprise appelle la Pyramide de la Clarté : les tâches, assorties d'un responsable et d'une échéance, s'agrègent en projets, puis en portefeuilles, eux-mêmes reliés aux objectifs globaux de l'entreprise. Ce graphe fonctionne comme un registre en temps réel de qui fait quoi, pour quand et pourquoi, ce qui permet par exemple de tracer l'impact d'une tâche de conception en retard sur un objectif de revenus. Bose a précisé que le produit est déjà en production, avec plusieurs clients actifs, dont FedEx, qui a publié sa propre étude de cas sur cette adoption. Cette architecture change la nature même de l'assistant IA en entreprise : au lieu d'un outil isolé, limité à un seul utilisateur et à un seul prompt, l'agent partage une mémoire commune avec l'ensemble des équipes humaines, consulte les objectifs globaux et met à jour les statuts de projet directement dans le registre partagé. Pour les équipes produit et les développeurs, cela représente un changement de paradigme dans la conception d'agents à grande échelle, où l'IA cesse d'être une simple interface conversationnelle pour devenir un acteur intégré aux flux de travail collectifs. Ce changement d'échelle a toutefois obligé Asana à résoudre plusieurs problèmes techniques critiques, à commencer par la gouvernance des données. Bose a insisté sur la nécessité d'éviter toute fuite de contexte : si un dirigeant utilise un agent pour piloter un projet confidentiel, par exemple une opération de fusion-acquisition secrète, la mémoire générée par cet usage ne doit jamais être accessible à un autre employé interagissant plus tard avec le même agent. Asana a donc mis en place des contrôles d'accès distinguant la création de mémoire de la simple exécution de tâches. Le système gère également un routage dynamique des modèles : les tâches complexes sont orientées vers des modèles frontière comme Opus d'Anthropic ou les modèles d'OpenAI, tandis que les tâches simples sont confiées à des modèles plus légers et moins coûteux, sans que l'utilisateur ait à se soucier de l'ingénierie du prompt. Cette automatisation soulève à son tour un troisième défi, encore en cours de résolution chez Asana : celui de la facturation liée à l'usage de ces agents.

💬 Le vrai sujet, c'est pas l'agent qui répond à un prompt, c'est la mémoire partagée entre équipes, et ça change complètement la donne côté gouvernance des données. Séparer la création de mémoire de l'exécution des tâches pour éviter qu'un stagiaire tombe sur le contexte d'une fusion-acquisition, c'est le genre de détail chiant qui décide si un produit tient en entreprise ou pas. Reste que la facturation à l'usage n'est toujours pas réglée chez eux, et ça, ça sent la roadmap qui traîne depuis un moment.

Les agents IA apprennent en cours de tâche, mais pas pour toute l'équipe

Les agents d'intelligence artificielle peinent à devenir de véritables outils d'équipe. Selon une étude interne d'Asana, 75 % des travailleurs du savoir utilisent déjà l'IA au quotidien, mais seulement 5 % des entreprises déclarent en avoir tiré des gains de productivité mesurables. La raison principale : lorsqu'un collaborateur corrige ou améliore un agent, en affinant ses instructions, en lui fournissant un contexte plus précis, cette amélioration s'évapore dès qu'un collègue ouvre le même outil. Chaque utilisateur repart de zéro, entraînant en pratique une version différente du même agent selon la personne qui l'interroge. Arnab Bose, directeur produit d'Asana, résume le problème : les fournisseurs de modèles progressent rapidement sur le raisonnement et les boucles de correction, mais échouent à intégrer le contexte de travail d'entreprise d'une manière intelligible et partageable entre humains. Ce défaut architectural a des conséquences concrètes dans les workflows multi-agents, devenus la norme dans les grandes organisations : des agents qui se contredisent, des tâches répétées inutilement, des versions incohérentes de la réalité selon les équipes. Sriharsha Chintalapani, cofondateur et directeur technique de Collate, souligne que les agents sont extrêmement sensibles à la qualité des instructions reçues : un utilisateur expérimenté obtient de meilleurs résultats parce qu'il formule des prompts plus précis et donne de meilleurs retours correctifs, que l'agent mémorise et applique aux interactions suivantes. Ce mécanisme fonctionne bien pour un usage individuel, mais devient un avantage inégalement distribué dès qu'il s'agit d'un usage collectif. Neej Gore, directeur des données de Zeta Global, défend l'idée d'une mémoire partagée qui agirait comme une intelligence composée, s'enrichissant à chaque interaction et bénéficiant à toute l'organisation. La réponse d'Asana consiste à placer la mémoire partagée au coeur de sa plateforme Agentic Work Management : toute correction apportée par un membre de l'équipe s'applique automatiquement à l'ensemble des utilisateurs, via un graphe de contexte injecté directement dans les agents opérant dans son système. Plus besoin que chaque collaborateur maîtrise l'ingénierie des prompts. Mais la question de qui contrôle cette mémoire, ce qui y est stocké et comment elle reste cohérente quand plusieurs agents et utilisateurs y écrivent simultanément reste largement sans réponse dans l'industrie. Chintalapani avance que la piste la plus prometteuse consiste à construire des agents capables de récupérer la mémoire de manière relationnelle, en fonction du contexte précis de chaque requête, une approche que seules quelques organisations disposant de ressources importantes sont aujourd'hui en mesure de mettre en oeuvre.

Organiser la mémoire des agents à grande échelle : patterns de conception par namespace dans AgentCore Memory

Amazon a publié un guide technique détaillé sur la conception de namespaces dans AgentCore Memory, le système de mémoire à long terme intégré à Amazon Bedrock. La fonctionnalité, présentée dans un billet de blog officiel d'AWS, permet aux développeurs d'organiser les souvenirs de leurs agents IA sous forme de chemins hiérarchiques, similaires à des arborescences de fichiers. Concrètement, les préférences d'un utilisateur identifié comme customer-123 seront stockées sous /actor/customer-123/preferences/, tandis que les résumés de ses sessions individuelles seront rangés sous /actor/customer-123/session/session-789/summary/. Ces chemins sont générés automatiquement à partir de trois variables prédéfinies : {actorId} pour l'identifiant de l'utilisateur, {sessionId} pour la session en cours, et {memoryStrategyId} pour le type de stratégie mémoire utilisé. Le système prend en charge plusieurs stratégies superposées, notamment la mémoire sémantique pour les faits durables sur un utilisateur, et la mémoire de résumé pour les synthèses de sessions passées. L'enjeu est concret : sans organisation rigoureuse, les agents IA récupèrent du contexte non pertinent lors de leurs requêtes, ce qui dégrade la qualité des réponses et peut créer des failles de sécurité, notamment en exposant les souvenirs d'un utilisateur à un autre. Le système de namespaces résout ces deux problèmes à la fois. D'un côté, la structure hiérarchique permet une récupération à granularité variable : on peut interroger la mémoire d'une session précise, l'ensemble des préférences d'un utilisateur à travers toutes ses sessions, ou encore des données communes à tous les utilisateurs d'un même agent. De l'autre, AWS intègre des contrôles d'accès IAM natifs qui permettent de délimiter précisément qui peut lire ou écrire dans quelle portion de la mémoire, sans dupliquer le stockage physique. Les namespaces sont des partitions logiques au sein d'une même ressource mémoire, une approche que les équipes habituées aux clés de partition DynamoDB ou aux préfixes S3 reconnaîtront immédiatement. Ce guide s'inscrit dans une dynamique plus large : l'essor des agents IA en production crée une demande croissante pour des infrastructures mémoire robustes et sécurisées. Amazon Bedrock, qui concurrence directement les offres d'OpenAI, Google et Microsoft Azure dans l'espace des plateformes d'agents d'entreprise, cherche à se différencier par des primitives de bas niveau bien pensées. AgentCore Memory, présenté comme une brique fondamentale pour les agents à longue durée de vie, cible les équipes qui construisent des assistants client, des copilotes métier ou des agents autonomes nécessitant une continuité de contexte entre les sessions. La prochaine étape annoncée par AWS porte sur les patterns de récupération multi-niveaux et les stratégies d'isolation entre agents dans des architectures multi-tenants.