Shopify-застосунки оновлюються самі через AI-агентів
Reactiv будує мобільні застосунки для Shopify-продавців (конверсія там у 2-4 рази вища, ніж на вебі). Компанія створила AI Scheduler — тримагентну систему на Amazon Bedrock AgentCore. Продавець пише «онови головну бестселерами щопонеділка о 9:00»: один агент аналізує дані через Redshift, другий генерує конфігурацію (50+ інструментів), а Config MCP перевіряє кожну зміну — без схвалення нічого не публікується.
Раніше кожен інструмент вимагав окремого OpenAPI-опису й Lambda-обгортки — близько 100 файлів. AgentCore зняла це вбудованою памʼяттю на продавця. Час налаштування впав на 80%, вихід у продакшн прискорився на 33%.
Як запит перетворюється на публікацію: п'ять кроків
Продавець ставить завдання не одним реченням у чат, а двома способами: через чат-бот у панелі Reactiv або через форму, де вибирає готовий сценарій, частоту й час запуску. Обидва варіанти створюють запис розкладу, привʼязаний до cron-правила в Amazon EventBridge.
Коли розклад спрацьовує, запит проходить п'ять етапів:
- EventBridge запускає Job Executor (AWS Lambda) — він перевіряє акаунт продавця, ставить блокування на паралельний запуск і дістає поточну конфігурацію застосунку з бази.
- Lambda передає в AgentCore весь контекст: запит продавця, поточну конфігурацію, метадані сесії.
- Supervisor Agent визначає намір і скеровує запит: лише аналітика, лише генерація конфігурації, або аналітика з подальшою генерацією.
- Analytics Agent перетворює запит на SQL-запит до Amazon Redshift і дістає тренди, топові товари, інсайти.
- Builder Agent на основі цих інсайтів формує нову конфігурацію, викликаючи понад 50 інструментів: зміни через Config MCP, запити даних через Lambda, пошук товарів через Shopify Storefront SDK, генерацію зображень.
Готова конфігурація потрапляє в Amazon DynamoDB на розгляд продавця — жодна зміна не публікується без явного підтвердження людини.
Друга ситуація: коли розклад і чат-бот почали ділитися памʼяттю
До AI Scheduler у Reactiv вже існував окремий інтерактивний AI-асистент у панелі керування — продавець міг у реальному часі попросити його змінити застосунок через чат. Але ці дві системи не мали спільної памʼяті, інструментів чи інфраструктури: те, що асистент дізнавався про смаки продавця в чаті, розклад не бачив, і навпаки.
Reactiv перевела інтерактивного агента на протокол AG-UI на тому ж AgentCore, і обидва агенти стали використовувати один фреймворк (Strands), одні MCP-сервери й один шар памʼяті. Результат — двостороннє навчання: уподобання, які продавець висловив у чаті, одразу враховує наступний запланований запуск, і навпаки, чим частіше продавець працює з чат-ботом, тим точніше стає автоматичний розклад.
Памʼять побудована на трьох механізмах: підсумовувач сесії стискає дії кожного завдання в контекст для майбутніх запусків, модуль навчання уподобань відстежує, які макети продавець схвалює чи відхиляє, а екстрактор фактів зберігає знання про магазин — категорії товарів, бестселери, брендові гайдлайни. Памʼять ізольована по кожному продавцю окремо.
Результати й вбудований запобіжник
Найпомітніший ефект — час: завдання з онбордингу, які раніше займали 17 годин ручної роботи, тепер завершуються за 3 години, а зміни після запуску — за хвилини замість днів. Виконання самого запланованого завдання прискорилось удвічі: з понад 10 хвилин до приблизно 5, бо чотириступеневий ланцюг опитувань замінили на один потоковий виклик у реальному часі.
Перехід на AgentCore також спростив розробку: замість близько 100 файлів OpenAPI-специфікацій команда використовує декоратор @tool у Strands SDK, а вбудована автентифікація AgentCore Identity зняла потребу в кастомному шарі авторизації та ручних JSON-RPC-рукостисканнях. Це заощадило Reactiv близько $6000 на рік на обчисленнях, а команда з трьох людей випустила трьохагентну систему за 10 тижнів замість 15.
При цьому система не публікує нічого автоматично: Config MCP перевіряє кожну мутацію конфігурації на відповідність схемі застосунку до того, як вона взагалі потрапляє на розгляд, а сама публікація завжди чекає підтвердження продавця. Це і є перевірка, яку варто шукати в будь-якій подібній системі: чи є проміжний крок людського схвалення між генерацією та публікацією.
Куди рухається продукт далі
Reactiv планує винести дизайн-систему (кольори, типографіку, відступи, варіанти компонентів) в окремий MCP-сервер за тим самим принципом, що й Config MCP. Тоді продавець зможе сказати «зроби застосунок у стилі мого бренду», і агент застосовуватиме зміни в межах заданого дизайн-словника, а не генеруватиме довільний результат.
Ця ж дизайн-система має лягти в основу нового онбордингу: за назвою бренду й сайтом агент аналізуватиме наявну веб-присутність продавця і одразу пропонуватиме стартовий варіант мобільного застосунку. У перспективі Reactiv хоче дозволити продавцям запитувати повністю нові розділи макета природною мовою — агент генеруватиме перевірену JSON-структуру, яку застосунок відображає на льоту, залишаючись у межах брендових гайдлайнів.