Présentation d’Agent Memory sur Databricks : rendre le travail passé réutilisable

Databricks a lancé en bêta une mémoire pour agents, remettant en cause la pratique qui consiste à obliger les agents d’entreprise à redécouvrir ce qu’ils ont appris lors de conversations précédentes. Son annonce du 20 octobre, Introducing Agent Memory on Databricks, intègre un contexte persistant à Agent Bricks, la plateforme de développement d’agents de l’entreprise. La question pratique est de savoir si la conservation de l’expérience génère des améliorations fiables face à l’évolution des tâches métier.

La comparaison centrale oppose une mémoire gérée à la redécouverte répétée et à une infrastructure de mémoire sur mesure. Les développeurs en entreprise doivent décider si le maintien de leur propre système justifie toujours son coût d’ingénierie. AgentCore d’Amazon propose déjà une mémoire gérée ; Databricks entre donc dans une compétition existante pour déterminer où doit résider le savoir accumulé d’un agent.

Pour les acheteurs, cette annonce soulève une question plus précise que celle de savoir si un assistant se souvient d’un format de réponse privilégié. Une plateforme peut-elle préserver des corrections utiles, les appliquer de façon appropriée et expliquer quand une information mémorisée a influencé une réponse ? Cette combinaison détermine si la mémoire devient un avantage opérationnel ou une source supplémentaire d’erreurs.

Introducing Agent Memory on Databricks rend le contexte persistant

Databricks propose la mémoire intersessions comme un service exploité, transférant une partie de la charge d’implémentation hors des équipes applicatives.

L’annonce d’Agent Memory de l’entreprise décrit des historiques de conversation gérés, des mémoires durables et des processus en arrière-plan qui consolident ce que les agents doivent conserver. Le service s’exécute sur Lakebase, la base de données Postgres gérée de Databricks. Databricks indique que les développeurs peuvent inspecter, exporter et supprimer les entrées mémorisées.

Cela modifie le point de départ d’une application d’entreprise. Auparavant, une équipe qui construisait elle-même la persistance devait relier le stockage à des règles de sélection et de récupération des informations utiles. Une option gérée permet à cette équipe d’évaluer une implémentation existante avant de s’engager dans la sienne.

La distinction importe, car conserver une transcription ne produit pas automatiquement une mémoire utile. Une transcription enregistre ce qui s’est passé, y compris les erreurs, les approches abandonnées et les hypothèses temporaires. Une mémoire utile exige de déterminer quelles parties méritent d’influencer le travail futur.

Prenons l’exemple illustratif d’un assistant d’analytique qui reçoit une correction concernant la définition du chiffre d’affaires. Cette correction peut s’appliquer à un service, à une période de reporting ou à un tableau de bord particulier. Mémoriser la phrase sans son périmètre risque d’appliquer la réponse d’hier à une question différente.

C’est là que l’annonce devient pertinente au-delà de la personnalisation. Une préférence de ton affecte la présentation. Une définition métier mémorisée affecte le fond d’une réponse et potentiellement les actions qui en découlent.

La décision d’ingénierie concerne donc autant la responsabilité que le stockage. Si les développeurs adoptent une mémoire gérée, ils doivent toujours déterminer quelles informations conservées ont leur place dans leur application. Ils ont également besoin d’un moyen de contester une entrée qui semble faire autorité mais ne s’applique plus.

Introducing Agent Memory on Databricks offre à ces équipes une option d’infrastructure. Cela ne signifie pas que chaque conversation doit créer un savoir durable. La conservation sélective reste une décision produit, en particulier lorsque les utilisateurs mêlent préférences pérennes et demandes temporaires.

Une application peut raisonnablement mémoriser le format de reporting préféré d’un utilisateur tout en refusant de conserver une prévision provisoire. Ces deux déclarations surviennent dans une conversation, mais elles n’impliquent pas les mêmes attentes. Les traiter de façon identique rendrait la persistance plus facile à implémenter et plus difficile à faire confiance.

Le changement immédiat est donc concret mais limité. Databricks offre désormais aux développeurs un espace géré pour préserver l’expérience d’une conversation à l’autre. La question de savoir si cette expérience mérite d’être réutilisée dépend des règles de l’application et des éléments qui étayent chaque mémoire.

Cette limite façonne les enjeux commerciaux. Les équipes peuvent transférer le travail d’infrastructure à une plateforme, mais elles ne peuvent pas lui transférer leur compréhension de ce qui constitue un savoir métier valide.

Les équipes d’entreprise font face à une décision différente entre construire et acheter

Les équipes sous pression sont celles qui maintiennent une infrastructure de mémoire en parallèle des agents qui en dépendent.

Pour un groupe interne chargé des plateformes, une mémoire sur mesure crée un engagement durable. Quelqu’un doit enquêter sur les entrées manquantes, les récupérations inappropriées, les corrections contradictoires et les mises à jour échouées. Ces responsabilités perdurent après la réussite de la démonstration initiale.

Un service géré fait passer la comparaison de la disponibilité des fonctionnalités à la valeur opérationnelle. La question devient de savoir si une implémentation sur mesure apporte suffisamment de contrôle ou de spécialisation pour justifier son entretien. Il s’agit d’une exigence plus élevée que de simplement démontrer qu’un agent peut enregistrer des informations.

Il existe des raisons légitimes de conserver une approche sur mesure. Une organisation peut avoir besoin de règles de conservation spécialisées, de limites de déploiement inhabituelles ou d’un format de mémoire partagé entre des systèmes existants. Ces besoins méritent d’être évalués plutôt que de supposer que l’infrastructure gérée l’emporte toujours.

À l’inverse, une équipe aux besoins classiques gagne peu à reconstruire des mécanismes familiers au seul motif qu’elle possède déjà l’application. Son attention d’ingénierie limitée pourrait créer davantage de valeur par de meilleures évaluations ou des contrôles utilisateur plus clairs.

L’arrivée de Databricks donne également aux acheteurs d’entreprise un autre point de comparaison. La documentation d’Amazon sur les types de mémoire d’AgentCore décrit le stockage des interactions brutes et des enregistrements à long terme extraits par des traitements en arrière-plan. Elle décrit aussi la consolidation et la récupération lors de sessions ultérieures.

Ce chevauchement établit un niveau de référence concurrentiel. La mémoire persistante est déjà une capacité de plateforme disponible auprès d’un autre fournisseur majeur. Databricks doit rivaliser par la qualité de son implémentation, son adéquation opérationnelle et son intégration aux charges de travail que les clients exécutent réellement.

La documentation disponible ne permet pas d’établir un gagnant en matière de performance entre ces services. Les descriptions d’architecture expliquent le comportement prévu, mais ne remplacent pas des tests équivalents. Une comparaison équitable maintiendrait constants la tâche, le modèle, l’historique et les règles de notation.

Pour les acheteurs, cela signifie que le choix du fournisseur doit découler des schémas de défaillance de l’application. Un assistant de support qui oublie des préférences présente des exigences différentes d’un agent d’analytique qui choisit à répétition la mauvaise source. La qualité de la mémoire doit être mesurée par rapport au problème précis dont l’achat vise à se décharger.

Les discussions d’approvisionnement doivent également distinguer la commodité de la dépendance. La consolidation de l’infrastructure peut réduire le nombre de systèmes exploités par une organisation. Elle peut aussi rendre une migration plus lourde de conséquences lorsque le contexte accumulé devient une partie du comportement de l’application.

Des entrées exportables sont utiles, mais une exportation seule ne garantit pas un comportement équivalent ailleurs. Un autre système peut sélectionner d’autres mémoires ou interpréter différemment le même texte conservé. La portabilité mérite un test comportemental autant qu’un test de transfert de données.

L’argument le plus solide en faveur de l’achat d’une mémoire gérée est donc pragmatique : le service doit réduire la maintenance tout en préservant les contrôles nécessaires à l’application. Les acheteurs devraient attendre des preuves de ces deux résultats avant de considérer la consolidation de l’infrastructure comme une amélioration.

La pression s’exerce à la fois sur les implémentations sur mesure et sur les fournisseurs de services gérés. Chacun doit expliquer comment son approche améliore le travail accompli, plutôt que d’augmenter simplement la quantité d’informations qu’un agent peut conserver.

Le mécanisme repose sur la sélection de ce qui mérite d’être réutilisé

Le problème central de conception consiste à décider quelles expériences doivent influencer la tâche suivante.

La documentation du pipeline de mémoire de Databricks décrit un traitement en arrière-plan qui extrait des informations durables, fusionne les entrées qui se chevauchent et réorganise les mémoires stockées. Les développeurs peuvent fournir des instructions sur ce qui doit être conservé. La conception documentée privilégie les faits et procédures réutilisables plutôt que les valeurs changeantes qui devraient provenir de sources en direct.

Cette distinction a des conséquences directes pour l’analytique d’entreprise. Mémoriser la façon dont une métrique est calculée peut aider un agent à répéter un processus valide. Mémoriser la valeur précédente de cette métrique peut produire une réponse obsolète lorsque l’activité sous-jacente évolue.

Un assistant commercial illustratif clarifie cette différence. Il pourrait conserver la règle selon laquelle une équipe exclut les contrats annulés d’un rapport particulier. Il devrait toutefois obtenir les données contractuelles actuelles lors de la préparation du rapport suivant.

La règle conservée réduit la redécouverte sans remplacer des éléments probants récents. Si l’organisation modifie cette règle, la mémoire doit toutefois recevoir une correction appropriée. Une réutilisation réussie dépend donc à la fois de la conservation et de la révision.

Le traitement en arrière-plan crée une autre limite décisionnelle. La documentation du pipeline permet des exécutions manuelles ou planifiées environ toutes les 24 heures. La consolidation planifiée doit donc être comprise comme un traitement différé, et non comme la garantie que chaque nouvelle correction remodèle immédiatement toutes les interactions futures.

Pour les concepteurs d’applications, l’implication est simple. Une correction nécessaire pour la prochaine demande de l’utilisateur mérite un traitement différent d’un savoir qui peut attendre une consolidation ultérieure. L’utilisateur ne devrait pas avoir à comprendre le calendrier de traitement pour savoir si une correction a pris effet.

La documentation indique également que la maintenance peut modifier des entrées enregistrées directement par un agent. Cela signifie qu’une mémoire stockée participe à une interprétation évolutive de la conversation. Il ne s’agit pas nécessairement d’une copie permanente de la déclaration d’origine.

Cela soulève une question de responsabilité pour les équipes produit. Si une instruction mémorisée change lors de la consolidation, l’application devrait disposer de suffisamment d’éléments pour expliquer le comportement qui en résulte. Dans le cas contraire, l’utilisateur voit un assistant modifier son interprétation sans raison compréhensible.

Une analogie utile est celle d’un analyste qui tient des notes de travail. Les notes ne sont utiles que lorsqu’elles préservent les conditions pertinentes et restent distinguables des sources vérifiées. Le résumé conservé par un agent mérite un examen similaire.

La même distinction apparaît dans la gestion des connaissances personnelles : collecter des informations et les rendre utiles sont des tâches liées mais distinctes. Pour les agents d’entreprise, l’utilité dépend également du fait que les informations conservées restent appropriées à la demande actuelle.

Ce mécanisme fait de la mémoire une partie active du comportement de l’application. Il sélectionne, compresse et met à jour l’expérience avant le début de la tâche suivante. Les équipes qui évaluent le service devraient juger ces transformations, plutôt que de considérer un stockage réussi comme la ligne d’arrivée.

Le benchmark étaye une affirmation de performance circonscrite

Databricks fait état d’améliorations sur son benchmark d’entreprise, mais ces résultats n’établissent pas des gains universels.

L’étude MemCurrent de l’entreprise décrit l’architecture à l’origine de cette publication. Sur son benchmark interne, Databricks indique un taux de réussite de 68,4 % avec MemCurrent, contre 22,3 % sans mémoire. L’entreprise fait également état de 31 % de tokens en moins et d’une exécution 26 % plus rapide.

Le benchmark interne comprend 114 cas impliquant 29 utilisateurs et 2 233 sessions historiques. Databricks indique avoir construit l’évaluation à partir de conversations sur des données d’entreprise et avoir examiné les cas. Il s’agit de résultats communiqués par l’entreprise, et non d’une validation indépendante de chaque déploiement.

L’étude présente également une amélioration illustrative d’un flux de travail : un suivi connexe a nécessité deux appels d’outils et 41 secondes, après qu’une tâche antérieure avait exigé 11 appels et près de six minutes. Cet exemple étaye le mécanisme proposé consistant à éviter des phases de découverte répétées. Il ne permet pas d’établir l’amélioration moyenne à laquelle les clients doivent s’attendre.

La distinction entre un exemple et un résultat attendu est importante. Une tâche répétée avec un contexte réutilisable offre une occasion favorable à la mémoire. Une nouvelle tâche aux exigences sans rapport pourrait tirer peu de bénéfices des informations historiques.

De même, une baisse du nombre de tokens mesure une ressource particulière, et non l’ensemble de la charge opérationnelle. Les équipes doivent toujours prendre en compte le travail nécessaire pour produire, maintenir, inspecter et évaluer la mémoire. Une décision de déploiement doit considérer l’application dans son ensemble.

Ces résultats sont surtout utiles comme raison de tester une hypothèse précise. Si un agent redécouvre à plusieurs reprises des connaissances métier stables, l’expérience conservée devrait réduire cette répétition. L’hypothèse s’affaiblit lorsque les conversations passées apportent peu d’informations pertinentes.

Une évaluation devrait également inclure des tâches pour lesquelles la mémoire devrait rester inutilisée. Sans cela, un système peut sembler efficace en insérant un contexte historique dans chaque réponse. La sélectivité importe, car des souvenirs non pertinents créent leur propre distraction.

La recherche indépendante fournit un cadre d’évaluation plus large. Le benchmark LongMemEval, présenté à ICLR 2025, teste l’extraction, le raisonnement entre sessions, le raisonnement temporel, les mises à jour de connaissances et l’abstention. L’abstention consiste à refuser de répondre lorsque les éléments disponibles ne permettent pas d’étayer une réponse.

Ces catégories montrent pourquoi le simple rappel est une mesure incomplète. Un assistant peut retrouver avec exactitude une ancienne déclaration tout en l’appliquant au mauvais moment. Il peut également échouer en répondant avec assurance alors que sa mémoire ne contient aucun élément pertinent.

Pour les acheteurs en entreprise, la question utile est donc plus précise que celle de savoir si la mémoire améliore les scores de benchmark. Améliore-t-elle les tâches que leurs employés accomplissent réellement, y compris les cas où les définitions ont changé ou les instructions se contredisent ?

Introducing Agent Memory on Databricks crée une occasion de mener cette comparaison avec une infrastructure gérée. Les résultats publiés justifient l’attention, tandis que l’évaluation propre à l’application doit déterminer si le mécanisme rapporté se transfère.

C’est une interprétation défendable des éléments disponibles. L’entreprise a présenté une affirmation mesurable accompagnée d’une évaluation décrite. Les clients ont toujours besoin de résultats reflétant leurs propres historiques, autorisations et décisions métier.

La propriété de la mémoire exige plus qu’un identifiant utilisateur

Le contexte persistant nécessite des règles explicites de sécurité et de suppression, car les informations mémorisées peuvent survivre à la conversation qui les a produites.

La documentation de Databricks sur la mémoire et les sessions indique que supprimer une session ne supprime pas la mémoire. Elle distingue également le partitionnement par utilisateur du contrôle d’accès. Un identifiant d’acteur sélectionne les entrées utilisées par une opération, mais un principal ayant accès au magasin peut lire les entrées appartenant à d’autres acteurs.

La documentation recommande de dériver cet identifiant d’une identité vérifiée dans un code d’application de confiance. Pour une isolation stricte des tenants, elle recommande des magasins distincts. Elle avertit également que les interfaces et le comportement de la bêta peuvent changer.

Ce sont des détails d’implémentation importants pour un acheteur qui évalue cette publication. Un champ qui étiquette les informations par utilisateur n’impose pas automatiquement une frontière de sécurité. L’application doit relier correctement l’identité, les autorisations et la structure de stockage.

Un déploiement illustratif de support client montre cette préoccupation. Une préférence mémorisée peut être inoffensive dans le compte propre d’un client, mais inappropriée dans la conversation d’un autre client. Une récupération correcte exige que l’application établisse la bonne identité avant que le modèle ne demande une mémoire.

La suppression pose une question différente. Un utilisateur peut raisonnablement penser que supprimer une conversation efface ce que l’assistant en a appris. Si des informations dérivées subsistent, le produit doit expliquer clairement cette distinction.

Il s’agit d’une implication de conception d’application, plutôt que d’une preuve qu’un déploiement particulier gère mal la suppression. La séparation documentée en fait une question à laquelle les équipes doivent répondre. Une politique complète de suppression doit traiter à la fois l’interaction d’origine et les informations conservées à partir de celle-ci.

La correction mérite une attention similaire. Remplacer un souvenir erroné devrait influencer les comportements futurs, mais les équipes doivent aussi comprendre comment la correction interagit avec l’historique restant. Sinon, les mêmes éléments sous-jacents pourraient de nouveau étayer l’interprétation erronée.

La mémoire peut également conserver des instructions qui n’auraient jamais dû acquérir une autorité durable. Considérons un document illustratif contenant une directive opérationnelle trompeuse. Si un agent résume cette directive comme une pratique acceptée, l’erreur peut influencer des tâches ultérieures au-delà de l’examen du document initial.

Ce scénario appelle une évaluation de l’autorité des sources et du comportement de rétention. Il ne doit pas être présenté comme une vulnérabilité découverte dans Databricks. La question pertinente est de savoir si une application distingue une préférence approuvée par l’utilisateur d’un contenu non fiable rencontré pendant le travail.

L’expérience produit compte ici autant que le backend. Les utilisateurs ont besoin de moyens compréhensibles pour inspecter les souvenirs importants, les corriger et demander leur suppression. Une capacité technique a une valeur pratique limitée si ses contrôles restent inaccessibles aux personnes concernées.

Pour les développeurs, la leçon opérationnelle est concrète. La mémoire introduit un chemin supplémentaire par lequel les informations atteignent une réponse. Le débogage doit donc prendre en compte ce dont l’agent s’est souvenu, pourquoi il a récupéré cette information et si l’application en a autorisé l’utilisation.

Ces responsabilités ne disparaissent pas avec le stockage géré. Elles deviennent partie intégrante de la décision de savoir si le service géré correspond aux frontières de confiance de l’application.

Ce qu’il faut surveiller après l’annonce de la bêta

Les prochaines preuves devraient relier la mémoire gérée à des résultats clients reproductibles et à des limites opérationnelles plus claires.

Le premier signal est une évaluation indépendante ou publiée par des clients sur des tâches d’entreprise récurrentes. Des résultats utiles compareraient la même application avec et sans mémoire, tout en incluant des corrections, des faits changeants et des demandes sans rapport. Ces éléments permettraient de vérifier si le contexte conservé améliore le travail au-delà des cas sélectionnés par l’entreprise.

Une évaluation convaincante expliquerait les échecs autant que les réussites. Si les performances ne s’améliorent que pour des questions très répétées, le bénéfice demeure plus limité qu’une compréhension durable de l’activité. Si les gains persistent sur des tâches liées mais différentes, l’argument en faveur d’une expérience réutilisable devient plus solide.

Le deuxième signal est l’évolution du produit concernant les contraintes opérationnelles et le contrôle par les utilisateurs. Les acheteurs devraient surveiller les changements documentés relatifs à la planification, à l’échelle, à l’isolation, à l’inspection et au comportement de suppression. Ces détails déterminent quelles applications peuvent s’appuyer sur le service sans construire une infrastructure de soutien substantielle.

Les progrès sur ces contrôles renforceraient l’argument du faire ou acheter. Si les équipes ont toujours besoin d’une importante mécanique personnalisée pour gérer le comportement ordinaire de la mémoire, l’avantage opérationnel devient moins convaincant. La mesure pertinente est la part de responsabilité que le service élimine réellement.

Le troisième signal concerne la manière dont les concurrents rendent leurs propres affirmations sur la mémoire plus faciles à vérifier. L’offre existante d’Amazon signifie que la catégorie possède déjà des alternatives. Des évaluations comparatives plus claires aideraient les clients à distinguer les différences de comportement des différences de terminologie.

Les réponses concurrentielles ne suffiraient pas à établir l’avantage de Databricks. Elles montreraient que la mémoire gérée est devenue une autre dimension du choix de plateforme. Des preuves que les applications peuvent préserver un comportement utile entre différents services clarifieraient aussi le niveau de portabilité auquel les acheteurs peuvent s’attendre.

Ces signaux doivent être considérés ensemble, car l’achat concerne un système continu. La performance sans contrôle crée des questions opérationnelles difficiles. Le contrôle sans amélioration utile des tâches laisse les acheteurs maintenir une fonctionnalité supplémentaire dont la valeur demeure incertaine.

Pour les travailleurs du savoir, le résultat devrait être visible dans l’usage ordinaire. Un assistant devrait nécessiter moins de corrections répétées tout en restant réactif lorsque les circonstances changent. Mémoriser une hypothèse obsolète avec davantage de cohérence manquerait l’objectif.

Pour les développeurs, l’annonce crée une expérience ciblée. Sélectionnez un flux de travail récurrent présentant des échecs identifiables liés à la mémoire, puis comparez les résultats dans des conditions cohérentes. Séparez les éléments en direct des conseils mémorisés et examinez les cas où les informations historiques devraient rester absentes de la réponse.

Introducing Agent Memory on Databricks donne aux équipes d’entreprise un service concret à évaluer par rapport à leur approche existante. Commencez par le travail que votre agent exécute à plusieurs reprises de façon incorrecte ou qu’il répète inutilement. Identifiez quelles corrections méritent de persister et quels faits doivent rester liés à des sources actuelles. Examinez ensuite si le contexte conservé améliore les décisions ultérieures sans faire perdurer des hypothèses obsolètes. Demandez qui peut inspecter une mémoire, qui peut la modifier et ce que signifie sa suppression dans l’ensemble de l’application. Considérez les benchmarks publiés comme une hypothèse qui mérite d’être testée sur vos propres tâches. Avant d’étendre l’adoption, votre équipe peut-elle démontrer que l’agent retient la bonne leçon et cesse de l’utiliser lorsque cette leçon ne s’applique plus ?