Home Blog Crossing the Demo-to-Prod Gap Before Your Agent Orders Stock

Crossing the Demo-to-Prod Gap Before Your Agent Orders Stock

I give talks and workshops on this material for retail teams and conferences. See past talks or invite me to speak.

Chapter 10 of Foundations of Agentic AI for Retail, Third Edition: Controls before autonomy widens

Series: Foundations of Agentic AI for Retail, Chapter 10 of 14. Updated for the Third Edition (October 2026).
From the book: Foundations of Agentic AI for Retail, Third Edition

A prototype agent watches one store's stock of jeans, and in the demo it shines. Then a queue delivers the same sale event twice, and the agent counts the sale twice.

In fashion, the extra order that follows may end the season marked down.

I call the distance between a demo like that and a system that holds up in production the demo-to-prod gap. Chapter 10 is about crossing it, and my answer is short: put each control in place before the agent's autonomy widens.

Why a duplicate sale event is a buying problem

Send a deterministic web app the same request twice and it does the same thing twice. Send the store's agent the same sale event twice and, unless it was built to ignore the copy, it orders stock nobody needs.

— Foundations of Agentic AI for Retail, Chapter 10

That duplicate is one of the events in the chapter's first fixture, a simulated store built to break a simple replenishment rule. Others include a supplier delay and a season-end sale that empties the shelf when no reorder makes sense. Each one exposes a different mistake an agent can make with real stock.

The gap shows up as assumptions that hold in a demo and break in a store.

In the demo In production
Each sale event arrives once Queues and retries can deliver the same event twice
An empty shelf means reorder Every stockout needs a disposition the policy allows, and sometimes that is no order
One clean run looks like proof One synthetic episode is not an evaluation baseline
A low escalation rate looks healthy It is good only if every case that needs a person still reaches one

What has to be true before an agent places a real order

Before the agent may reorder a single unit, its team has to show it is ready. The chapter turns that into a short list of minimum production readiness gates, from versioned schema contracts on every tool call to budgets that throttle cost. If any gate is missing, the system stays in pilot mode.

Load is its own test. When my team's systems at OODARIS AI met real load, the first things to break were database input and output capacity, the memory of the serverless instances that run the data engineering, and parallelization. We measure and tune constantly.

Here is the shape of the path the chapter describes, with autonomy widening only after the gates pass.

flowchart LR D["Prototype demo"] --> G{"Readiness gates pass?"} G -->|Not yet| P["Pilot mode"] P --> G G -->|Yes| C["Canary stores"] C --> W["Wider autonomy"] W -.->|Operations feedback| D

What the capstone reorder proves, and what it cannot

In the book's capstone, SKU-123 is down to 20 units before a holiday weekend, and a proposal to reorder would commit 6,000 dollars to a supplier. That is above the 5,000-dollar line at which a buyer must approve, so the agent stops and waits.

A buyer who is not the requester approves, the approval lands in the audit log, and a duplicate receipt counts once. The controls hold.

Then the chapter reads the outcome as a merchant would, and the verdict is more careful than the green checks. As I put it in the chapter's conclusion, "The reorder passed its control checks, but its economics are unproven." Three readiness gates remain open, so the capstone stays in pilot mode.

What the chapter gives you

  • The minimum production readiness gates, the test that decides whether an agent leaves pilot mode
  • Three hypothetical fixtures that carry the chapter: a simulated store built to break a restock rule, a unit test of that rule, and the capstone's governed reorder of SKU-123
  • A catalog of workflow patterns for retail, from propose then approve to fallback then recover, and the seven-step build sequence the capstone follows from stub to production
  • Companion code for the testing, tracing and dashboard listings, a capstone scaffold demo you can run, and nine exercises

Go deeper

Chapter 10 of the Third Edition, out since October 2026, has the full method, the three fixtures and the companion code. This post only hinted at two of its sections: "Testing Strategies for Autonomous Systems," where exact assertions meet an agent whose outputs vary, and "Debugging Techniques for Autonomous Systems," which starts from a pricing agent that sets a bizarre price at 3 AM. New in the Third Edition: Part IV readies the capstone system for production, with Black Friday as its stress test.

See the book →