Reactiv 借助 Amazon Bedrock AgentCore 将移动电商运营自动化提速 80%

Reactiv 提供移动电商产品，帮助 Shopify 商家发布和管理原生移动应用；在这些应用中，消费者的转化率是网页访客的 2–4 倍。对于这些商家而言，过时的首页或错过促销窗口会直接造成营收损失。但要保持应用内容新鲜，需要持续进行大量人工工作：挑选主推商品、重新排列页面区块、生成新素材，以及按时发布更新。大多数商家没有能力每周完成这些工作。Reactiv 使用 Amazon Bedrock AgentCore 将这些更新自动化，将商家配置时间缩短了 80%，并将产品上线速度提升了 33%。

Reactiv 希望通过 AI Scheduler 解决这一问题：该系统可按计划自主更新商家的应用。商家只需使用自然语言描述需求，例如“每周一上午 9 点用畅销品刷新我的首页”，其余工作均由系统处理。他们基于 Amazon Bedrock AgentCore 和 Strands Agents SDK 构建了一个三 Agent 系统，并在数周内投入生产。随后，他们将交互式 Agent 和定时 Agent 统一到同一技术栈上，实现两种模式之间的共享记忆。

本文将介绍实现这些成果的架构、Reactiv 选择 Amazon Bedrock AgentCore 的原因，以及该产品自发布以来的演进。

挑战：不会自行更新的内容

Reactiv 为 Shopify 商家构建原生 iOS 和 Android 应用。其工具包括低代码应用构建器、分析仪表板和 AI 驱动功能。在推出 AI Scheduler 之前，Reactiv 已经构建了一个对话式 AI 构建器。商家可以在 Reactiv 仪表板中与 AI 助手聊天，实时修改其应用。

该系统适用于交互式使用场景，但 Reactiv 的商家提出了不同需求：无需任何人工干预、按计划自主完成的更新。构建这项能力需要现有架构不具备的能力：

• 多 Agent 编排。定时任务需要一个主管 Agent 来分类意图、一个分析 Agent 来查询商家数据，以及一个构建 Agent 来生成配置。Reactiv 需要一个专为专业化 Agent 有向图设计的托管运行时，因此选择了 Amazon Bedrock AgentCore。
• 持久化记忆。每次会话都从零开始，Agent 无法记住商家在不同运行之间的偏好，也无法从过去的审批中学习。
• 原生 Model Context Protocol（MCP）支持。Reactiv 的配置模式服务器（Config MCP）运行在 Amazon Elastic Container Service（Amazon ECS）上，采用自定义 Amazon Cognito 身份验证层，并且每次调用都需要手动进行 JSON-RPC 握手。
• 工具定义开销。每个工具都需要 OpenAPI 规范、AWS Lambda 连接配置和操作组映射。他们在两个位置维护了约 100 个规范文件。

Reactiv 需要一个解决方案，能够托管多 Agent 图、跨会话持久化记忆、原生连接 MCP 服务器，并自动隔离每个商家的数据。

为什么选择 Amazon Bedrock AgentCore

Amazon Bedrock AgentCore 是一个可使用任意框架或模型大规模构建、连接和优化 Agent 的平台。Reactiv 使用其中三项能力解决了上述四项需求。作为 Amazon Bedrock AgentCore 功能的 AgentCore Runtime 负责托管 Agent 执行；作为 Amazon Bedrock AgentCore 功能的 AgentCore Memory 提供跨会话持久化上下文；作为 Amazon Bedrock AgentCore 功能的 AgentCore Identity 处理服务间身份验证。

托管 Agent 运行时。AgentCore 在 Firecracker microVM 中运行 Agent，这也是 AWS Lambda 背后采用的隔离技术。Reactiv 将其 Strands Agent 图打包为 Docker 镜像，推送至 Amazon Elastic Container Registry（Amazon ECR），然后部署到 AgentCore。当计划触发时，Agent 会启动；任务完成后则关闭。无需管理 Amazon ECS 集群、扩缩容策略或闲置计算资源。

“我们不管理容器、编排器或扩缩容策略。我们将 Agent 代码打包成 Docker 镜像，部署到 AgentCore，剩下的工作由它完成。”——Reactiv 高级 AI 开发者 Adam Gibicar

内置记忆。AgentCore 提供可跨 Agent 会话持久化的长期记忆。Reactiv 使用三种策略：会话摘要器会将每项任务的操作压缩为供未来运行使用的上下文；偏好学习器会跟踪商家长期以来批准或拒绝的布局；语义事实提取器则存储有关商家店铺的知识，例如商品类别、畅销商品和品牌指南。记忆按商家划分作用域，确保每个商家的数据保持私密。无需自定义向量数据库或检索管道。

原生 MCP 托管。Reactiv 将其 Config MCP 托管在 Amazon Bedrock AgentCore Runtime 上。MCP 作为有状态服务器运行，在会话开始时初始化商家当前的应用配置。Builder Agent 会针对这一实时状态执行变更，并在每次调用时根据模式进行验证。借助 AgentCore Identity，Reactiv 可原生处理服务间身份验证，移除了此前自行构建和维护的自定义身份验证层及 JSON-RPC 握手代码。

多租户隔离。每个商家的执行上下文、记忆和 Agent 状态均在各自的 Firecracker microVM 中运行。商家 A 的偏好会与商家 B 的会话保持隔离。AgentCore 在基础设施层面处理租户路由和隔离。

架构概览

下图展示了 AI Scheduler 的端到端流程。

图 1：Reactiv AI Scheduler 的端到端流程。Amazon EventBridge 触发 Lambda 执行器，由其调用 AgentCore Runtime；其中三个 Strands Agent 通过 MCP 工具、Lambda 函数、AgentCore Memory 和 Amazon Bedrock 协作，生成应用配置并存储在 Amazon DynamoDB 中，供商家审批。

下表总结了该解决方案中的服务：

服务	角色
Amazon Bedrock AgentCore	托管 Agent 运行时、持久化记忆、MCP 托管、AG-UI 支持、多租户隔离
Amazon Bedrock	基础模型访问、护栏
Amazon EventBridge	为商家定义的更新频率提供 Cron 调度
AWS Lambda	任务执行器，以及由 Agent 调用的 17 个工具函数
Amazon DynamoDB	存储结果，供商家审阅和批准
Amazon Redshift	为 Analytics Agent 的 text-to-SQL 查询提供支持的分析数据存储

系统从商家开始。在 Reactiv 仪表板中，商家可通过聊天机器人界面创建定时任务，例如“每周一上午 9 点用畅销品刷新我的首页”；也可以通过表单选择提示词、频率和时间。两种方式都会生成由 Amazon EventBridge Cron 规则支持的计划记录。

当计划触发后，流程会经过五个组件：

1. Amazon EventBridge 触发 Job Executor（AWS Lambda），后者验证商家账户、获取并发锁，并从数据库拉取商家当前的应用配置。
2. Lambda 函数使用 Agent 所需的完整上下文调用 AgentCore Runtime：商家的提示词、当前应用配置和会话元数据。
3. 在运行时内部，一个 Strands 多 Agent 图开始执行：
   • Supervisor Agent 对商家的意图进行分类，并路由到正确的处理管线（仅分析、仅构建，或先分析后构建）。
   • Analytics Agent 通过针对 Amazon Redshift 的 text-to-SQL 查询商家业绩数据，发现趋势、热门商品和可执行洞察。
   • Builder Agent 获取这些洞察并生成更新后的应用配置。为此，它会调用超过 50 个工具，包括通过 Config MCP 进行配置变更、通过 Lambda 函数查询数据、通过 Shopify Storefront SDK 查找商品，以及利用图像生成 SDK 创建素材。
4. Config MCP（托管在 AgentCore 上）会根据 Reactiv 的应用模式验证 Builder Agent 进行的每一次变更。由于 MCP 同时充当参考依据和护栏，Builder Agent 无法生成无效配置。
5. 生成的配置会存储在 Amazon DynamoDB 中供商家审阅。未经商家明确批准，任何内容都不会上线。

在整个执行过程中，AgentCore Memory 会在隔离命名空间中读取和写入商家的长期记忆。每项定时任务都会建立在 Agent 在此前针对该特定商家的会话中积累的偏好和事实之上。三个 Agent 通过 Amazon Bedrock 访问基础模型；该服务提供无服务器推理和内置护栏，无需 Reactiv 管理模型托管或 GPU 基础设施。

统一交互式 Agent 和定时 Agent

在发布 Scheduler 后，Reactiv 拥有两个独立的 Agent 系统：使用 Amazon Bedrock 自定义 UI 适配器构建的交互式仪表板 Agent，以及基于 Strands 和 AgentCore 构建的定时 Agent。二者不共享记忆、工具或基础设施。

Reactiv 通过将交互式 Agent 迁移至 Amazon Bedrock AgentCore 上的 AG-UI 协议，实现了二者统一。仪表板 Agent 现在与 Scheduler 共享相同的 Strands 框架、AgentCore 托管的 MCP 服务器和 AgentCore Memory 实例。结果是，两个 Agent 在框架、运行时、记忆层和 UI 协议上实现统一。其实际效果是双向记忆共享：在交互式仪表板会话中学习到的偏好和事实，会直接传递到下一次定时运行中，反之亦然。商家越多地使用前端 Agent，定时任务就会变得越智能。

成果

迁移至 Amazon Bedrock AgentCore 后，Reactiv 在开发速度、运行时性能和商家体验方面均获得提升。根据 Reactiv 的内部测量数据：

• 商家配置时间减少 80%。过去需要 17 小时人工完成的入驻任务现在可在 3 小时内完成；上线后的变更也从数天缩短至数分钟。
• 工具链简化且成本降低。Strands SDK @tool 装饰器替代了约 100 个 OpenAPI 规范文件；AgentCore Runtime 和 AgentCore Identity 移除了自定义基础设施；仅计算成本一项，该迁移每年便可节省近 6,000 美元。
• 无需自定义基础设施的持久化记忆。每个商家采用三种长期记忆策略，全部由 AgentCore Memory 托管，无需构建或维护向量数据库和检索管道。
• 投入生产速度提升 33%。三人团队在 10 周内交付了三 Agent 系统，而此前单 Agent 版本需要 15 周。借助 AgentCore 和 Strands，团队可以将工程时间集中于 Agent 逻辑，而不是基础设施连接工作。
• 任务执行速度提升 2 倍。通过使用 AgentCore Runtime 的原生流式处理，定时任务执行时间从超过 10 分钟降至约 5 分钟；该能力以一次实时调用替代了原先由四个步骤构成的轮询链。

下一步计划

随着交互式 Agent 和定时 Agent 已在单一技术栈上完成统一，Reactiv 正在扩展商家可用的创作界面。其核心方向是：让商家通过自然语言，以逐步深入的方式自定义移动应用。

第一步是将 Reactiv 现有的设计属性——颜色、字体排印、间距和组件变体——作为一个托管在 Amazon Bedrock AgentCore 上的新 MCP 服务器提供给 Agent。这沿用了 Config MCP 的方法：创建一个可共享的工具能力层，供 Scheduler、交互式构建器，以及未来的外部集成共同使用。商家可以说“让我的应用符合我的品牌风格”，Agent 将在受治理的设计词汇体系内应用变更，而不是生成不受约束的输出。

该设计系统还将支持重新构建的入驻体验。当新商家提供其品牌名称和网站时，Agent 会分析其现有的网络形象，并为移动应用生成一个高质量的起点。由于设计系统已经就位，Agent 可以面向实际的设计属性和组件进行操作，而不是从零生成布局。

更长远来看，Reactiv 计划允许商家通过自然语言请求全新的布局区块。Agent 将生成所请求布局的、经过验证的 JSON 表示形式，移动应用可利用 Reactiv 设计系统组件即时渲染该布局。这将把 Agent 的创作能力从预构建区块类型扩展到仍遵循品牌指南、由商家定义的布局。

结论

Reactiv 最初是在自主管理的基础设施上运行单一 Agent，随后发展为基于 Amazon Bedrock AgentCore 的统一多 Agent 系统。如今，其生产系统运行着三个专业化 Agent、超过 50 个工具，以及在交互式和自主模式间共享的持久化记忆。多个 MCP 服务器运行在同一个托管运行时上。他们以更快的速度、更少的基础设施代码实现了交付，同时获得了原本需要数月自定义工程才能实现的能力。

基于 MCP 的架构已被证明具有特别强的可复用性。Reactiv 的 Config MCP 模式现已扩展至设计系统 MCP，并最终将延伸到外部开发者工具。每项新能力都始于定义工具、将其托管在 AgentCore 上，并在各个 Agent 之间共享。

如果你正在构建需要多租户隔离、长期记忆或 m 的代理式 AI 系统，

Reactiv offers a mobile commerce product that helps Shopify merchants launch and manage native mobile apps, where shoppers convert at 2–4 times the rate of web visitors. For these merchants, a stale homepage or a missed promotional window costs real revenue. Yet keeping an app fresh requires constant manual work: choosing which products to feature, rearranging sections, generating new assets, and publishing updates on time. Most merchants don’t have the bandwidth to do this every week. Reactiv used Amazon Bedrock AgentCore to automate these updates, reducing merchant configuration time by 80 percent and getting to production 33 percent faster.

Reactiv set out to solve this with an AI Scheduler that updates merchant apps autonomously on a schedule. A merchant describes what they want in natural language, such as “Refresh my homepage with best sellers every Monday at 9 AM,” and the system handles the rest. They built it as a three-agent system on Amazon Bedrock AgentCore with the Strands Agents SDK and had it in production within weeks. They then unified their interactive and scheduled agents onto a single stack, achieving shared memory across both modes.

In this post, we walk through the architecture behind those results, why Reactiv chose Amazon Bedrock AgentCore, and how their product has evolved since launch.

The challenge: Content that doesn’t update itself

Reactiv builds native iOS and Android apps for Shopify merchants. Their tools include a low-code app builder, analytics dashboards, and AI-powered features. Before the AI Scheduler, Reactiv had already built a conversational AI builder. Merchants could chat with an AI assistant in the Reactiv dashboard to modify their app in real time.

That system worked for interactive use, but Reactiv’s merchants asked for something different: autonomous updates that happen on a schedule without any manual intervention. Building this required capabilities that the existing architecture didn’t support:

• Multi-agent orchestration. The scheduled task needed a supervisor to classify intent, an analytics agent to query merchant data, and a builder agent to generate configurations. Reactiv needed a managed runtime purpose-built for directed graphs of specialized agents, which led them to Amazon Bedrock AgentCore.
• Persistent memory. Every session started from scratch. The agent had no way to remember what a merchant preferred across runs or learn from past approvals.
• Native Model Context Protocol (MCP) support. Reactiv’s configuration schema server (the Config MCP) ran on Amazon Elastic Container Service (Amazon ECS) with a custom Amazon Cognito authentication layer and manual JSON-RPC handshakes on every invocation.
• Tool definition overhead. Each tool required an OpenAPI specification, AWS Lambda wiring, and action-group mapping. Approximately 100 spec files were maintained across two locations.

Reactiv needed a solution that could host multi-agent graphs, persist memory across sessions, connect to MCP servers natively, and isolate each merchant’s data automatically.

Why Amazon Bedrock AgentCore

Amazon Bedrock AgentCore is a platform to build, connect, and optimize agents at scale with any framework or model. Reactiv used three of its capabilities to address all four requirements. AgentCore runtime, a capability of Amazon Bedrock AgentCore, handles managed agent execution. AgentCore memory, a capability of Amazon Bedrock AgentCore, provides persistent cross-session context. AgentCore Identity, a capability of Amazon Bedrock AgentCore, handles service-to-service authentication.

Managed agent runtime. AgentCore runs agents in Firecracker microVMs, the same isolation technology behind AWS Lambda. Reactiv packages their Strands agent graph as a Docker image, pushes it to Amazon Elastic Container Registry (Amazon ECR), and deploys it to AgentCore. Agents spin up when a schedule triggers and shut down when done. No Amazon ECS clusters, scaling policies, or idle compute.

“We don’t manage containers, orchestrators, or scaling policies. We package our agent code as a Docker image, deploy it to AgentCore, and it handles the rest.” — Adam Gibicar, Senior AI Developer, Reactiv

Built-in memory. AgentCore provides long-term memory that persists across agent sessions. Reactiv uses three strategies. A session summarizer condenses each job’s actions into context for future runs. A preference learner tracks which layouts a merchant approves or rejects over time. A semantic fact extractor stores knowledge about the merchant’s store, such as product categories, top sellers, and brand guidelines. Memory is scoped per merchant, keeping each merchant’s data private. No custom vector database or retrieval pipeline required.

Native MCP hosting. Reactiv hosted their Config MCP on Amazon Bedrock AgentCore runtime. The MCP runs as a stateful server that initializes the merchant’s current app configuration at session start. The Builder Agent performs mutations against this live state, validated against the schema on every call. With AgentCore Identity, Reactiv handles service-to-service authentication natively, removing the custom authentication layer and JSON-RPC handshake code they had previously built and maintained.

Multi-tenant isolation. Each merchant’s execution context, memory, and agent state runs in its own Firecracker microVM. Merchant A’s preferences remain isolated from Merchant B’s sessions. AgentCore handles tenant routing and isolation at the infrastructure level.

Architecture overview

The following diagram shows the end-to-end flow of the AI Scheduler.

Figure 1: End-to-end flow of the Reactiv AI Scheduler. Amazon EventBridge triggers a Lambda executor that invokes the AgentCore runtime, where three Strands agents coordinate across MCP tools, Lambda functions, AgentCore memory, and Amazon Bedrock to produce app configurations stored in Amazon DynamoDB for merchant approval

The following table summarizes the services in the solution:

Service	Role
Amazon Bedrock AgentCore	Managed agent runtime, persistent memory, MCP hosting, AG-UI support, multi-tenant isolation
Amazon Bedrock	Foundation model access, guardrails
Amazon EventBridge	Cron scheduling for merchant-defined update cadences
AWS Lambda	Job executor and 17 tool functions invoked by agents
Amazon DynamoDB	Result storage for merchant review and approval
Amazon Redshift	Analytics data store powering the Analytics Agent’s text-to-SQL queries

The system starts with the merchant. From the Reactiv dashboard, merchants create a scheduled task through either a chatbot interface (“Refresh my homepage with best sellers every Monday at 9 AM”) or a form where they pick a prompt, frequency, and time. Both produce a schedule record backed by an Amazon EventBridge cron rule.

When the schedule triggers, the flow proceeds through five components:

1. Amazon EventBridge triggers a Job Executor (AWS Lambda) that validates the merchant’s account, acquires a concurrency lock, and pulls the merchant’s current app configuration from the database.
2. The Lambda function invokes the AgentCore runtime with the full context the agents need: the merchant’s prompt, current app configuration, and session metadata.
3. Inside the runtime, a Strands multi-agent graph executes:
   • The Supervisor Agent classifies the merchant’s intent and routes to the correct pipeline (analytics only, builder only, or analytics-then-builder).
   • The Analytics Agent queries merchant performance data through text-to-SQL against Amazon Redshift, surfacing trends, top products, and actionable insights.
   • The Builder Agent takes those insights and produces updated app configurations. To do so, it calls over 50 tools. These include configuration mutations through the Config MCP, data queries through Lambda functions, product lookups from the Shopify Storefront SDK, and asset creation with an image generation SDK.
4. The Config MCP (hosted on AgentCore) validates every mutation the Builder Agent makes against Reactiv’s app schema. The Builder Agent cannot produce an invalid configuration because the MCP acts as both reference and guardrail.
5. The generated configuration is stored in Amazon DynamoDB for merchant review. Nothing goes live without explicit merchant approval.

Throughout execution, AgentCore memory reads and writes the merchant’s long-term memory in an isolated namespace. Every scheduled job builds on preferences and facts the agent accumulated in prior sessions for that specific merchant. The three agents access foundation models through Amazon Bedrock, which provides serverless inference and built-in guardrails without requiring Reactiv to manage model hosting or GPU infrastructure.

Unifying interactive and scheduled agents

After launching the scheduler, Reactiv had two separate agent systems: the interactive dashboard agent (built with a custom UI adapter for Amazon Bedrock) and the scheduled agent (built on Strands with AgentCore). They did not share memory, tools, or infrastructure.

Reactiv unified them by migrating the interactive agent to the AG-UI protocol on Amazon Bedrock AgentCore. The dashboard agent now shares the same Strands framework, AgentCore-hosted MCP servers, and AgentCore memory instance as the scheduler. The result is one shared framework, runtime, memory layer, and UI protocol across both agents. The practical effect is bidirectional memory sharing. Preferences and facts learned during an interactive dashboard session feed directly into the next scheduled run, and vice versa. Scheduled jobs get smarter the more a merchant uses the front-end agent.

Results

After moving to Amazon Bedrock AgentCore, Reactiv realized gains across development speed, runtime performance, and merchant experience. According to Reactiv’s internal measurements:

• 80 percent reduction in merchant configuration time. Onboarding tasks that took 17 hours of manual work now complete in 3 hours, and post-launch changes happen in minutes instead of days.
• Simplified tooling and lower costs. The Strands SDK @tool decorator replaced approximately 100 OpenAPI spec files, AgentCore runtime and AgentCore Identity removed custom infrastructure, and the migration saves nearly $6,000 per year in compute costs alone.
• Persistent memory with zero custom infrastructure. Three long-term memory strategies per merchant, fully managed by AgentCore memory, with no vector database or retrieval pipeline to build or maintain.
• 33 percent faster time to production. A three-person team shipped the three-agent system in 10 weeks versus 15 weeks for the prior single-agent build. With AgentCore and Strands, the team focused engineering time on agent logic instead of infrastructure plumbing.
• 2x faster job execution. Scheduled jobs dropped from over 10 minutes to approximately 5 minutes using native streaming in AgentCore runtime, which replaced a four-step polling chain with a single real-time invocation.

What’s next

With the interactive and scheduled agents unified on a single stack, Reactiv is extending the authoring surface available to merchants. The through-line: merchants can customize their mobile apps through natural language, in progressively deeper ways.

The first step is making Reactiv’s existing design properties (colors, typography, spacing, component variants) available to the agent as a new MCP server hosted on Amazon Bedrock AgentCore. This mirrors the Config MCP approach: a shareable tool surface that the scheduler, the interactive builder, and eventually external integrations can all consume. Merchants can say “make my app match my brand” and the agent will apply changes within a governed design vocabulary rather than generating unconstrained output.

That design system also unlocks a rebuilt onboarding experience. When a new merchant provides their brand name and website, the agent analyzes their existing web presence and produces a strong starting point for the mobile app. Because the design system is in place, the agent can target real design properties and components rather than generating layouts from nothing.

Further out, Reactiv plans to let merchants request entirely new layout sections through natural language. The agent would generate a validated JSON representation of the requested layout, which the mobile app renders on the fly using Reactiv’s design system components. This extends the agent’s authoring capability beyond pre-built section types into merchant-defined layouts that still follow brand guidelines.

Conclusion

Reactiv started with a single agent on self-managed infrastructure and grew into a unified multi-agent system on Amazon Bedrock AgentCore. Today their production system runs three specialized agents, over 50 tools, and persistent memory shared across interactive and autonomous modes. Multiple MCP servers run on one managed runtime. They delivered it faster, with less infrastructure code, and with capabilities that would have required months of custom engineering otherwise.

The MCP-based architecture has proven especially reusable. Reactiv’s Config MCP pattern now extends to a design system MCP and, eventually, to external developer tooling. Each new capability starts with defining tools, hosting them on AgentCore, and sharing them across agents.

If you’re building agentic AI systems that need multi-tenant isolation, long-term memory, or managed MCP hosting, with Amazon Bedrock AgentCore, you can access these through AgentCore runtime, AgentCore memory, and AgentCore Identity. To get started, refer to the AgentCore documentation and the Strands Agents SDK.

---

About the authors

Adam Gibicar

Adam is a Senior AI Developer at Reactiv, where he specializes in architecting AI-powered mobile commerce infrastructure and multi-agent systems. His recent work focuses on developing Model Context Protocol (MCP) servers and agentic workflows using AgentCore to power real-time agent orchestration across complex microservice environments.

Ryan Masciovecchio

Ryan is a Solutions Architect at AWS based in Toronto, Canada. He works with startups on AI and machine learning workloads, helping customers design and build production agentic AI systems on AWS.