Reactiv, разработчик нативных мобильных приложений для Shopify-мерчантов, собрала AI Scheduler: мультиагентную систему, которая сама обновляет приложение по расписанию. Мерчант формулирует задачу словами, например «Refresh my homepage with best sellers every Monday at 9 AM», а дальше система всё делает сама. Разбор кейса опубликован в блоге AWS (How Reactiv automates mobile commerce 80% faster with Amazon Bedrock AgentCore).
Ядро решения - три агента на Strands Agents SDK: Supervisor, Analytics и Builder. Они работают в управляемом рантайме Amazon Bedrock AgentCore, который даёт общую память между сессиями, нативное подключение к MCP-серверам и изоляцию данных мерчантов. По внутренним замерам Reactiv, время настройки сократилось на 80%, а выход в продакшен ускорился на 33%.
Экономика здесь простая. Reactiv делает мобильные приложения, где покупатели конвертируются в 2-4 раза чаще, чем посетители веб-сайта. Если витрина в приложении отстаёт от наличия и спроса, преимущество в конверсии частично теряется. Обновление главной страницы бестселлерами каждую неделю работает как инструмент продаж, а не как косметическая правка оформления.
Что такое AI Scheduler от Reactiv и какую задачу он решает
AI Scheduler - слой автоматизации поверх мобильного приложения Shopify. Мерчант описывает желаемое изменение на естественном языке: «обновляй главную страницу бестселлерами каждый понедельник в 9 утра». Система разбирает запрос, собирает данные магазина, формирует конфигурацию и применяет её в назначенное время. Ни правок кода, ни ручной настройки планировщика.
До Scheduler у Reactiv уже работал разговорный AI-билдер. Мерчанты писали ассистенту в дашборде Reactiv и меняли приложение в реальном времени. Разовые задачи это решало, регулярные нет: ассортимент и распродажи меняются по календарю, а ассистент ждал нового сообщения. Scheduler закрыл разрыв между «поменять сейчас» и «чтобы менялось само».
В продакшен систему вывели за несколько недель. Команда выбрала готовый управляемый рантайм вместо самостоятельной сборки инфраструктуры для агентов, и это заметно сократило путь до релиза.
Архитектура мультиагентной системы: Supervisor, Analytics и Builder
Запланированная задача плохо ложится на одного агента. Ему пришлось бы одновременно понимать, чего хочет мерчант, ходить за данными в разные системы и генерировать итоговую конфигурацию. Reactiv разделила эти роли между тремя агентами, у каждого свой набор инструментов и своя зона ответственности.
Роль Supervisor: классификация намерения
Supervisor принимает запрос на естественном языке и определяет, что именно требуется: обновление контента, изменение расписания или запрос данных. Это этап маршрутизации в графе агентов, и от его точности зависит, в какую ветку уйдёт задача. Ошибка классификации на этом шаге уводит всю цепочку не туда, поэтому роль вынесена в отдельного агента.
Роль Analytics: доступ к данным мерчанта
Analytics-агент запрашивает данные магазина: что продаётся, какие товары попадают в бестселлеры, как выглядит текущая конфигурация. Данные приходят через MCP-серверы и внутренние API Reactiv. Без этого шага Builder работал бы вслепую и подставлял в витрину случайные позиции.
Роль Builder: генерация конфигураций
Builder получает намерение от Supervisor и данные от Analytics, после чего формирует конфигурацию обновления: меняет состав блока на главной, задаёт порядок товаров, прописывает расписание. Результат - та самая конфигурация, которую применяет приложение.
Пример сквозного потока: запрос «обновляй главную страницу бестселлерами каждый понедельник в 9 утра» → Supervisor помечает его как запланированное обновление → Analytics достаёт список бестселлеров и параметры магазина → Builder собирает конфигурацию → система сохраняет задачу и применяет её по расписанию. Каждый агент отвечает за свой участок, и сбой на одном шаге не ломает остальные.
Интерактивные и запланированные агенты Reactiv объединила в единый стек. Общая память работает на оба режима: то, что система узнала в чате с мерчантом, доступно и при плановом запуске. Похожие схемы с несколькими ролевыми агентами и MCP-инструментами разбираются в кейсе AvioBook на AgentCore (аналитика наземного обслуживания авиарейсов).
Почему Reactiv выбрала Amazon Bedrock AgentCore
Требования к платформе сложились из четырёх пунктов: хостинг мультиагентных графов, память между сессиями, нативное подключение к MCP-серверам и автоматическая изоляция данных каждого мерчанта. По описанию команды, именно поиск управляемого рантайма под ориентированные графы специализированных агентов привёл её к Amazon Bedrock AgentCore.
Управляемый рантайм для мультиагентных графов
AgentCore берёт на себя запуск агентов и их жизненный цикл, поэтому команде не пришлось строить собственный оркестратор и дежурную инфраструктуру вокруг него. Для Reactiv это означало более короткий путь от прототипа до продакшена. Как менялась платформа в августе 2026, какие лимиты добавились и на что смотреть перед переездом, разобрано в обзоре обновлений Amazon Bedrock и AgentCore (обновления августа 2026).
Постоянная память между сессиями
До перехода на AgentCore каждая сессия начиналась с нуля. Агент не помнил, какие варианты мерчант одобрял раньше, какие блоки предпочитает и что уже отклонял. Контекст приходилось повторять при каждом запуске. Память, которая сохраняется между сессиями, убирает эту рутину и позволяет опираться на прошлые решения мерчанта.
Нативная поддержка MCP и изоляция данных
AgentCore подключается к MCP-серверам штатно, без ручных прослоек между агентом и инструментом. Изоляция данных каждого мерчанта работает автоматически, поэтому агенты одного магазина не видят данные другого. Для платформы, которая обслуживает множество независимых магазинов, это обязательное условие.
Прежний стек выглядел тяжелее. Сервер конфигурационной схемы Config MCP работал на Amazon ECS с самодельным слоем аутентификации на Amazon Cognito и ручными JSON-RPC-рукопожатиями при каждом вызове. Каждый инструмент требовал OpenAPI-спецификации, обвязки на AWS Lambda и маппинга action-group. Около 100 файлов спецификаций поддерживались в двух местах, и любую правку приходилось синхронизировать вручную. AgentCore снял значительную часть этих накладных расходов (исходный кейс AWS).
Как работает автоматизация: от запроса мерчанта до обновления приложения
Разберём полный цикл на одном примере. Мерчант вводит в дашборде: «обновляй главную страницу бестселлерами каждый понедельник в 9 утра».
- Supervisor получает текст и классифицирует намерение как запланированное обновление контента.
- Analytics запрашивает через MCP данные магазина: список бестселлеров, текущую структуру главной страницы, настройки темы.
- Builder собирает конфигурацию: какой блок менять, какие товары ставить, на какое время назначить запуск.
- Система сохраняет задачу вместе с контекстом мерчанта в общей памяти.
- В следующий понедельник в 9:00 обновление применяется автоматически, без участия человека.
Дальше вмешательство нужно только при изменении условий. Мерчант может сказать «перенеси на вторник в 8 утра» или «добавь блок с новинками», и правка пройдёт тот же маршрут. Память агента сохранит предыдущие настройки, поэтому не придётся заново описывать весь магазин. Отменить расписание тоже можно словами: задача снимается так же, как ставилась.
Результаты внедрения: цифры и бизнес-эффект
Reactiv приводит две метрики. Время настройки мерчанта сократилось на 80%, выход в продакшен ускорился на 33%. Система из трёх агентов заработала в продакшене за несколько недель. Обе цифры взяты из внутренних замеров компании, независимой проверки в открытом доступе нет (кейс Reactiv на AWS).
Читать эти цифры стоит в контексте платформы. Мобильные приложения Shopify, которые делает Reactiv, конвертируют в 2-4 раза лучше веб-сайта. Каждая неделя с устаревшей витриной означает потерю части этой конверсии. Экономия времени на настройке важна ещё и потому, что платформа обслуживает множество магазинов: то, что для одного мерчанта выглядит как один запрос, для команды означает поток однотипных задач.
Для сравнения показателей на той же платформе стоит посмотреть кейс Mobileye: там ИИ-агент на Amazon Bedrock AgentCore сократил время ответа на тикеты на 90%, а точность обработки достигла 98% (разбор кейса Mobileye). Цифры другой задачи и другой компании, но подход с управляемым рантаймом и MCP повторяется.
Ограничения и чему учит кейс Reactiv
Кейс полезен, но переносить его один в один в свой проект стоит с оговорками.
- Привязка к AWS. Стек строится на Amazon Bedrock AgentCore и Strands Agents SDK. Если продукт живёт на другой платформе, часть преимуществ (управляемый рантайм, нативная работа с MCP, изоляция данных) придётся собирать самостоятельно.
- Сложность оркестрации. Три агента означают три набора инструкций и инструментов, общую память и правила маршрутизации. Для одной задачи по расписанию такая схема избыточна.
- Метрики без внешней проверки. Цифры 80% и 33% дала сама Reactiv. Независимого аудита, который бы их подтвердил, в открытом доступе нет.
- Память требует правил. Хранение предпочтений между сессиями помогает, но добавляет вопросы: что запоминать, когда забывать, как чистить данные при отключении магазина.
Что переносится на любой проект: разделение ролей между агентами, общая память и вынос доступа к внешним данным в MCP-инструменты. Как этот сдвиг меняет архитектуру контентных систем, разбирали в материале про агентные CMS (от генерации к управляемым конвейерам). Если строите агентов с расписанием и доступом к данным магазина, начинайте с одного сценария и одного набора инструментов, а роли дробите только когда появляется реальная нагрузка на классификацию.
Планы Reactiv: расширение кастомизации через новые MCP-серверы
Reactiv планирует расширять кастомизацию через новые MCP-серверы. Смысл направления понятен: чем больше источников данных и инструментов подключается штатно, тем меньше ручной настройки нужно мерчанту и тем гибче Scheduler под конкретный магазин. Точные сроки, список серверов и набор функций в опубликованном кейсе не раскрыты, поэтому конкретику стоит ждать в анонсах компании.
Если вы строите похожую систему, стартовый каркас выглядит так: агент-классификатор намерения, отдельные агенты для данных и генерации конфигураций, общая память между сессиями и доступ к внешним системам только через MCP. Такой скелет переносится на планировщики контента, регулярную отчётность и любые задачи, где решение принимается по данным магазина, а не по заранее прописанному сценарию.