عرضت AWS كيفية ربط Amazon Bedrock AgentCore بـ Slack عبر CDK وLambda

AWS показала, как встроить Amazon Bedrock AgentCore прямо в Slack и не писать интеграцию с нуля вокруг каждого нового агента. В статье компания разбирает готовый шаблон на AWS CDK, который закрывает проверку вебхуков, асинхронную обработку сообщений и сохранение контекста диалога.

Как устроена схема Решение делится на две части.

Первая — инфраструктурный слой между Slack и агентом: API Gateway принимает вебхуки, AWS Lambda обрабатывает события, Secrets Manager хранит токены, а Amazon SQS помогает разнести приём запроса и фактическую обработку. Вторая — сам агент в Amazon Bedrock AgentCore Runtime. В демонстрации это погодный бот, собранный на Strands Agents SDK, но AWS подчёркивает, что этот слой можно заменить на любую бизнес-логику без переделки интеграции со Slack.

Разворачивание идёт через три CDK-стека. Один собирает и публикует контейнерный образ агента, второй поднимает Runtime, Gateway и Memory, третий создаёт Slack-инфраструктуру с API Gateway и Lambda-функциями. По данным AWS, полный деплой занимает примерно 10–15 минут.

После этого остаётся подставить webhook URL в настройки Slack-приложения, включить подписки на события и переустановить приложение в рабочем пространстве. То есть речь не о концепте на уровне диаграммы, а о рабочем шаблоне, который можно повторить почти пошагово.

Почему три Lambda Ключевая проблема тут не модель, а ограничения Slack.

Платформа ждёт быстрый ответ на входящий webhook и даёт на это около трёх секунд. Если агенту нужно поднять историю диалога, вызвать инструменты и дождаться ответа модели, этого окна часто не хватает. Поэтому AWS выносит обработку в асинхронную схему через очередь и делит обязанности между тремя отдельными функциями.

Такой подход снижает риск таймаутов и делает поведение интеграции более предсказуемым при росте нагрузки. Verification Lambda проверяет подпись Slack, достаёт секреты из Secrets Manager и сразу возвращает 200 OK. SQS Integration Lambda фильтрует события, игнорирует сообщения бота, отправляет пользователю промежуточный ответ и кладёт задачу в FIFO-очередь.

* Agent Integration Lambda получает сообщение из очереди, вызывает AgentCore Runtime и обновляет тред итоговым ответом. В результате пользователь сначала видит короткое служебное сообщение вроде «Processing your request…», а затем оно заменяется финальным ответом агента.

Это важная мелочь: UX остаётся быстрым, хотя основная работа идёт в фоне. Одновременно такой паттерн защищает систему от циклов, потому что промежуточный слой может отбрасывать сообщения самого бота. Для корпоративных чатов это особенно полезно: интеграция не превращается в хрупкий webhook-скрипт, который ломается при первом же более сложном сценарии.

Память и сессии Отдельно AWS показывает аккуратный способ хранить контекст разговора.

Вместо внешнего state store с собственными ключами сессия строится прямо из структуры Slack: идентификатором становится timestamp треда, а actor_id — ID пользователя. Все ответы внутри одной ветки автоматически попадают в одну memory session, а соседние треды остаются изолированными. Это упрощает архитектуру и убирает лишний слой синхронизации, который обычно приходится писать при интеграции агентов в мессенджеры и helpdesk-интерфейсы.

Внутри Runtime за память отвечает AgentCore Memory, доступ к инструментам идёт через AgentCore Gateway, а вызовы инструментов выполняются по MCP. В примере модель Amazon Nova Pro решает, когда нужен дополнительный вызов инструмента, и продолжает ответ уже с его результатом. AWS отдельно отмечает, что интеграционный слой можно переиспользовать без изменений: достаточно заменить погодные инструменты на свои — поиск по базе знаний, внутренние регламенты, CRM-действия или сервисные операции.

Если нужен доступ от имени конкретного сотрудника, AgentCore поддерживает и пользовательские сценарии авторизации через корпоративный IdP.

Что это значит

Для команд, которые хотят посадить AI-агента в Slack, AWS фактически даёт референсную архитектуру вместо набора разрозненных советов. Главное в ней не только Bedrock, а повторно используемый каркас: безопасная проверка событий, обход таймаута Slack и нормальная память диалога. Это снижает время на запуск новых агентов и убирает часть рутинной инфраструктурной работы.