Reactiv says an AI scheduler cut mobile-app updates from hours to minutes

Reactiv says it has used Amazon Bedrock AgentCore to automate the routine work of updating Shopify merchants’ native mobile apps. The useful part is not that an agent can write a cheerful sentence about best sellers. It is that scheduled, multi-agent software can now analyse store data, propose configuration changes and wait for merchant approval before anything goes live.

AWS AI Watch analysis

What happened

In an AWS case study published on 22 September, Reactiv describes an AI Scheduler that lets merchants request updates in natural language, such as refreshing a homepage with best sellers every Monday. A three-agent system classifies the task, queries merchant data and builds a revised app configuration.

Reactiv says the system uses AgentCore runtime, persistent memory, hosted Model Context Protocol tools and identity controls. EventBridge triggers scheduled jobs, while the resulting configuration is stored for review in DynamoDB. The company says its Config MCP validates each proposed change against the app schema, and that no update is published without explicit merchant approval.

The practical results are company-reported: Reactiv says work that previously took 17 hours can now take about three, post-launch changes can happen in minutes rather than days, scheduled jobs have fallen from more than 10 minutes to roughly five, and a three-person team delivered the system in 10 weeks rather than an estimated 15.

Why it matters

This is a useful example of AI being attached to a repeatable business workflow rather than waved over a dashboard like technological fairy dust. The agent can remember merchant preferences, inspect performance data, generate app changes and carry them through a controlled review step.

The strongest idea is the approval boundary. Reactiv is not allowing an autonomous system to publish every generated change directly. It is using automation to prepare work, validate it against a schema and leave the final decision with the merchant. That is a much more credible pattern for commerce systems, where a wrong homepage can become a very real sales problem.

Our read

Reactiv’s figures are internal measurements reported in AWS’s case study, not an independent assessment. They do not establish the system’s accuracy, conversion impact, cost at larger scale or how often merchants reject its suggestions. Still, the architecture is more instructive than another generic claim that AI makes work faster.

The transferable lesson is to automate the boring sequence while keeping authority narrow: scheduled triggers, specialised agents, scoped memory, validated tools and a human approval gate. If the agent gets the product mix wrong, the merchant should be able to veto it before customers see the result. A surprisingly radical notion in 2026: ask before publishing.

What to watch

• Merchant approval:
  whether Reactiv publishes rejection rates and examples of changes people overruled.
• Recommendation quality:
  whether faster updates improve app engagement or merely produce more frequent rearranging.
• Memory controls:
  how merchants inspect, correct or delete preferences stored across sessions.
• Operational scale:
  whether the same design works as merchants, tools and scheduled jobs multiply. Source: AWS’s case study on Reactiv’s use of Amazon Bedrock AgentCore, which attributes the performance figures to Reactiv’s internal measurements.

Discussion spark: Should commerce agents be allowed to publish routine changes automatically once they pass schema checks, or should a person approve every customer-facing update?

not affiliated with or endorsed by Amazon Web Services (AWS)