Automating Scheduled Mobile Commerce Updates with Multi-Agent Workflows

Overview

Reactiv provides native iOS and Android commerce applications for Shopify merchants. Before this project, merchants could use an interactive conversational builder to modify their apps, but keeping those apps current required recurring manual work: selecting products, rearranging sections, creating assets, and publishing promotional changes. Reactiv’s AI Scheduler extends the conversational experience into autonomous, merchant-defined workflows. A merchant can express a recurring request such as “Refresh my homepage with best sellers every Monday at 9 AM,” and the platform schedules an agent run that analyzes store data, constructs a proposed configuration, and places the result in a review queue.

The production implementation is a three-agent system running on Amazon Bedrock AgentCore with the Strands Agents SDK. A Supervisor Agent routes work, an Analytics Agent queries merchant performance data, and a Builder Agent generates configuration changes using MCP servers and other tools. AgentCore supplies managed execution, persistent memory, service identity, MCP hosting, and tenant isolation. Reactiv reports that this architecture reduced merchant configuration time by 80%, accelerated its time to production by 33%, and cut scheduled-job execution time roughly in half. Because the measurements come from Reactiv’s internal comparison and the article is also an AWS product success story, the results should be treated as reported outcomes rather than independently verified benchmarks.

Problem and production requirements

Reactiv’s original conversational agent was designed for interactive sessions. Scheduled automation introduced a different operational model: jobs had to run without a user present, retain context from previous executions, access current merchant data, produce valid app configurations, and remain isolated across tenants. The company identified several gaps in its earlier architecture. Sessions started without durable memory, the configuration MCP server required custom authentication and manual JSON-RPC handshakes, and tool integration involved maintaining approximately 100 OpenAPI specification files in two locations. The planned workflow also required multiple specialized agents rather than a single conversational assistant.

These requirements are representative of LLMOps concerns in production. The system needed repeatable triggering, execution management, state and memory boundaries, tool authentication, schema validation, concurrency control, artifact persistence, and a human approval step. The LLM was therefore only one component in a larger workflow; deterministic cloud services and application-level controls determine when an agent runs, what context it receives, where its output is stored, and whether the output can affect a live mobile application.

Architecture and execution flow

A merchant creates a schedule through the Reactiv dashboard, either conversationally or through a form. The resulting schedule is represented by an Amazon EventBridge cron rule. When the rule fires, an AWS Lambda Job Executor validates the merchant account, acquires a concurrency lock, and retrieves the current app configuration. It then invokes the AgentCore runtime with the merchant’s prompt, current configuration, and session metadata.

Inside the runtime, a Strands multi-agent graph coordinates the workflow. The Supervisor Agent classifies the request and selects an analytics-only, builder-only, or analytics-then-builder path. The Analytics Agent uses text-to-SQL against Amazon Redshift to find trends, top products, and other actionable store insights. The Builder Agent uses those insights to construct an updated app configuration. Its tool surface includes configuration mutations through the Config MCP, Lambda-backed data queries, product lookups through the Shopify Storefront SDK, and asset generation through an image-generation SDK. The source describes more than 50 tools available to the Builder Agent.

The Config MCP is hosted on AgentCore as a stateful server. It initializes the merchant’s current configuration at session start, and the Builder Agent performs mutations against that live state. Each mutation is checked against Reactiv’s application schema. This is an important reliability boundary: rather than allowing a model to emit unconstrained JSON that is later interpreted by the application, the MCP exposes governed operations and validates changes as they are made. Schema validation does not by itself guarantee that a design is commercially effective, factually appropriate, or safe for every business rule, but it reduces one important class of malformed-output failures.

The proposed configuration is written to Amazon DynamoDB for merchant review. The source explicitly states that nothing goes live without explicit approval. This approval gate limits the blast radius of erroneous product selection, unsuitable generated assets, or an otherwise undesirable layout. It also means the scheduler is better characterized as an automated recommendation and configuration-generation system than as a fully autonomous publishing system.

Memory, identity, and tenant isolation

AgentCore memory stores context across runs in a merchant-scoped namespace. Reactiv describes three memory strategies: a session summarizer condenses the actions taken during each job, a preference learner records which layouts a merchant approves or rejects, and a semantic fact extractor stores information such as product categories, top sellers, and brand guidelines. Future scheduled jobs can use this information to tailor their proposals without Reactiv maintaining a custom vector database or retrieval pipeline.

The architecture also uses AgentCore Identity for service-to-service authentication. This replaces the custom authentication layer and repeated JSON-RPC handshake code that Reactiv had used for its Config MCP. AgentCore runtime executes packaged agent code in Firecracker microVMs. Reactiv builds the agent graph into a Docker image, publishes it to Amazon Elastic Container Registry, and deploys it to AgentCore, which manages execution when a job starts rather than requiring Reactiv to operate ECS clusters, scaling policies, or continuously running compute.

AgentCore is described as providing isolation for execution context, memory, and agent state for each merchant. This is relevant to multi-tenant LLMOps because merchant preferences, configuration state, and generated results must not leak between customers. The source presents infrastructure-level isolation as a capability of the platform, but it does not provide an independent security assessment, formal threat model, or detailed evidence about authorization testing. In a production review, Reactiv would still need application-level access checks, audit logging, data-retention controls, prompt and tool authorization policies, and tests for cross-tenant failure modes.

Unifying interactive and scheduled agents

After launching the scheduler, Reactiv had two agent implementations: an interactive dashboard agent and the scheduled Strands/AgentCore agent. They initially differed in memory, tools, and infrastructure. Reactiv migrated the interactive agent to the AG-UI protocol on AgentCore and aligned it with the same Strands framework, AgentCore-hosted MCP servers, and memory instance used by the scheduler.

This unification creates bidirectional memory sharing. Preferences or facts learned during an interactive session can influence the next scheduled run, while scheduled activity can inform later dashboard interactions. Operationally, a shared stack reduces duplicated integration code and makes tool surfaces reusable across modes. It also increases the importance of memory governance: incorrect or stale preferences can influence both interactive and scheduled behavior, so production implementations need mechanisms for correction, expiration, inspection, and possibly explicit user confirmation of durable facts. The source describes the memory strategies but does not report evaluation results for memory accuracy or contamination.

Results and evaluation considerations

Reactiv reports that onboarding and configuration work requiring 17 hours manually can be completed in 3 hours, and that post-launch changes can be made in minutes rather than days. It also reports a 33% faster time to production: a three-person team delivered the three-agent system in 10 weeks, compared with 15 weeks for an earlier single-agent build. The article attributes part of this improvement to the Strands @tool decorator, which replaced approximately 100 OpenAPI specification files, and to managed runtime and identity capabilities. Reactiv further reports nearly $6,000 per year in compute savings and a decrease in scheduled-job duration from more than 10 minutes to approximately 5 minutes after replacing a four-step polling chain with native streaming and a single real-time invocation.

These figures are useful directional indicators, but the source does not define a controlled experimental methodology, workload mix, model versions, token consumption, latency percentiles, error rates, approval rates, or total cost of ownership. The comparison may include architectural changes beyond AgentCore itself, and configuration time is not necessarily equivalent to business value or merchant satisfaction. A fuller LLMOps evaluation would track successful schema-valid proposals, tool-call failure and retry rates, SQL correctness, hallucinated product or analytics claims, human rejection and revision rates, end-to-end latency, model and infrastructure cost per job, and incidents involving tenant isolation or inappropriate content.

Tradeoffs and future direction

The managed approach reduces the amount of infrastructure Reactiv must build and operate, and it provides a common execution and integration layer for multiple agents. MCP-based tools also create a reusable contract: the same governed capabilities can be exposed to the scheduler, interactive builder, and future integrations. However, the design increases dependence on AgentCore, Bedrock, Strands, and AWS-specific operational primitives. Managed memory may simplify deployment but can make portability, debugging, data export, and detailed retrieval control more dependent on the platform. Multi-agent routing and a large tool surface can improve specialization while also creating more possible failure paths and more complex observability requirements.

Reactiv plans to expose design properties such as colors, typography, spacing, and component variants through another AgentCore-hosted MCP server. This would let the agent make brand-aligned changes within a governed design vocabulary rather than generating unconstrained layouts. It also plans to analyze a new merchant’s website to produce a mobile-app starting point and eventually generate validated JSON for new layout sections rendered through Reactiv’s design-system components. These extensions preserve the same core LLMOps pattern: natural-language intent is translated into tool calls and structured artifacts, with schema and design-system constraints used to control the output. As the system becomes more capable, maintaining approval workflows, observability, regression tests, evaluation datasets, and explicit limits on autonomous actions will remain important.