AWS Partner Network (APN) Blog

Autonomous replenishment with Databricks MMF, Genie, and Amazon Quick

By: Venkatavaradhan Viswanathan, Global Partner Solutions Architect – AWS
By: Ryuta Yoshimatsu, Senior Specialist Solutions Architect – Databricks
By: Antony Prasad Thevaraj, Senior Specialist Solutions Architect – Databricks

Partner Logo
Connect with Databricks

Replenishment decisions repeat every planning cycle for every item in the inventory catalog, and in most retail organizations planners still make them by hand. A planner exports the forecast, checks each stock keeping unit (SKU) against what suppliers can ship, and places the orders one line at a time. Pre-trained models now forecast demand across a full catalog with little tuning. What doesn’t scale is the manual work between the forecast and the order, on a catalog refreshed every day.

This post is for supply chain and data leaders deciding whether to automate that step. It covers what manual decisions cost, a pattern that places the routine reorders automatically and escalates only the exceptions, where the pattern fits and where it doesn’t, and the outcome across a full inventory catalog.

The cost of manual last-mile decisions

Every replenishment decision can err in two directions, and the same decision recurs every planning cycle. In perishable categories such as grocery, both errors carry direct cost. Underordering causes stockouts and lost sales, and overordering causes spoilage. The combined cost is large. IHL Group’s 2025 Inventory Distortion Study put it at about $1.73 trillion a year, roughly 6.5 percent of global retail sales. IHL’s 2026 study reports the figure at about $1.7 trillion, or roughly 5 percent of global retail revenue, with out-of-stocks accounting for approximately two-thirds of the total and overstocks the remaining third. For a single SKU on a single day, the cost is small, but across tens of thousands of items refreshed daily, decisions that arrive late or without current supplier data reduce margin through both lost sales and waste.

Most of these decisions are routine and follow a fixed rule: demand rises, a supplier has stock, the order is placed. That volume consumes most of the planner’s time while drawing on little of the expertise they were hired for. The decisions that genuinely need a person are the exceptions, such as when no supplier can cover the demand or the spend crosses an approval threshold. Today, those exceptions sit in the same queue as the routine cases and receive the same slow, manual handling. Separating the two is the opportunity.

A pattern for automating routine reorders

The idea is straightforward: let the forecast trigger the order in the routine cases and involve a person only when the situation is genuinely an exception. Databricks produces the forecast. The Databricks Many Model Forecasting (MMF) solution accelerator runs Chronos-2, an open-source, pre-trained forecasting model from Amazon, across the full catalog. Chronos-2 needs no per-item training and can factor in drivers such as promotions and holidays, so one model covers every product. A Databricks Genie Agent then flags the products about to surge. Someone in the business can ask, in plain language, which products are about to surge, instead of writing SQL. Amazon Quick acts on it. It checks each flagged product against supplier availability in Amazon S3 Tables, a capability of Amazon Simple Storage Service (Amazon S3), and a scheduled Amazon Quick Flows automation places the routine orders and escalates the rest. The forecast and the supplier data stay in their own systems.

The following figure shows how the replenishment loop runs in day-to-day business operations.

Figure 1 – A demand forecast feeds a detect, decide, act loop that places routine purchase orders automatically and sends exceptions to a planner

Figure 1 – How a replenishment decision moves from forecast to placed order: routine reorders are placed automatically, and only the exceptions reach a planner

For the step-by-step build and its design choices, see the companion post on the Amazon Web Services (AWS) Machine Learning Blog.

Where it fits and where it doesn’t

Reach for this pattern when three conditions hold at one time: the authoritative data lives in your data environment, the people who must act on it don’t work inside that environment, and the decision requires information from more than one system. We focus on replenishment in this post, but the same pattern appears wherever the authoritative data and the people who act on it sit in different systems.

It’s equally important to state where the pattern is the wrong tool. When a decision turns on judgment that no rule can capture, such as splitting scarce stock across regions that are all short, the system should surface the options and stop there. A scheduled automation is also too slow when the answer has to be returned in milliseconds. The pattern pays off in one specific case: where a clear rule handles the ordinary decisions and people are freed to spend their time on the rest.

The business outcome

The result is replenishment that runs from forecast to placed order without anyone signing into a console, writing SQL, or switching between tools. The scale is straightforward to estimate. Consider a 50,000-SKU catalog refreshed daily. If roughly 80 percent of the reorder decisions are routine, the loop settles on the order of 40,000 lines per day on its own. The planner’s workload drops from the full catalog to the remaining exceptions that require human judgment. These are illustrative figures, not measured pilot results.

Because none of these components are specific to grocery or to supply chain, the same pattern is a repeatable way to turn a prediction into action across the business. It applies to other high-volume decision cycles, such as the financial close, field-service dispatch, and fraud triage, wherever a prediction and the action it implies are separated across systems and roles.

Learn more

For the full technical build, including the architecture, the approach to scaling, and a complete reference implementation, visit the companion code repository on GitHub. For how the forecasts themselves are produced at scale, read the Databricks companion post, Forecasting at the speed of modern retail. To put the pattern to work, start from the step-by-step walkthrough and engage your AWS or Databricks account team to scope a first use case.

Connect with Databricks


Databricks – AWS Partner Spotlight

Databricks is the data and AI company. More than 20,000 organizations worldwide, including adidas, AT&T, Bayer, Block, Mastercard, Rivian, Unilever, and 70 percent of the Fortune 500, rely on the Databricks Data + AI Platform to unify their data, analytics, and AI. Built on an open source foundation, the platform gives teams a practical way to build AI that understands their business context. The platform includes the products Lakebase, Genie, Unity Gateway, Agent Bricks, Lakeflow, Lakehouse, and Unity Catalog. Databricks holds 11 AWS Competencies, including Data & Analytics, Machine Learning, AI, and Retail, and was named an AWS Partner of the Year in seven categories at re:Invent 2025.

Contact Databricks | Partner Overview | AWS Marketplace