AI Agent for Inventory Reorder Optimisation

Reorder decisions are a good fit for an LLM-orchestrated agent for one reason: the inputs are scattered across systems (POS or ERP sales history, supplier lead times, current on-hand, open POs, seasonality) and the output is a judgment call that pure statistical forecasting handles poorly when demand is noisy or intermittent. The wrong mental model is "the AI decides what to order." The right one is "the agent assembles the evidence and proposes a number, a deterministic reorder-point calculation checks it against policy, and a human approves anything above a materiality threshold."

Forecasting is not the agent's job

Don't ask an LLM to predict next month's demand from a chat prompt — that's a regression problem, and classical methods (moving average, exponential smoothing, or a proper model like Prophet or a gradient-boosted forecaster for higher-value SKUs) will beat an LLM's guess and are far cheaper to run at scale across thousands of SKUs. The agent's job is upstream and downstream of the forecast: pulling the right data together, catching signals a pure time-series model misses (a supplier email saying lead time just doubled, a marketing calendar showing a promotion next week), and turning a raw reorder quantity into a readable recommendation with reasoning attached. Use the LLM for synthesis and communication, the stats model for the number.

Reorder point as a deterministic tool call

Expose your reorder-point formula as a tool the agent calls, not something it computes in its head from token predictions. Classic reorder point is ROP = (average daily demand × lead time in days) + safety stock, with safety stock sized off demand and lead-time variability. The agent's contribution is populating that formula correctly — pulling actual lead time from the last N purchase orders rather than the supplier's quoted number, which drifts — and flagging when a SKU's demand pattern doesn't fit the assumptions (a launch product with three weeks of history, a seasonal item about to hit its peak).

def calculate_reorder(sku: str) -> dict:
    """Deterministic ROP calc — the agent calls this, never estimates it."""
    demand = get_daily_demand_stats(sku, window_days=90)
    lead_time = get_actual_lead_time_days(sku)  # from PO history, not quoted
    safety_stock = Z_SCORE_95 * demand.stddev * (lead_time ** 0.5)
    rop = (demand.mean * lead_time) + safety_stock
    on_hand = get_on_hand(sku)
    open_po_qty = get_open_po_quantity(sku)

    return {
        "sku": sku,
        "reorder_point": round(rop),
        "current_position": on_hand + open_po_qty,
        "needs_reorder": (on_hand + open_po_qty) < rop,
        "suggested_qty": max(0, round(rop * 1.5 - (on_hand + open_po_qty))),
        "confidence": "low" if demand.sample_days < 30 else "normal",
    }

# Agent calls this per flagged SKU, then explains the "why" in plain language
# using the returned fields plus any qualitative context it retrieved.

Ground the recommendation in retrieved context, not vibes

A reorder recommendation without a citation to real data is not more useful than a spreadsheet formula — arguably less, since it's harder to audit. Structure the agent's tool access so every claim in its recommendation traces to a retrieved fact: "reorder 400 units of SKU-4471; demand has run 18% above the 90-day average for the last 3 weeks (see sales report), and the last two POs to this supplier took 21 days instead of the quoted 14." That's RAG in the practical sense — retrieval over your own transactional data, not a vector database of PDFs — and it's what makes a buyer trust the output enough to act on it without re-deriving it themselves.

Set the approval threshold by dollar exposure, not by SKU count

Auto-approve reorders below a spend threshold and route everything else to a buyer for confirmation — the threshold should be a dollar amount tied to your working-capital tolerance, not a flat rule like "always ask for restocks over 100 units," which treats a $2 fastener the same as a $2,000 component. Most inventory agents that get adopted successfully start with a low auto-approve ceiling and raise it only after enough approved recommendations have gone through without correction to justify the trust.

Close the loop by tracking what happened after

The single highest-value thing you can add after launch is feeding actual outcomes back into evaluation: did the SKU stock out anyway, did it overstock, was the buyer's edit to the suggested quantity significant. Log the agent's recommendation, the buyer's final decision, and the outcome 30/60/90 days later. That dataset is what tells you whether to raise the auto-approve threshold, whether a particular supplier's lead-time estimate needs recalibrating, and whether the agent's qualitative reasoning (not just the math) is actually adding signal or just noise dressed up in confident prose.

Wrapping up

Keep the forecasting math in a deterministic tool, use the LLM to gather scattered context and explain the recommendation in language a buyer can verify, and gate anything above a dollar threshold behind human approval. The payoff isn't replacing the buyer — it's cutting the time they spend hunting down lead times and sales history before they can make the call they were always going to make.