«Ничего не уходит в продакшн без одобрения мерчанта»: Reactiv собрала планировщик на Amazon Bedrock AgentCore

Задача: приложение, которое не обновляет себя само

Reactiv выпускает продукт для мобильной коммерции, с которым Shopify-мерчанты запускают и ведут нативные мобильные приложения. По данным компании, покупатели в таких приложениях конвертируются в два-четыре раза лучше, чем посетители веб-сайта, — поэтому устаревшая главная страница или пропущенное окно промоакции оборачиваются реальными деньгами.

Цена свежести высока, а поддерживать её приходится вручную: выбрать, какие товары выносить в витрину, переставить блоки, сгенерировать новые ассеты, опубликовать обновление вовремя. Делать это каждую неделю у большинства мерчантов просто нет ресурса.

Reactiv автоматизировала цикл с помощью Amazon Bedrock AgentCore. Результат, который компания приводит по внутренним замерам: время настройки со стороны мерчанта сократилось на 80 процентов, а выход в продакшн оказался на 33 процента быстрее.

Как описан планировщик

Ядро решения — AI Scheduler, который обновляет приложения мерчантов автономно по расписанию. Мерчант формулирует задачу на естественном языке, например «обновляй главную страницу бестселлерами каждый понедельник в 9 утра», а дальше система работает сама.

Система построена как три агента на Amazon Bedrock AgentCore с использованием Strands Agents SDK и была введена в продакшн в течение нескольких недель. Затем Reactiv свела интерактивных и «расписанных» агентов в один стек с общей памятью для обоих режимов работы.

До планировщика у Reactiv уже был разговорный ИИ-сборщик: мерчант общался с ассистентом в дашборде и менял приложение в реальном времени. Именно эта интерактивная часть и оказалась отправной точкой — мерчанты попросили автономные обновления по расписанию, без ручного участия.

Четыре требования, которые не закрывала прежняя архитектура

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

Второе — постоянная память: каждая сессия начиналась с нуля, и агент не помнил, что предпочитает мерчант, и не учился на прошлых одобрениях. Третье — нативная поддержка Model Context Protocol: сервер схемы конфигурации (Config MCP) работал на Amazon Elastic Container Service с собственной аутентификацией через Amazon Cognito и ручными JSON-RPC-хендшейками при каждом вызове. Четвёртое — накладные расходы на описание инструментов: для каждого инструмента требовались спецификация OpenAPI, обвязка в AWS Lambda и маппинг action group, а поддерживать приходилось около 100 файлов спецификаций в двух местах.

Reactiv требовалось решение, которое разместит графы агентов, будет хранить память между сессиями, нативно подключается к MCP-серверам и автоматически изолирует данные каждого мерчанта. Из возможностей AgentCore компания использовала три: AgentCore runtime для управляемого исполнения агентов, AgentCore memory для постоянного контекста между сессиями и AgentCore Identity для аутентификации между сервисами.

Рантайм запускает агентов в микроVM на Firecracker — той же технологии изоляции, что лежит в основе AWS Lambda. Reactiv упаковывает граф агентов на Strands в Docker-образ, отправляет его в Amazon Elastic Container Registry и разворачивает в AgentCore: агенты поднимаются по триггеру расписания и выключаются по завершении, без кластеров Amazon ECS, политик масштабирования и простаивающих мощностей.

Память: три стратегии вместо векторной базы

AgentCore предоставляет долговременную память, которая сохраняется между сессиями агента. Reactiv применяет три стратегии. Суммаризатор сессии сжимает действия каждой задачи в контекст для будущих запусков. Модуль изучения предпочтений отслеживает, какие макеты мерчант одобряет, а какие отклоняет. Семантический экстрактор фактов хранит знание о магазине — категории товаров, бестселлеры, правила бренда.

Память ограничена рамками одного мерчанта и остаётся приватной, собственной векторной базы и конвейера поиска строить не требуется. На уровне инфраструктуры изоляция идёт дальше: контекст исполнения, память и состояние агента каждого мерчанта живут в отдельной микроVM, и предпочтения одного магазина не смешиваются с сессиями другого — маршрутизацию и изоляцию арендаторов берёт на себя платформа.

Как проходит одно задание

Мерчант создаёт задачу в дашборде Reactiv — через чат-интерфейс или форму, где выбирает промпт, периодичность и время. Оба пути создают запись расписания на основе cron-правила Amazon EventBridge.

Когда расписание срабатывает, Amazon EventBridge вызывает Job Executor на AWS Lambda: тот проверяет аккаунт мерчанта, берёт блокировку на параллельный запуск и вытаскивает текущую конфигурацию приложения из базы. Затем Lambda вызывает рантайм AgentCore, передавая промпт мерчанта, текущую конфигурацию и метаданные сессии.

Внутри рантайма выполняется мультиагентный граф на Strands. Supervisor Agent классифицирует намерение и направляет работу в нужный конвейер: только аналитика, только сборка или аналитика, а затем сборка. Analytics Agent запрашивает данные о производительности через text-to-SQL к Amazon Redshift, показывая тренды, топовые товары и выводы, на которые можно опереться. Builder Agent превращает эти выводы в обновлённые конфигурации приложения и для этого вызывает более 50 инструментов: мутации конфигурации через Config MCP, запросы к данным через функции Lambda, поиск товаров через Shopify Storefront SDK и создание ассетов через SDK генерации изображений.

Config MCP, размещённый на AgentCore, проверяет каждую мутацию Builder Agent по схеме приложения. Сборщик физически не может выдать невалидную конфигурацию, потому что MCP служит одновременно справочником и предохранителем. Готовая конфигурация сохраняется в Amazon DynamoDB и ждёт проверки: ничего не публикуется без явного одобрения мерчанта.

Фундаментальные модели агенты получают через Amazon Bedrock — это серверный инференс со встроенными guardrails без управления хостингом моделей и GPU-инфраструктурой.

Один стек вместо двух систем

После запуска планировщика у Reactiv оказалось два независимых агентных контура: интерактивный агент в дашборде, построенный на собственном UI-адаптере для Amazon Bedrock, и агент по расписанию на Strands с AgentCore. Они не делили ни память, ни инструменты, ни инфраструктуру.

Компания свела их, перенеся интерактивного агента на протокол AG-UI в Amazon Bedrock AgentCore. Теперь агент дашборда использует тот же фреймворк Strands, те же MCP-серверы на AgentCore и тот же экземпляр памяти, что и планировщик. Практический эффект — двусторонний обмен памятью: предпочтения и факты, выясненные в интерактивной сессии, попадают в следующий запуск по расписанию, и наоборот. Запланированные задачи становятся точнее по мере того, как мерчант пользуется агентом в интерфейсе.

Цифры, которые приводит Reactiv

Сокращение времени настройки на 80 процентов расшифровывается конкретнее: задачи онбординга, требовавшие 17 часов ручной работы, теперь закрываются за три часа, а изменения после запуска занимают минуты вместо дней.

Ускорение выхода в продакшн на 33 процента — это 10 недель против 15 на прежнюю сборку с одним агентом; систему из трёх агентов собрала команда из трёх человек. Упрощение инструментария дало ещё один эффект: декоратор @tool из Strands SDK заменил примерно 100 файлов спецификаций OpenAPI, а рантайм и идентичность AgentCore убрали собственную инфраструктуру — миграция экономит почти 6 000 долларов в год, и это только расходы на вычисления.

Отдельный замер касается скорости работы: запланированные задания сократились с более чем 10 минут примерно до 5, потому что нативный стриминг в рантайме AgentCore заменил четырёхшаговую цепочку опроса одним вызовом в реальном времени.

Что дальше

Следующий шаг — вывести дизайн-свойства Reactiv (цвета, типографику, отступы, варианты компонентов) в отдельный MCP-сервер на Amazon Bedrock AgentCore по образцу Config MCP: общая поверхность инструментов, которую смогут использовать и планировщик, и интерактивный сборщик, а со временем и внешние интеграции. Мерчант сможет сказать «сделай приложение под мой бренд», а агент применит изменения в рамках заданного словаря дизайна, а не сгенерирует произвольную вёрстку.

Тот же дизайн-словарь открывает переработанный онбординг: получив название бренда и адрес сайта, агент анализирует существующее веб-присутствие и собирает стартовую версию мобильного приложения, оперируя реальными свойствами и компонентами, а не придумывая макет с нуля.

Дальше по плану — заявки на полностью новые секции макета на естественном языке: агент сгенерирует провалидированное JSON-представление запрошенной секции, а мобильное приложение отрисует его на лету компонентами дизайн-системы. Это расширяет авторские возможности агента за пределы готовых типов блоков — но по-прежнему внутри правил бренда.

Кто описал архитектуру

Разбор опубликован в блоге AWS Machine Learning. Adam Gibicar — старший ИИ-разработчик Reactiv, специализируется на архитектуре инфраструктуры мобильной коммерции и мультиагентных системах; его текущая работа связана с MCP-серверами и агентными процессами на AgentCore. Ryan Masciovecchio — Solutions Architect в AWS, работает с стартапами над ИИ- и ML-нагрузками и помогает строить продакшн-системы агентного ИИ на AWS.