La mémoire de NVIDIA NeMo Agent Toolkit passe à Amazon S3 Vectors, mais la qualité de la récupération reste déterminante

NVIDIA dispose d’une nouvelle voie pour la mémoire persistante des agents, AWS ayant publié une implémentation en trois volets reposant sur Amazon S3 Vectors et Amazon EKS. L’intégration de mémoire de NVIDIA NeMo Agent Toolkit remplace une base de données vectorielle dédiée par un stockage vectoriel géré que les agents peuvent partager entre les sessions.

AWS a publié cette implémentation le 1er octobre 2026. Elle connecte le framework d’agents open source de NVIDIA à un fournisseur S3 Vectors personnalisé, puis déploie le workflow obtenu sur Kubernetes. L’enjeu central est opérationnel : les équipes bénéficient d’un stockage durable et léger en infrastructure, mais restent responsables des politiques de sélection, d’isolation, d’évaluation et de suppression des mémoires.

Cette distinction compte, car la mémoire persistante devient une composante de l’état applicatif des agents en production. Redis, Zep, Mem0 et d’autres fournisseurs spécialisés proposent des fonctionnalités davantage orientées mémoire. AWS défend plutôt l’idée que le stockage d’objets peut devenir la couche de récupération durable lorsque l’échelle, la cohérence et les contrôles d’accès AWS priment.

AWS transforme la mémoire de NVIDIA NeMo Agent Toolkit en charge de travail S3

L’annonce transforme une proposition architecturale en une implémentation concrète que les développeurs peuvent examiner, déployer et tester.

L’implémentation AWS relie trois produits. NVIDIA NeMo Agent Toolkit, ou NAT, orchestre et évalue les agents. Amazon S3 Vectors stocke des mémoires interrogeables. Amazon EKS exécute les services d’agents avec les contrôles Kubernetes.

NAT est un framework open source destiné à créer, profiler, évaluer et optimiser des workflows d’agents. Il peut fonctionner avec des implémentations d’agents basées sur LangChain, LlamaIndex, CrewAI, Strands Agents ou du code personnalisé.

Son sous-système de mémoire conserve des informations au-delà d’une seule invocation de modèle. Ces informations peuvent inclure l’historique des conversations, les préférences utilisateur, des résultats antérieurs ou des connaissances procédurales. Un fournisseur récupère les entrées pertinentes lorsqu’un autre agent a besoin de contexte.

Le framework expose une interface MemoryEditor avec trois opérations essentielles : ajouter des éléments, rechercher des mémoires et supprimer des éléments. Chaque élément peut contenir des données de conversation, des balises, des métadonnées, un identifiant utilisateur et une représentation textuelle de la mémoire.

Cette abstraction permet aux développeurs d’ajouter un backend sans repenser les agents qui l’utilisent. AWS implémente l’interface au moyen d’un plugin personnalisé appelé s3vectors_memory, que NAT découvre via sa configuration YAML.

La conception de référence crée un bucket vectoriel et un index vectoriel. Un bucket vectoriel est une ressource S3 conçue spécifiquement pour les données vectorielles, tandis qu’un index organise les embeddings pour la recherche de similarité.

L’exemple configure 1 024 dimensions et la similarité cosinus. Ces choix correspondent à Amazon Titan Text Embeddings V2, qui convertit chaque mémoire en une représentation numérique de sa signification.

Le fournisseur envoie le texte au modèle d’embedding via Amazon Bedrock. Il stocke ensuite le vecteur obtenu avec des métadonnées décrivant son origine et son périmètre autorisé.

Lorsqu’un agent interroge sa mémoire, le fournisseur transforme la requête en embedding et appelle l’API de similarité S3 Vectors. Il convertit les enregistrements renvoyés en objets NAT MemoryItem avant de les réinjecter dans le workflow.

L’implémentation traduit également les restrictions au niveau des agents en filtres de métadonnées. Elles peuvent inclure agent_id, memory_type, ticker, team_id, user_id et l’indication qu’un enregistrement est partagé.

Cette étape de filtrage est plus importante que la recherche de similarité de base. Une mémoire sémantiquement pertinente reste erronée si elle appartient à un autre client, à un autre rôle d’agent ou à une tâche analytique obsolète.

AWS marque le contenu complet de la mémoire comme métadonnée non filtrable. Le système renvoie ce texte avec un vecteur correspondant, mais n’utilise pas son quota de métadonnées filtrables pour indexer le contenu lui-même.

Cette approche est conforme aux recommandations d’AWS pour les grands champs de référence. Les développeurs peuvent réserver les filtres aux champs compacts qui contrôlent la récupération, notamment l’identité, le temps, la catégorie et la propriété.

L’exemple a été testé avec NVIDIA NeMo Agent Toolkit 1.6 et Python 3.11 ou 3.12. Il suppose également l’existence d’un cluster EKS, de Docker, de kubectl, d’un accès à Bedrock et des autorisations nécessaires pour les ressources S3 Vectors.

Cette liste de prérequis fait de l’annonce davantage qu’un connecteur prêt à l’emploi. Il s’agit d’une architecture de référence pour les équipes déjà disposées à exploiter des agents dans AWS et Kubernetes.

La mémoire persistante transforme la recherche multi-agents

La mémoire partagée permet à des agents spécialisés de réutiliser des travaux antérieurs, mais elle fait aussi du contexte récupéré une dépendance que les équipes doivent gouverner.

AWS illustre cette conception avec un workflow de recherche en investissement. Trois agents spécialisés se répartissent le travail entre recherche, analyse et synthèse.

L’agent de recherche collecte des informations de marché, des documents sur les résultats financiers et des actualités. L’agent d’analyse recherche des tendances quantitatives. L’agent de synthèse rassemble ces résultats dans un rapport.

Sans mémoire persistante, chaque exécution démarre avec une connaissance limitée des travaux précédents. Les agents peuvent répéter la même recherche, recalculer un résultat antérieur ou produire des conclusions incohérentes parce que leurs contextes temporaires diffèrent.

Un stockage persistant modifie ce comportement. L’agent de recherche peut enregistrer une observation avec son ticker, son type de mémoire, le contexte source et son statut de partage. Un autre agent autorisé peut ensuite la récupérer grâce à la similarité sémantique et aux filtres de métadonnées.

La récupération sémantique recherche par le sens au lieu d’exiger des mots-clés exacts. Elle peut donc rapprocher une question sur la baisse des marges d’une observation stockée qui emploie un vocabulaire différent.

L’approche sépare également la mémoire d’une fenêtre de contexte de modèle particulière. Une fenêtre de contexte correspond à la quantité limitée d’entrées qu’un modèle peut traiter au cours d’une requête. Les enregistrements persistants restent disponibles après la fin de cette requête.

Cette architecture ne signifie pas que chaque enregistrement stocké doit figurer dans chaque prompt. La récupération sélectionne un petit groupe de candidats, souvent appelés résultats top-k, avant que l’agent décide de leur utilisation.

L’exemple AWS fixe la valeur top-k par défaut à cinq. Cette valeur est un choix de configuration, et non un optimum universel. Un ensemble de résultats plus réduit peut limiter le bruit, tandis qu’un ensemble plus large peut améliorer la couverture au prix de tokens supplémentaires et d’éventuelles distractions.

L’enveloppe de mémoire automatique de NAT peut capturer et récupérer des informations sans obliger le modèle à appeler des outils de mémoire explicites. Cela réduit la complexité des prompts, mais déplace aussi un comportement important vers la configuration système.

L’interface mémoire NVIDIA fournit le contrat nécessaire à ces fournisseurs. Elle ne détermine pas quels faits méritent une conservation à long terme ni à quel moment une ancienne mémoire devient peu fiable.

Pour les équipes qui créent des systèmes de recherche agentiques, cela ajoute une nouvelle couche d’ingénierie. Elles ont besoin de règles pour extraire les mémoires, consolider les doublons, résoudre les contradictions et supprimer les affirmations obsolètes.

L’exemple d’investissement présente trois classes de mémoire utiles. La mémoire épisodique enregistre ce qui s’est produit lors d’une exécution antérieure. La mémoire sémantique stocke un fait ou une relation. La mémoire procédurale conserve une méthode efficace ou une séquence d’actions.

Ces catégories peuvent justifier différentes politiques de conservation. Une date de dépôt vérifiée peut rester utile pendant des années, tandis qu’un prix de marché ou une interprétation d’actualité urgente peut rapidement expirer.

Elles peuvent aussi exiger des règles d’accès différentes. Une méthode d’analyse peut être partagée au sein d’une équipe. Les détails du portefeuille d’un utilisateur doivent rester isolés, même si la requête d’un autre utilisateur paraît sémantiquement similaire.

C’est à ce stade que la mémoire de NVIDIA NeMo Agent Toolkit devient un enjeu de conception applicative plutôt qu’une fonctionnalité de stockage. Le backend peut renvoyer un enregistrement correspondant, mais l’application définit si cette correspondance est actuelle, autorisée et utile.

Ce défi ressemble à la gestion des connaissances personnelles, mais à une autre échelle. Capturer davantage d’informations ne produit pas automatiquement une meilleure capacité de rappel. Le système doit préserver la provenance et récupérer les bonnes preuves au bon moment.

Les équipes qui explorent le versant orienté utilisateur de ce problème peuvent le comparer à une base de connaissances personnelle, où la propriété et le contexte déterminent également si les informations stockées sont utiles.

La conception AWS fournit aux équipes d’agents une base de stockage réutilisable. Sa véritable valeur dépendra des politiques superposées à cette fondation.

S3 Vectors remet en cause le choix par défaut d’une base de données vectorielle dédiée

AWS positionne S3 Vectors comme un niveau de mémoire durable, et non comme un remplacement complet de tous les systèmes de récupération à faible latence.

NAT prend déjà en charge des fournisseurs de mémoire tels que Mem0, MemMachine, Redis et Zep. Ces options représentent différentes approches de la mémoire d’agent, allant de l’infrastructure de données en mémoire à des services conçus autour de l’extraction et de la gestion de mémoire.

L’intégration S3 Vectors ajoute une autre voie. Les développeurs peuvent conserver l’interface d’orchestration de NAT tout en plaçant les embeddings dans un stockage qui ne nécessite pas de serveurs vectoriels provisionnés.

AWS indique que S3 Vectors assure des écritures fortement cohérentes. Une écriture réussie devient immédiatement disponible pour la récupération, ce qui est important lorsque plusieurs agents se coordonnent via le même index.

La cohérence éventuelle introduirait un mode de défaillance difficile. Un agent pourrait enregistrer une découverte importante, tandis qu’un autre commencerait à travailler avant que cette mémoire ne devienne visible.

La forte cohérence réduit cet écart de coordination. Elle ne garantit pas que les agents soient d’accord avec la conclusion stockée, mais assure qu’ils peuvent récupérer la dernière écriture réussie.

L’échelle constitue un autre élément de l’argumentaire d’AWS. Les limites documentées de S3 Vectors autorisent jusqu’à deux milliards de vecteurs dans un index et 10 000 index dans un bucket vectoriel.

Le service prend en charge des dimensions vectorielles de un à 4 096. Chaque vecteur peut contenir jusqu’à 40 Ko de métadonnées au total, dont jusqu’à 2 Ko de métadonnées filtrables.

Ces limites favorisent de grandes collections d’embeddings compacts et d’attributs structurés. Elles obligent aussi les équipes à concevoir soigneusement leurs métadonnées plutôt que d’attacher un état applicatif illimité à chaque vecteur.

S3 Vectors propose les métriques de distance cosinus et euclidienne. La métrique choisie et le nombre de dimensions ne peuvent pas être modifiés après la création d’un index ; une migration de modèle peut donc nécessiter un nouvel index et un processus de ré-embedding.

Cette immuabilité mérite attention. Les modèles d’embedding évoluent, et leurs dimensions de sortie ou calculs de distance recommandés peuvent différer. Les systèmes d’agents conçus pour durer ont besoin d’un plan de versionnage et de migration avant que le premier index ne devienne essentiel.

AWS décrit une latence de requête inférieure à la seconde pour les accès peu fréquents, et pouvant descendre à 100 millisecondes pour les accès plus fréquents. Ce profil convient davantage à la récupération de mémoire durable qu’à toutes les interactions en temps réel.

Un assistant vocal soumis à des délais de réponse stricts peut toujours nécessiter une couche de service ou un cache plus rapide. Un agent de recherche asynchrone peut souvent tolérer une recherche supplémentaire inférieure à la seconde lorsque l’inférence du modèle domine déjà le workflow.

AWS oriente également les clients vers OpenSearch lorsqu’ils ont besoin de fonctions de recherche avancées telles que la récupération hybride, les agrégations, la recherche à facettes ou des taux de requêtes plus élevés. Cette distinction limite toute affirmation selon laquelle S3 Vectors remplacerait la catégorie plus large des bases de données vectorielles.

L’adversaire principal est donc architectural, non concurrentiel. Les équipes peuvent exploiter un service de récupération dédié aux fonctionnalités plus riches, ou utiliser un stockage vectoriel managé fondé sur les objets pour une mémoire durable nécessitant moins d’intervention.

Il ne s’agit pas d’un choix où le gagnant rafle tout. Un système mature peut utiliser S3 Vectors comme registre durable et ajouter une couche de recherche plus rapide pour les mémoires fréquemment consultées ou sensibles à la latence.

L’avantage de l’abstraction de fournisseur de NAT est la portabilité au niveau de l’orchestration. Le risque est qu’une interface commune puisse masquer des différences significatives entre les backends.

Une méthode search() paraît uniforme dans le code, mais la qualité du rappel, la sémantique du filtrage, le comportement d’indexation, le débit et les modes de défaillance varient toujours. Les développeurs doivent mesurer ces différences sur leurs propres données.

L’annonce d’AWS met sous pression les fournisseurs spécialisés dans la mémoire et les fournisseurs de bases de données vectorielles, qui doivent justifier leur infrastructure supplémentaire. Ils doivent démontrer qu’une extraction, un classement, une observabilité ou une latence améliorés produisent de meilleurs résultats pour les agents.

Dans le même temps, l’intégration pousse les utilisateurs d’AWS à prouver que la réduction de la charge opérationnelle ne masque pas des compromis sur la récupération. Un stockage durable n’a de valeur que si la bonne mémoire apparaît dans le contexte de l’agent.

Amazon EKS apporte du contrôle, avec la responsabilité opérationnelle associée

EKS rend la couche agent évolutive et gouvernable, tout en laissant aux équipes la responsabilité des contrôles entre les identités Kubernetes et les mémoires stockées.

La référence AWS déploie l’agent de recherche comme service Kubernetes. Son manifeste d’exemple démarre avec deux réplicas et attribue au conteneur des demandes définies en CPU et en mémoire.

Un Horizontal Pod Autoscaler peut ramener le déploiement à un réplica ou l’étendre à 10. L’exemple cible une utilisation moyenne du CPU de 70 %.

Chaque réplica se connecte au même index vectoriel S3. Cette conception dissocie l’exécution des agents du stockage de la mémoire, de sorte qu’un pod redémarré n’efface pas les résultats antérieurs.

Elle empêche également qu’un réplica particulier devienne propriétaire de l’historique d’une conversation. Tout pod autorisé peut récupérer les mêmes mémoires validées.

L’architecture utilise IAM Roles for Service Accounts, communément appelé IRSA. Ce mécanisme associe un compte de service Kubernetes à une identité AWS, évitant les identifiants à longue durée de vie dans l’image du conteneur.

La stratégie d’exemple accorde quatre opérations vectorielles : l’ajout, l’interrogation, la récupération et la suppression de vecteurs. Son périmètre de ressources pointe vers le bucket de mémoire désigné.

Ce modèle d’autorisation offre une base utile. Les systèmes de production ont néanmoins besoin de rôles distincts lorsque les agents ont des responsabilités ou des périmètres de données différents.

Un agent de synthèse pourrait n’exiger qu’un accès en lecture. Un agent de recherche pourrait ajouter des enregistrements sans disposer de droits de suppression en masse. Un service administratif de maintenance pourrait gérer l’expiration et les suppressions via un rôle distinct.

La documentation AWS indique que les buckets vectoriels appliquent toujours Block Public Access. La vue d’ensemble de S3 Vectors prend également en charge les contrôles IAM et à l’échelle de l’organisation pour les buckets et les index.

Ces contrôles peuvent isoler les ressources d’infrastructure. Ils n’appliquent pas automatiquement chaque règle au niveau de l’application encodée dans les métadonnées vectorielles.

Si plusieurs locataires partagent un index, l’absence d’un filtre user_id ou team_id peut exposer une mémoire sans rapport au workflow demandeur. La recherche par similarité renverra des résultats mathématiquement proches sans comprendre la frontière métier.

Des index distincts peuvent offrir une isolation plus stricte. AWS recommande ce modèle pour les charges de travail multi-locataires dont les requêtes restent propres à chaque locataire.

Ce choix crée son propre compromis de gestion. Davantage d’index améliorent l’isolation et peuvent répartir la charge de requêtes, mais ils augmentent aussi le travail de provisionnement, de stratégie, de migration et de supervision.

Les équipes doivent également examiner l’enveloppe de débit. AWS documente jusqu’à 1 000 requêtes combinées d’écriture ou de suppression par seconde pour chaque index.

Le service autorise également jusqu’à 2 500 vecteurs insérés ou supprimés par seconde et par index. Les applications peuvent regrouper jusqu’à 500 vecteurs dans une seule requête d’écriture.

Pour les lectures, AWS indique qu’un index peut prendre en charge des centaines de requêtes de consultation, de récupération ou de liste par seconde. Dépasser les limites de débit du service peut renvoyer une TooManyRequestsException.

Les conseils S3 Vectors recommandent de regrouper les écritures, d’implémenter des tentatives de reprise et de répartir les charges de travail adaptées entre plusieurs index.

Ces limites ne devraient guère contraindre une petite équipe de recherche. Elles comptent lorsqu’une plateforme d’agents enregistre plusieurs mémoires pour chaque interaction sur une vaste base de clients.

L’autoscaling des pods Kubernetes ne peut pas supprimer une limite de requêtes côté stockage. Ajouter des réplicas peut en réalité augmenter les requêtes simultanées et révéler plus rapidement la limitation du débit.

L’observabilité doit donc relier les deux couches. Les équipes ont besoin des métriques NAT sur la latence, les tokens et les trajectoires des agents, ainsi que des données sur la santé d’EKS et la limitation ou les erreurs de S3 Vectors.

Le contrôle opérationnel est la raison pour laquelle AWS utilise EKS dans cette conception. C’est aussi la source de complexité supplémentaire.

Une équipe qui choisit cette voie prend en charge les builds de conteneurs, les mises à niveau du cluster, les politiques réseau, le comportement de l’autoscaling et les identités de service. Les plateformes d’agents serverless ou les fournisseurs de mémoire hébergée peuvent supprimer une partie de ce travail.

La bonne comparaison n’oppose pas simplement le stockage managé aux bases de données dédiées. Elle concerne le système dans son ensemble, y compris les opérations Kubernetes, les appels d’embedding, les politiques de mémoire, l’évaluation et la réponse aux incidents.

La qualité de la récupération reste la partie non démontrée de la conception mémoire de NVIDIA NeMo Agent Toolkit

AWS fournit des attentes directionnelles, et non des résultats de benchmark montrant que cette couche mémoire améliore les réponses des agents.

L’article propose deux exécutions d’évaluation NAT utilisant le même jeu de données. L’une active la mémoire, tandis que l’autre fournit une référence sans mémoire.

NAT peut mesurer la précision, l’ancrage factuel, l’utilisation des tokens et la latence. L’ancrage factuel évalue si une réponse suit le contexte fourni, tandis que l’évaluation de trajectoire examine la séquence d’actions de l’agent.

AWS s’attend à ce que les mémoires rappelées améliorent l’ancrage, réduisent le travail répété et diminuent l’utilisation des tokens lorsque les workflows réutilisent un contexte antérieur. L’entreprise prévoit également que chaque requête mémoire ajoute une certaine latence.

L’entreprise décrit explicitement ces résultats comme directionnels plutôt que benchmarkés. Leur ampleur dépend de la charge de travail, du budget de récupération, du niveau de répétition et de la coordination entre agents.

Cette réserve est essentielle pour évaluer la mémoire de NVIDIA NeMo Agent Toolkit. Aucun résultat publié dans l’annonce n’établit un gain universel de précision ou une réduction des tokens.

La mémoire peut améliorer un agent lorsque les enregistrements récupérés contiennent des éléments vérifiés et pertinents. Elle peut aussi amplifier les erreurs lorsque le stockage contient une conclusion incorrecte ou une interprétation obsolète.

Le risque augmente dans les workflows multi-agents, car la sortie d’un agent peut devenir l’entrée d’un autre. Une affirmation fragile peut acquérir une fausse crédibilité après que plusieurs systèmes l’ont récupérée et reformulée.

La recherche en investissement rend ce danger facile à observer. Les résultats financiers peuvent être révisés, les prévisions peuvent changer et les données de marché deviennent rapidement obsolètes.

Un élément de mémoire devrait donc inclure davantage qu’un ticker et du texte. Les métadonnées utiles peuvent inclure l’identité de la source, la date de publication, la date d’observation, le statut de vérification et une règle d’expiration.

La récupération doit également distinguer les preuves primaires de l’interprétation générée par l’agent. Un document réglementaire cité et le résumé de ce document par un modèle ne devraient pas avoir la même autorité.

La suppression est une autre préoccupation non résolue. Le fournisseur de NAT prend en charge la suppression d’enregistrements, et S3 Vectors expose des opérations de suppression. L’application doit néanmoins déterminer quels identifiants supprimer et comment satisfaire une demande de retrait au niveau de l’utilisateur.

Cela devient plus difficile lorsque la même information apparaît dans des mémoires consolidées. Un agent ultérieur pourrait combiner plusieurs enregistrements dans un nouveau résumé avec une clé vectorielle différente.

Les tests de sécurité doivent couvrir davantage que l’accès à l’infrastructure. Un attaquant pourrait insérer du texte conçu pour manipuler des agents ultérieurs, créant une forme persistante d’injection de prompt.

Les filtres de métadonnées réduisent l’exposition entre utilisateurs, mais n’évaluent pas la sécurité du contenu stocké. Les systèmes ont besoin d’une validation avant le stockage et de contrôles sur la manière dont le texte récupéré entre dans un prompt de modèle.

La question du classement se pose également. La similarité vectorielle de base identifie les enregistrements sémantiquement proches, mais la proximité n’équivaut ni à la vérité, ni à la fraîcheur, ni à l’autorité.

Un pipeline de récupération de production peut reclasser les candidats selon la date, la qualité de la source, la pertinence pour la tâche ou un modèle supplémentaire. Le fournisseur d’exemple conserve volontairement un mécanisme simple.

Cette simplicité rend le code compréhensible. Elle signifie aussi que les lecteurs devraient le considérer comme une base plutôt que comme un système achevé de gouvernance de la mémoire.

L’évaluation nécessite des cas adversariaux, et pas seulement des scores moyens par tâche. Les équipes devraient tester des mémoires contradictoires, des utilisateurs supprimés, des données obsolètes, des métadonnées malformées, des requêtes limitées et des endpoints d’embedding indisponibles.

Elles devraient également comparer le fournisseur S3 aux backends de mémoire existants de NAT. Une référence sans mémoire révèle si la persistance aide, mais elle ne montre pas si S3 Vectors est la meilleure option de persistance.

L’expérience la plus utile maintiendrait constants les prompts, les modèles et les jeux de données entre plusieurs fournisseurs. Elle rendrait ensuite compte du rappel de récupération, de la qualité des réponses, de la distribution de la latence, de la consommation de tokens et des taux de défaillance opérationnelle.

En attendant ces éléments, AWS a démontré la faisabilité plutôt que la supériorité. L’intégration prouve que NAT peut utiliser S3 Vectors via son contrat de fournisseur.

Elle ne prouve pas que chaque charge de travail d’agent bénéficie d’une mémoire persistante, ni que le stockage vectoriel fondé sur les objets surpasse un système de service spécialisé pour chaque profil d’accès.

Trois signaux montreront si la mémoire d’agent adossée à S3 tient la route

Le prochain test consistera à déterminer si les développeurs peuvent transformer une architecture de référence fonctionnelle en mémoire de production mesurable et gouvernée.

Premièrement, surveillez les évaluations reproductibles de la qualité de la mémoire. Les équipes devraient publier des comparaisons entre des exécutions avec mémoire et sans mémoire utilisant des tâches, modèles et prompts identiques.

Ces résultats doivent aller au-delà de la précision moyenne. Ils devraient inclure la précision de récupération, les échecs dus à une mémoire obsolète, la latence p95, les variations de tokens et le taux de travail d’agent dupliqué.

Des preuves de gains constants renforceraient l’affirmation d’AWS selon laquelle une mémoire partagée durable améliore la coordination multi-agents. Des résultats mitigés montreraient que la sélection de mémoire compte davantage que le backend de stockage.

Deuxièmement, observez comment NVIDIA et AWS développent l’expérience fournisseur. Le modèle actuel exige du code de plugin personnalisé, des appels d’embedding Bedrock, une conception des métadonnées, une configuration YAML, le packaging de conteneurs, IAM et un déploiement EKS.

Une intégration officiellement maintenue, un package réutilisable ou un modèle de déploiement testé réduirait les frictions d’adoption. Une meilleure prise en charge des migrations aiderait également les équipes lorsqu’elles changent de modèles d’embedding ou de schémas d’index.

La configuration actuelle de l’index est fixée à sa création pour les dimensions et la métrique de distance. Les utilisateurs en production ont besoin de modèles documentés de versionnement, de double écriture, de remplissage historique et de basculement.

Troisièmement, observez comment les équipes de production partitionnent et gouvernent la mémoire. Le signal décisif sera de savoir si elles choisissent des index partagés avec filtres de métadonnées ou des index distincts pour une isolation plus forte des locataires.

Les déploiements réels devraient révéler des stratégies pratiques de rétention, de suppression, de provenance et de détection de mémoire empoisonnée. Ils devraient également montrer si S3 Vectors conserve une latence acceptable sous un trafic d’agents simultané.

La référence AWS plaide de manière convaincante en faveur du transfert de la mémoire persistante des agents vers un stockage vectoriel managé. Elle offre aux développeurs une frontière de plugin concrète, un modèle de déploiement et un point de départ pour l’évaluation.

Son implication plus large est que la mémoire se dissocie du framework d’agents lui-même. L’orchestration peut rester dans NVIDIA NeMo Agent Toolkit, tandis que l’état réside dans un service gouverné de manière indépendante.

Cette séparation peut faciliter la mise à l’échelle et le remplacement des systèmes. Elle peut aussi créer des dépendances cachées lorsque les équipes supposent que retrouver un enregistrement sémantiquement similaire revient à se souvenir correctement.

Les développeurs qui évaluent la mémoire de NVIDIA NeMo Agent Toolkit devraient commencer par un workflow circonscrit et un jeu de tests étiqueté. Comparez-la à une absence de mémoire et à au moins un fournisseur alternatif.

Testez ensuite l’isolation, la suppression, les enregistrements obsolètes et les contenus adversariaux avant d’élargir l’accès. Si ces vérifications sont concluantes, S3 Vectors devient plus qu’une persistance peu coûteuse. Il devient une couche de mémoire partagée crédible pour les agents opérant entre différentes sessions et répliques.