AWS a montré comment connecter Amazon Bedrock AgentCore à Slack via CDK et Lambda

AWS a montré comment intégrer Amazon Bedrock AgentCore directement dans Slack sans écrire l'intégration de zéro pour chaque nouvel agent. L'entreprise détaille un modèle AWS CDK prêt à l'emploi qui couvre la vérification des webhooks, le traitement asynchrone des messages et la préservation du contexte de conversation.

Comment fonctionne le schéma

La solution est divisée en deux parties. La première est la couche d'infrastructure entre Slack et l'agent : API Gateway reçoit les webhooks, AWS Lambda traite les événements, Secrets Manager stocke les jetons et Amazon SQS aide à séparer la réception de la demande du traitement réel. La seconde est l'agent lui-même dans Amazon Bedrock AgentCore Runtime. Dans la démonstration, il s'agit d'un bot météorologique construit sur Strands Agents SDK, mais AWS souligne que cette couche peut être remplacée par n'importe quelle logique métier sans refaire l'intégration avec Slack.

Le déploiement se fait via trois stacks CDK. Un construit et publie l'image du conteneur de l'agent, le deuxième active Runtime, Gateway et Memory, le troisième crée l'infrastructure Slack avec API Gateway et des fonctions Lambda. Selon AWS, un déploiement complet prend environ 10–15 minutes. Après cela, il suffit de brancher l'URL du webhook dans les paramètres de l'application Slack, d'activer les abonnements aux événements et de réinstaller l'application dans votre espace de travail. Il ne s'agit pas d'un concept au niveau du diagramme, mais d'un modèle fonctionnel qui peut être reproduit presque étape par étape.

Pourquoi trois Lambdas

Le problème clé ici n'est pas le modèle, mais les limitations de Slack. La plateforme s'attend à une réponse rapide à un webhook entrant et accorde environ trois secondes pour cela. Si l'agent doit récupérer l'historique de la conversation, appeler des outils et attendre la réponse du modèle, cette fenêtre est souvent insuffisante. C'est pourquoi AWS transfère le traitement vers un schéma asynchrone via une file d'attente et divise les responsabilités entre trois fonctions séparées. Cette approche réduit le risque de délais d'expiration et rend le comportement de l'intégration plus prévisible à mesure que la charge augmente.

• Verification Lambda vérifie la signature de Slack, récupère les secrets de Secrets Manager et renvoie immédiatement 200 OK.
• SQS Integration Lambda filtre les événements, ignore les messages du bot, envoie une réponse intermédiaire à l'utilisateur et met la tâche dans une file d'attente FIFO.
• Agent Integration Lambda reçoit le message de la file d'attente, appelle AgentCore Runtime et met à jour le fil de discussion avec la réponse finale.

En conséquence, l'utilisateur voit d'abord un message de service court comme « Traitement de votre demande… », puis il est remplacé par la réponse finale de l'agent. C'est un détail important : l'UX reste rapide, bien que le travail principal se déroule en arrière-plan. En même temps, ce modèle protège le système contre les boucles, car la couche intermédiaire peut supprimer les messages du bot lui-même. Pour les chats d'entreprise, c'est particulièrement utile : l'intégration ne devient pas un script webhook fragile qui se casse au premier scénario plus complexe.

Mémoire et sessions

AWS montre séparément un moyen élégant de stocker le contexte de la conversation. Au lieu d'un state store externe avec ses propres clés, la session est construite directement à partir de la structure de Slack : l'horodatage du fil de discussion devient l'identifiant et actor_id est l'ID de l'utilisateur. Toutes les réponses dans une branche tombent automatiquement dans une seule memory session, et les fils de discussion adjacents restent isolés. Cela simplifie l'architecture et supprime une couche supplémentaire de synchronisation qui doit généralement être écrite lors de l'intégration d'agents dans des messagers et des interfaces d'assistance.

À l'intérieur de Runtime, AgentCore Memory est responsable de la mémoire, l'accès aux outils passe par AgentCore Gateway et les appels d'outils sont exécutés via MCP. Dans l'exemple, le modèle Amazon Nova Pro décide quand un appel d'outil supplémentaire est nécessaire et continue la réponse avec son résultat. AWS note séparément que la couche d'intégration peut être réutilisée sans modifications : il suffit de remplacer les outils météorologiques par les vôtres — recherche de base de connaissances, réglementations internes, actions CRM ou opérations de service. Si vous avez besoin d'un accès au nom d'un employé spécifique, AgentCore prend également en charge des scénarios d'autorisation personnalisés via un IdP d'entreprise.

Ce que cela signifie

Pour les équipes qui cherchent à mettre un agent IA dans Slack, AWS fournit essentiellement une architecture de référence plutôt qu'un ensemble de conseils disparates. L'élément clé n'est pas seulement Bedrock, mais un cadre réutilisable : vérification sécurisée des événements, contournement du délai d'expiration de Slack et mémoire de conversation appropriée. Cela réduit le temps de lancement de nouveaux agents et supprime une partie du travail d'infrastructure de routine.