What If a Grocery Store Could Learn From Every Stockout?

Kota Preetham — Tue, 29 Sep 2026 14:24:18 +0000

A stockout is usually treated as a problem that happened.

I wanted GrocerAI to treat it as something the store could learn from.

If the store restocked 30 units before a busy period and those units disappeared in roughly 2.5 hours, the next similar situation should not be treated as completely new.

The system should remember what happened.

Then the next recommendation should change.

That became the foundation of the GrocerAI Store Agent: an operational AI agent that watches store signals, reasons about demand and inventory, recommends actions, observes the outcomes, and stores useful experiences for future decisions.

Why the Store Needed Its Own Agent

The Customer Agent asks:

“What does this particular shopper need?”

The Store Agent asks a different question:

“What is happening across the store, and what should the store do next?”

Those responsibilities include:

inventory monitoring
product demand
stock availability
stockouts
unmet demand
checkout activity
restocking
operational outcomes

A generic chatbot was not enough.

The Store Agent needed access to authoritative store data and the ability to reason over multiple signals at once.

The Store Agent Watches the Demand Funnel

One of the most important design decisions was not treating every product interaction as a purchase.

Suppose the store sees:

100 searches
      ↓
60 product views
      ↓
30 cart additions
      ↓
20 checkout attempts
      ↓
15 successful purchases

There are many signals here.

But only 15 successful payments represent confirmed sales.

So GrocerAI distinguishes different stages of demand:

SEARCH DEMAND
      ↓
INTEREST
      ↓
SHOPPING INTENT
      ↓
CHECKOUT INTENT
      ↓
CONFIRMED DEMAND
      ↓
UNFULFILLED DEMAND

This matters for inventory decisions.

If 100 people searched for a product but only 15 purchased it, treating those 100 searches as confirmed demand would distort the store's understanding of what actually happened.

The Store Agent therefore reasons over the funnel rather than one isolated metric.

The Store Agent Uses Tools, Not Guesswork

The Store Agent is powered by an LLM reasoning layer, but operational facts come from backend tools.

The agent can work with information such as:

Inventory
Product catalog
Customer demand
Transactions
Stock availability
Checkout activity
Unmet demand
Restocking history
Operational outcomes

The basic architecture is:

Store Signals
     ↓
Store Agent
     ↓
Reasoning
     ↓
Backend Tools
     ↓
Recommended Action

This separation is important.

An LLM can reason about whether the current signals justify a restocking recommendation.

It should not invent how many units are currently in inventory.

The Store Also Needs Memory

Current inventory answers:

“How many units do we have now?”

It does not answer:

“What happened the last time we saw this situation?”

That second question is where Hindsight becomes useful.

I gave the Store Agent its own memory scope:

grocerai-store-main

Customer memories remain isolated in customer-specific banks.

Store memory instead captures experiences about store operations.

This keeps two different kinds of learning separate:

Customer Agent
      ↓
Personal Experiences

Store Agent
      ↓
Operational Experiences

The store can aggregate operational signals across customers without writing those experiences into an individual's personal memory.

The 30 → 50 Learning Scenario

The clearest test of the Store Agent was a restocking scenario.

Imagine the store previously decided to restock:

30 units

A busy period followed.

Those 30 units were depleted in approximately:

2.5 hours

That outcome is important.

If the same kind of demand appears later, the Store Agent should be able to recall it.

The learning loop becomes:

Previous Demand
      ↓
Restock 30 Units
      ↓
Stock Depletes Quickly
      ↓
retain(outcome)
      ↓
Future Similar Demand
      ↓
recall(previous outcome)
      ↓
Adapt Recommendation
      ↓
Recommend ≥50 Units
      ↓
Manager Approval
      ↓
Observe New Outcome
      ↓
retain(new outcome)

The important part is not that the system changed 30 to 50.

The important part is why it changed the recommendation.

A previous operational outcome influenced a future operational decision.

That is what makes the system adaptive rather than simply reactive.

Manager Approval Stays in the Loop

I did not want an AI recommendation to silently change store operations.

The Store Agent produces intelligence.

The manager remains responsible for approving, modifying, or dismissing recommendations.

The flow is therefore:

Store Signals
     ↓
Store Agent
     ↓
Recommendation
     ↓
Manager Review
     ↓
Approve / Modify / Dismiss
     ↓
Operational Action
     ↓
Observe Outcome
     ↓
Remember Outcome

This also creates a useful feedback loop.

The system can learn not only from what it recommended, but from what happened after the decision.

Unmet Demand Is More Than a Missing Product

A product being unavailable is not the whole story.

The store should understand whether customers were actually asking for it.

For example:

Product searched
      ↓
Product unavailable
      ↓
Customer cannot purchase
      ↓
Unfulfilled demand

That is different from:

Product available
      ↓
Customer purchases
      ↓
Confirmed demand

GrocerAI therefore treats unfulfilled demand as a meaningful operational signal.

This helps the Store Agent reason about situations where the store may be losing demand because inventory does not match what customers are trying to buy.

Checkout Activity Also Becomes a Store Signal

The store can observe checkout activity independently from successful purchases.

That distinction is useful.

For example:

Checkout started
      ↓
Payment failed
      ↓
No completed order
      ↓
No inventory deduction
      ↓
No confirmed sale

A successful payment has different semantics:

Payment successful
      ↓
Completed order
      ↓
Inventory deduction
      ↓
Sales event
      ↓
Confirmed demand

Keeping these states separate prevents the Store Agent from learning from transactions that never actually happened.

The Complete Store Learning Loop

The mental model I used for the Store Agent was:

OBSERVE
   ↓
RECALL
   ↓
REASON
   ↓
ACT
   ↓
RE-OBSERVE
   ↓
REMEMBER

Applied to store operations:

Observe demand
      ↓
Recall previous outcomes
      ↓
Reason about current signals
      ↓
Recommend action
      ↓
Manager decision
      ↓
Observe result
      ↓
Remember outcome

The loop can continue across future shopping periods.

That is the key difference between a static dashboard and a learning operational agent.

Why Hindsight Is Not the Inventory Database

I deliberately did not use Hindsight as a replacement for structured store data.

The structured backend answers deterministic questions:

How many units are available?
What is the product ID?
What is the current price?
What orders exist?
What happened in the current transaction?

Hindsight answers a different category of question:

What happened before?
Which operational outcome may be relevant now?
What experience should influence the next decision?

So the architecture becomes:

Structured State
      +
Operational Memory
      ↓
Store Agent Reasoning
      ↓
Action

That separation made the system much easier to reason about.

What I Learned Building the Store Agent

1. Demand is not the same as sales

Searches, views, carts, checkout attempts, and successful purchases carry different meanings.

A store agent needs those distinctions.

2. Recommendations are not learning

A system that recommends 50 units is not necessarily adaptive.

It becomes adaptive when it remembers the outcome and uses that experience in a later decision.

3. Outcomes matter more than actions

The important memory is not only:

“We restocked 30 units.”

It is:

“We restocked 30 units, demand stayed high, and the stock depleted quickly.”

That outcome contains the information needed for future reasoning.

4. Human approval is useful

The Store Agent provides operational intelligence, while the manager remains in the decision loop.

This makes the system easier to inspect and control.

5. Memory should have a scope

Store-level operational memory and individual customer memory should not become one shared bucket.

Different scopes produce different kinds of reasoning.

The Architecture

The Store Agent sits alongside the Customer Agent but solves a different problem:

                    GROCERAI
                       │
          ┌────────────┴────────────┐
          │                         │
   Customer Agent             Store Agent
          │                         │
          ↓                         ↓
Customer Memory              Store Memory
          │                         │
          └────────────┬────────────┘
                       ↓
                Hindsight Layer
                       │
                       ↓
              Adaptive Decisions

The Customer Agent learns about people.

The Store Agent learns about operations.

Both use the same fundamental principle:

what happened before should be useful when deciding what to do next.

The Bigger Idea

A grocery store already generates enormous amounts of operational information.

The challenge is turning that history into something that can influence future decisions.

With GrocerAI, the Store Agent can connect:

Current Signals
      +
Relevant Past Outcomes
      ↓
Better-Grounded Reasoning
      ↓
Operational Action
      ↓
New Outcome
      ↓
Future Memory

That creates a feedback loop instead of a one-way dashboard.

The goal was never to make the store “smart” by adding another chatbot.

The goal was to make the store remember what happened, understand why it mattered, and use that experience the next time a similar situation appears.

That is the behavior I wanted from a self-adaptive grocery store.

DEV Community: Kota Preetham