AWS a ajouté à Bedrock AgentCore un stockage de session persistant et l'exécution de commandes shell

AWS a ajouté le stockage persistant des sessions et l'exécution de commandes shell à Bedrock AgentCore

AWS a démontré comment résoudre deux problèmes typiques des environnements d'agents dans Amazon Bedrock AgentCore Runtime : la perte de fichiers après l'arrêt de la session et l'exécution de commandes prévisibles comme les tests ou les opérations git via le modèle lui-même. Les nouvelles capacités permettent de préserver l'état de travail d'un agent entre les redémarrages et d'exécuter des commandes shell directement dans son environnement.

Ce qui change

Autrefois, une session d'agent dans AgentCore vivait à l'intérieur d'une microVM séparée avec des ressources isolées, sa propre mémoire et son propre système de fichiers. C'est bon pour la sécurité, mais peu pratique en réalité : si un agent a passé 20 minutes à installer des dépendances, générer un projet et modifier du code, tout cela pourrait disparaître après l'arrêt de la session. Au lancement suivant, vous devriez télécharger à nouveau le référentiel, déployer l'environnement et refaire le travail déjà complété. Pour les flux de travail des agents, cela signifiait du temps perdu et des coûts de calcul inutiles.

Le deuxième problème concerne les actions déterministes. Quand vous avez simplement besoin d'exécuter une suite de tests, un linter ou une commande git push, il n'y a aucun intérêt à la faire passer par un LLM. Le modèle ajoute de la latence, des coûts de tokens et une incertitude inutile là où la commande est déjà connue d'avance. AWS propose de diviser les rôles : l'agent gère le raisonnement et les modifications de code, tandis que la plateforme exécute directement les commandes dans la même session. Pour les scénarios de production, cette séparation des responsabilités semble beaucoup plus pratique.

Comment cela fonctionne

La première fonction — stockage de session géré — est actuellement en statut de préversion publique. Lors de la création d'un runtime, vous pouvez spécifier un répertoire persistant, comme un chemin dans le répertoire /mnt. Tout ce que l'agent écrit dans ce dossier est conservé entre l'arrêt et la reprise, même si la microVM elle-même est détruite et qu'un nouvel environnement de calcul est lancé au prochain démarrage. En même temps, la logique d'enregistrement est intégrée au runtime, donc l'agent n'a pas besoin de code séparé pour les points de contrôle, la sérialisation ou le téléchargement manuel de fichiers vers le stockage d'objets.

AWS montre un scénario proche du développement réel : le premier jour, l'agent télécharge le projet, le décompresse et configure les dépendances, et le deuxième jour continue à travailler avec le même runtime-session-id. Il voit le même code source, le dossier node_modules, les artefacts de compilation et l'historique .git sans réinitialisation.

Par défaut, ces données sont stockées pendant 14 jours d'inactivité, et la taille maximale par session est de 1 Go. Pour les équipes travaillant avec de grandes bases de code, c'est déjà suffisant pour un cycle complet de plusieurs jours.

L'environnement de calcul d'hier a déjà disparu, mais le système de

fichiers a été préservé.

La deuxième fonction — InvokeAgentRuntimeCommand. Elle exécute des commandes shell directement dans la session AgentCore Runtime active et diffuse en continu stdout et stderr au fur et à mesure de l'exécution. Un détail important : la commande s'exécute non pas dans un processus sidecar séparé ni via un orchestrateur externe, mais dans le même conteneur et avec le même système de fichiers où l'agent opère. Si l'agent a écrit un fichier dans le dossier de travail, la commande peut immédiatement le lire, le tester ou le valider. En même temps, chaque commande démarre comme un processus bash séparé : sans session de shell partagée, sans transfert d'historique de commandes et sans conservation des variables d'environnement entre les appels.

Où cela sera utile

Pour les équipes d'ingénierie, cette combinaison est particulièrement utile dans les scénarios où un agent ne fait pas seulement répondre dans un chat, mais mène réellement un cycle de travail sur une base de code. AWS souligne spécifiquement que les commandes shell sont mieux utilisées là où le résultat doit être strictement reproductible et observable. En d'autres termes, le modèle raisonne et apporte des modifications, tandis que toutes les étapes prévisibles de vérification et de livraison sont mieux confiées à la plateforme sans appels d'outils inutiles via le LLM.

• Exécution des tests après les modifications de l'agent : npm test, pytest et autres vérifications
• Opérations git : création de branche, commit, push sans logique de contrôle de version à l'intérieur du LLM
• Préparation de l'environnement : clonage du référentiel, installation des paquets, configuration des outils de compilation
• Portails de validation : linters, vérificateurs de type, scanners de sécurité avant le commit
• Débogage de l'environnement : vérification des paquets installés, de l'espace disque et des processus en cas d'échec de l'agent

Il y a aussi des limitations. La microVM de base n'a pas un ensemble complet d'outils de développement, donc git, npm, les runtimes de langage et les autres dépendances doivent être ajoutés à l'image du conteneur au préalable ou installés pendant l'opération. De plus, l'état n'est pas conservé entre les commandes, donc changer de répertoire ou exporter des variables doit être inclus directement dans la commande elle-même. C'est un modèle d'exécution unique qui fonctionne bien pour les tests et les compilations, mais ne remplace pas une session de shell interactive en direct.

Ce que cela signifie

AWS rapproche Bedrock AgentCore non pas des chatbots, mais d'un environnement à part entière pour le développement d'agents. Si auparavant l'agent perdait le contexte au niveau des fichiers et nécessitait une intégration externe pour les tests et les commandes git, maintenant les deux tâches sont traitées au sein d'un seul runtime. Pour les équipes qui construisent des agents de codage, cela réduit l'orchestration inutile et rend le cycle « l'agent écrit — la plateforme vérifie — le travail est enregistré » notablement plus pratique. Surtout là où un processus de plusieurs jours de travail sur le même référentiel est important.