Publié le 6 octobre 2026, le tutoriel d’AWS décrit Sprout, un assistant de jardinage qui associe OpenClaw à Amazon Bedrock AgentCore Runtime et AgentCore Memory. Le principe : faire converger Telegram et les tâches planifiées vers un même agent, puis extraire les souvenirs à long terme de façon asynchrone. Voici comment s’articulent les différentes briques et les deux parcours de déploiement proposés.
Comment deux points d’entrée atteignent le même agent
Le modèle sépare les portes d’entrée, mais pas l’agent qui traite les demandes. Un message Telegram passe par API Gateway, puis par une fonction Lambda de webhook. Une tâche planifiée suit une autre voie : Amazon EventBridge Scheduler déclenche une fonction Lambda dédiée aux tâches récurrentes. Les deux chemins invoquent ensuite le même agent dans AgentCore Runtime.
Pour reproduire cette architecture, il faut donc penser à la fois au canal de conversation et aux tâches automatiques :
- Relier Telegram au webhook. API Gateway reçoit les requêtes Telegram et les transmet à la fonction Lambda de webhook.
- Configurer les tâches planifiées. EventBridge Scheduler déclenche la fonction Lambda prévue pour ces tâches.
- Diriger les deux voies vers le runtime. Les fonctions invoquent le même agent hébergé dans AgentCore Runtime.
Cette séparation permet au canal de messagerie et aux rappels programmés d’utiliser un agent commun, plutôt que deux assistants distincts.
Le contrat du runtime et les modèles utilisés
Dans l’exemple d’AWS, un wrapper Python nommé server.py relie AgentCore Runtime à la passerelle OpenClaw. Il écoute sur le port 8080, expose GET /ping pour le contrôle de santé et reçoit les demandes sur POST /invocations. Le wrapper vérifie aussi l’état de la passerelle OpenClaw lors d’une invocation et la redémarre si nécessaire.
Le choix du modèle dépend du type de demande : Claude Haiku 4.5 traite le texte via la passerelle OpenClaw ; Claude Sonnet 4.5 est appelé directement par server.py pour les images. Dans la version décrite par AWS, ce détour répond à un comportement particulier de l’image du conteneur OpenClaw utilisée dans l’exemple : elle écartait les parties de contenu image_url. Les images sont donc envoyées directement à Amazon Bedrock sous forme de données binaires. Les deux voies conservent le même prompt de personnalité et de mémoire.
Comment les échanges alimentent la mémoire à long terme
AgentCore Memory distingue les événements de conversation à court terme des informations extraites pour des usages ultérieurs. À chaque tour, l’exemple recherche des souvenirs à partir du message courant, puis insère les éléments retenus dans le prompt système. Il enregistre aussi les échanges de l’utilisateur et de l’assistant pour alimenter la mémoire.
L’extraction à long terme s’effectue de façon asynchrone selon trois stratégies : USER_PREFERENCE, SEMANTIC et SUMMARIZATION. Un fait qui vient d’être mentionné peut donc n’être récupérable que lors d’une session ultérieure ; les événements à court terme couvrent la conversation en cours.
Pour la récupération, la configuration présentée par AWS prévoit un plafond de 50 enregistrements et un budget de 3 secondes. Les préférences explicites passent avant les informations inférées lors de l’assemblage du prompt. Si la récupération échoue, l’assistant peut tout de même répondre, mais sans les souvenirs récupérés.
Dans l’exemple Sprout, les espaces de mémoire sont associés à l’identifiant du chat Telegram. Les métadonnées indexées — type, section et plants — servent aux filtres côté serveur. Cette organisation relie les souvenirs à la conversation concernée sans transformer la mémoire en dépendance obligatoire pour chaque réponse.
Choisir entre le Launch Stack et une image personnalisée
AWS décrit deux façons de déployer l’exemple. Le Launch Stack s’appuie sur une image publique hébergée dans Amazon ECR et demande un jeton de bot Telegram. Le parcours personnalisé construit et pousse une image privée linux/arm64, déploie la pile CloudFormation et enregistre le webhook Telegram.
| Parcours | Image | Prérequis indiqués | Opérations décrites |
| Launch Stack | Image publique dans Amazon ECR | Jeton de bot Telegram | Lancer la pile CloudFormation à partir de l’image publique. |
| Image personnalisée | Image linux/arm64 construite puis poussée dans un registre privé | Docker avec prise en charge de la compilation linux/arm64 et AWS CLI configurée | Valider le modèle CloudFormation, construire et pousser l’image, déployer la pile et enregistrer le webhook Telegram. |
Le Launch Stack évite de construire une image personnalisée. Le second parcours donne la main sur cette image et demande les outils de compilation ainsi qu’une configuration AWS CLI.
Services associés et suppression de la pile
L’architecture décrite utilise Amazon S3 pour le stockage de l’espace de travail, AWS Key Management Service (KMS) pour le chiffrement, AWS Secrets Manager pour le jeton Telegram, et Amazon CloudWatch pour les journaux et les métriques. Pour supprimer l’installation, le parcours de nettoyage prévu par AWS comprend la suppression du magasin de mémoire et de ses espaces de noms.
