AI Agent Systems for Supply Chains: Structured Decision Prompts and Memory Retrieval

TL;DR

Running a multi-tier supply chain well means each stage (retailer, wholesaler, distributor, manufacturer) has to decide how much to order every round, without over-ordering (holding costs) or under-ordering (backlog penalties, angry customers). The two standard tools are heuristics (simple, but need hand-tuning per scenario) and reinforcement learning (adaptive, but expensive to train and simulate). This paper asks a more basic question first: can you skip both and just ask an LLM? It shows that a carefully engineered prompt — one that explains the mechanics of the environment step by step and hands the LLM a classic safety-stock formula — lets a multi-agent LLM system (one agent per supply-chain tier) reach the provably optimal ordering policy in a simple constant-demand scenario, with zero training. But that same recipe breaks down the moment demand starts trending up or down: the prompt encodes a fixed strategy, and a fixed strategy can’t adapt. Their fix, AIM-RM, gives each tier’s agent a small memory of past situations (state vector, order placed, profit earned) it can search by similarity and feed into the prompt as “similar cases — treat as evidence, not rules.” When that memory is pre-seeded with even a cheaply-trained RL agent’s rollout, the LLM system gets most of the benefit of multi-agent RL (competitive average performance against IPPO/MAPPO) without ever training a policy network. The honest caveat: it’s still 2–3x worse than trained RL on the paper’s own optimality-gap metric, and more “reasoning effort” from the LLM often makes things worse, not better, once the prompt gets complex — a real, reproduced instance of “overthinking.”

Problem & Motivation

Multi-echelon inventory management — the retailer orders from the wholesaler, who orders from the distributor, who orders from the manufacturer, each with its own lead time, capacity, and costs — is one of the oldest hard problems in operations research. Two approaches dominate in practice:

• Heuristics (base-stock policy, demand-tracking policy): cheap and interpretable, but brittle. Each new scenario — different lead times, different demand pattern, different cost structure — usually needs its parameters re-tuned by hand.
• Multi-agent reinforcement learning (IPPO, MAPPO under the “centralized training, decentralized execution” pattern): genuinely adaptive, and the current state of the art on optimality, but expensive. You need a calibrated simulator, thousands of training rollouts, and hyperparameter search — impractical for a real company’s actual supply chain, which you can’t cheaply simulate at that scale.

LLM-based multi-agent systems (MASs) are the obvious third option everyone’s been trying since 2023: skip training entirely, describe the problem in a prompt, let the model reason its way to an order quantity each round. Prior work (InvAgent, and follow-ups that add negotiation or RAG over manufacturing textbooks) shows this basically works — but nobody had checked whether it works well, in the sense of ever reaching the actual optimal policy, or whether it’s just “good enough to publish a number.” That’s the gap this paper opens with: can an LLM-MAS, without any scenario-specific prompt tuning, find the mathematically optimal ordering policy — and if not everywhere, where does it break, and can you fix that without going back to RL?

What’s New (Core Contribution)

• A step-by-step process prompt (P_SD) that closes InvAgent’s biggest gap. Before: the original InvAgent prompt ([Quan & Liu, 2024]) tells the LLM its current state (inventory, backlog, lead time) but never explains the mechanics of the environment — when an order actually arrives, what happens before what in a round. Now: this paper adds an explicit walkthrough of the four-step period cycle (receive delivery → decide order → ship → calculate profit), including a worked lead-time example, inserted directly into the decision prompt. This alone measurably improves order-quantity accuracy.

• A safety-stock strategy prompt (P_SS) — textbook OR knowledge, handed over as instructions, not trained in. Before: LLM-MASs were expected to infer a good ordering strategy purely from state descriptions. Now: the prompt explicitly teaches the classic “order-up-to with safety stock” formula (inventory position, target level, safety buffer scaled by demand volatility). With this and P_SD together, the LLM system reaches the literal, solver-verified optimum in the constant-demand scenario — the first time (per the authors) an LLM-MAS has been shown to hit true optimality on a multi-echelon problem, not just “beat a heuristic.”

• AIM-RM: memory-augmented decision-making via similarity retrieval. Before: every LLM-MAS in this line of work is stateless across scenarios — the prompt is the only “policy,” and it’s frozen once written. Now: each tier’s agent keeps a growing memory of (state, order placed, profit earned) triples. At decision time it retrieves the K nearest past states (Euclidean distance, under a threshold) and drops them into the prompt as “similar cases — evidence, not rules.” This is the paper’s actual novel mechanism: retrieval-based, non-parametric adaptation instead of prompt rewriting or gradient updates.

• Bootstrapping memory from RL rollouts instead of training on them. Before: if you have RL training data, the standard move is to use it to train (or fine-tune) a policy. Now: the paper pre-loads AIM-RM’s memory with the evaluation trajectories of a trained IPPO agent — not the weights, just the logged (state, action, reward) history. The LLM system never sees gradients; it just gets to “remember” what a competent RL policy did in similar situations. This is closer to case-based reasoning / one-shot distillation-by-retrieval than to fine-tuning, and it’s the version that performs best.

Be honest about what’s not new: safety-stock formulas are 70-year-old operations research, KNN-over-a-vector-store is standard RAG plumbing, and IPPO/MAPPO are off-the-shelf baselines the authors didn’t design. The genuine contribution is narrow but real: showing prompt completeness (not cleverness) gets you to the actual optimum in the easy case, precisely characterizing where that stops working, and using retrieval — seeded from RL, not replacing it — as the adaptation mechanism instead of either prompt-engineering-by-hand or training a network.

How It Works (Technically)

The environment. Picture a chain of M tiers, tier 0 = retailer, tier M-1 = manufacturer. Each period t, four things happen in order at every tier: (1) materials ordered L_m periods ago arrive and become inventory; (2) the tier places a new order O_{m,t} with its upstream supplier while fulfilling downstream demand from available stock; (3) it ships what it can — capped by production capacity or on-hand inventory, whichever is smaller — with anything unmet becoming backlog; (4) it books profit/loss for the period. The state each agent sees, s_{m,t}, is its own recent inventory, backlog (both its own and its downstream customer’s backlog to it), and its recent shipment/receipt history over the lead-time window.

The core bookkeeping (from the OR-Gym formulation this paper builds on) is a small set of update rules. Translated to plain English:

• S_{0,t} = min(B_{0,t-1} + D_t, c_0, I_{0,t-1} + R_{0,t-1}) — the retailer can only ship the smallest of: what it owes plus new demand, its production/shipping capacity, or what it actually has on hand.
• B_{m,t} = B_{m,t-1} + O_{m-1,t} - S_{m,t} — backlog grows by new orders coming in and shrinks by what actually got shipped.
• I_{m,t} = I_{m,t-1} + R_{m,t-L_m} - S_{m,t} — inventory is topped up by deliveries that were ordered L_m periods ago finally arriving, and drawn down by shipments out.
• P_{m,t} = p_m S_m - r_m R_{m,t} - k_m B_{m,t} - h_m I_{m,t} — profit is sales revenue, minus what you paid your supplier for what arrived, minus a backlog penalty, minus a holding cost on unsold inventory.

None of this is exotic — it’s exactly the cost accounting any inventory manager already does mentally. The point of P_SD (the step-description prompt) is to make the LLM do this same bookkeeping explicitly and in the right order, because the original InvAgent prompt just handed over numbers without explaining what causes what.

One decision, traced end to end. Say we’re at tier 1 (wholesaler) in round t, running AIM-RM:

1. The agent observes its state s_{1,t}: current inventory, its own backlog, its downstream customer’s backlog to it, and its recent shipment/receipt history — plus, notably, the order the downstream tier just placed this round (agents act tier-by-tier within a round, not simultaneously, so tier 1 can literally see tier 0’s fresh order before deciding its own).
2. That state is embedded — here, “embedding” just means taking the raw numeric fields [inventory, backlog, upstream_backlog, lead_time, deliveries] as a vector; no neural encoder involved.
3. AIM-RM computes the Euclidean distance from this vector to every stored case in tier 1’s memory, sorts ascending, keeps the K=6 nearest, and discards any beyond a distance threshold τ=2. What’s left, R, is the “similar cases” evidence set.
4. The full prompt is assembled: the decision prompt P_DM (state + what the downstream tier just ordered) + the step-description P_SD + the memory-usage instructions P_MU (“similar cases are evidence, not rules”) + the retrieved cases R + the demand description D (which, notably, tells the agent the exact deterministic demand formula for the whole episode up front — this is a “given the ground truth, can you act on it” test, not a forecasting test).
5. The LLM returns an order quantity O_{1,t} and a natural-language reason.
6. The order is submitted to the environment; the environment returns the next state and the period’s profit.
7. That new triple (state, order, profit) is written back into tier 1’s memory for future retrieval — the memory grows as the episode plays out.

Repeat across all M tiers each round, across all T rounds.

Architecture & data flow

flowchart LR
  subgraph SC["Supply chain (sequential within a round)"]
    direction LR
    T0["Tier 0: Retailer agent"] -->|order O0| T1["Tier 1: Wholesaler agent"]
    T1 -->|order O1| T2["Tier 2: Distributor agent"]
    T2 -->|order O2| T3["Tier 3: Manufacturer agent"]
  end
  CUST["Customer demand D_t"] --> T0
  UP["Environment / user proxy"] -.state, reward.-> T0
  UP -.state, reward.-> T1
  UP -.state, reward.-> T2
  UP -.state, reward.-> T3
  T0 -.action.-> UP
  T1 -.action.-> UP
  T2 -.action.-> UP
  T3 -.action.-> UP
  subgraph MEM["Per-tier memory (AIM-RM only)"]
    M0[(Tier 0 memory)]
    M1[(Tier 1 memory)]
    M2[(Tier 2 memory)]
    M3[(Tier 3 memory)]
  end
  T0 <-.retrieve/store.-> M0
  T1 <-.retrieve/store.-> M1
  T2 <-.retrieve/store.-> M2
  T3 <-.retrieve/store.-> M3
  RL["Optional: IPPO rollout logs"] -.preload.-> MEM

Schematic of AIM-RM's memory lookup at one tier: the current state (star) is compared by Euclidean distance to every stored past case (dots); only the K nearest cases inside the similarity threshold (the circle) get pulled into the prompt as evidence. Illustrative 2D projection built from the paper's mechanism, not real embeddings.

The decision loop, per tier per round

flowchart TD
  A["Observe state s_m,t"] --> B["Embed state<br/>(raw numeric vector)"]
  B --> C["Find K nearest neighbors<br/>in tier memory, Euclidean distance"]
  C --> D{"distance < threshold τ?"}
  D -->|yes, keep| E["Similar cases R"]
  D -->|no, drop| F["Discard"]
  E --> G["Assemble prompt:<br/>P_DM + P_SD + P_SS + P_MU + R + D"]
  G --> H["LLM decision module<br/>(o4-mini / GPT-5)"]
  H --> I["Order quantity O_m,t + reasoning"]
  I --> J["Environment step:<br/>next state, profit P_m,t"]
  J --> K["Write (state, O_m,t, P_m,t)<br/>back into tier memory"]
  K --> A

Demystifying the math

• Safety stock: SS = z·σ̂·√(L_m+1). Plain English: the buffer you carry is bigger when demand is more volatile (σ̂, the forecasted demand std-dev), when the lead time is longer (more rounds of uncertainty to cover), and when you want a higher service level (z, a factor picked from a standard normal table — bigger z = you’re less willing to stock out).
• Target consumption: C̃_{t,m} = (L_m+1)·μ̂ + SS. Plain English: over the time it takes a fresh order to arrive, you’ll consume roughly (L_m+1) periods’ worth of average demand μ̂, plus the safety buffer on top. That’s your order-up-to target.
• Order quantity: the gap between C̃_{t,m} and the scheduled inventory increase Ĩ_{m,t} (what you already have coming, net of backlog). Plain English: order enough to close the gap between “what I’ll need” and “what’s already in the pipeline” — don’t order more than that, and don’t ignore stock that’s already inbound.
• KNN retrieval cost: O(|M|·d + X + K) where |M| is memory size, d the embedding dimension, X the sort cost. Plain English: this is a brute-force linear scan over memory, not an approximate nearest-neighbor index (no FAISS/HNSW). Fine at the scale tested (dozens of stored cases); would need a real ANN index the moment memory grows into the thousands.

The algorithm, simplified

# One tier's AIM-RM decision step. Runs once per tier per round; called
# sequentially tier 0 -> tier M-1 so each tier sees the downstream order first.

def aim_rm_decide(state, tier_memory, demand_desc, llm, K=6, tau=2.0):
    query_vec = embed(state)                     # raw numeric fields, no neural encoder
    scored = sorted(tier_memory,                  # tier_memory: list of (state_vec, order, profit)
                     key=lambda case: euclidean(query_vec, case.state_vec))
    neighbors = scored[:K]
    similar_cases = [c for c in neighbors if euclidean(query_vec, c.state_vec) < tau]
    # similar_cases are "evidence, not rules" -- the prompt says so explicitly

    prompt = build_prompt(
        decision_prompt=state,                    # P_DM: current state + downstream's order this round
        step_description=STEP_DESC,               # P_SD: how a period actually unfolds
        safety_stock_strategy=SAFETY_STOCK_DESC,   # P_SS: textbook order-up-to formula
        memory_usage=MEMORY_USAGE_DESC,            # P_MU: how to read similar_cases
        similar_cases=similar_cases,
        demand_description=demand_desc,            # ground-truth future demand, given up front
    )
    order_qty, reason = llm(prompt)                # o4-mini / GPT-5, some reasoning effort
    return order_qty, reason

def aim_rm_round(env, tiers, tier_memories, demand_desc, llm):
    actions = {}
    for m in tiers:                                # sequential, not simultaneous
        state = env.observe(m)
        order, reason = aim_rm_decide(state, tier_memories[m], demand_desc, llm)
        next_state, profit = env.step(m, order)     # apply the order, get next state + P&L
        tier_memories[m].append((embed(state), order, profit))   # memory grows online
        actions[m] = order
    return actions

Built on Prior Work

Results & Evidence

The headline metric is a relative optimality gap, Δ = |Opt − r| / Opt, computed against a solver-verified optimal reward Opt for each of five scenarios (constant/increasing/decreasing demand × uniform/diverse tier parameters). Lower Δ is better.

What holds up:

• In the single easiest scenario (constant demand, uniform tiers), InvAgent (w/ step desc + safety-stock) hits Δ = 0.00 — the literal optimum, solver-verified via CP-SAT. That’s a real result: no training, one well-specified prompt, exact optimality on a multi-echelon problem.
• Across the harder, time-varying-demand scenarios, AIM-RM (w/ RL log) has the lowest average gap of any non-RL method (91.27 at medium reasoning effort), consistently ranking first among the LLM-based configurations.
• Ablating the RL-log preload (AIM-RM w/o RL log, 138.59) versus keeping it (91.27) shows the memory mechanism is genuinely using the preloaded experience, not just accumulating noise.

What to be skeptical of:

• “Comparable to RL” is generous. IPPO (42.79) and MAPPO (34.04) still beat AIM-RM (w/ RL log)‘s 91.27 by roughly 2–3x on this metric. AIM-RM closes a lot of the gap to trained RL without any training — genuinely useful — but it does not match it.
• The optimal reward itself is sometimes negative (Appendix Table 4: Const-Uni Opt = −120.00, Dec-Uni Opt = −45.00, Inc-Uni Opt = −132.00). Dividing by a small negative number makes Δ swing wildly for small absolute differences in r — the paper doesn’t flag or correct for this, and it makes the cross-scenario “average Δ” comparison noisier than it looks (a gap computed against Opt=−120 and one against Opt=332 aren’t really on the same scale).
• Demand was made deterministic specifically to control LLM API costs — the authors say so directly. Real supply chains face stochastic demand; this paper doesn’t test it, and the deterministic setting also means agents were handed the exact future demand curve, softening the actual decision problem.
• Only 5 episodes per configuration were run (again, cost-driven), and standard deviations were ~0 for nearly every LLM configuration — consistent with low-temperature/near-deterministic decoding rather than genuine robustness.
• “Overthinking” is real but scoped: more reasoning effort (medium → high) hurt performance for the complex-prompt models (both AIM-RM variants, and InvAgent w/ safety-stock), but helped the simpler-prompt InvAgent variants. The effect is prompt-complexity-dependent, not universal — a useful nuance, not a blanket “reasoning models are worse” claim.

Average optimality gap (Δ, lower is better) at medium vs. high reasoning effort, plotted from the paper's Tables 2 and 3. Complex-prompt models (AIM-RM, InvAgent + safety-stock) get worse with more reasoning; the plain step-description InvAgent barely moves. This is the paper's "overthinking" evidence, not a simulation.

One more failure mode is worth calling out on its own, since it explains several of the per-scenario results the averages hide: in the Increasing-Diverse and Increasing-Uniform scenarios, agents that under-ordered early (to save on holding costs) got caught by the rising demand trend, forcing sudden large catch-up orders at the upstream tiers — a textbook bullwhip effect. It shows up worse at high reasoning effort for AIM-RM (the model becomes more aggressive about minimizing inventory, then gets blindsided), and it’s the specific mechanism, not just “reasoning effort is bad,” behind several of the high-effort regressions in the table above.

Illustrative order quantities by tier over a 12-round episode with rising demand: a small, sensible response at the retailer amplifies into large, oscillating orders upstream once a tier under-orders and then over-corrects. Schematic, built to illustrate the mechanism the paper describes — not the paper's literal per-round data.

How You’d Use It

The transferable idea here isn’t inventory management specifically — it’s a pattern: any recurring, state-based decision problem you can express as a vector, where you either have or can cheaply generate a corpus of (state, action, outcome) examples, can get an LLM decision agent “for free” by retrieval instead of by fine-tuning.

• A retrieval-augmented decision layer over any MAS you already run — your harness. If you’re operating a multi-agent system with agents making repeated, similar-shaped decisions — routing, scheduling, pricing, triage — this is a concrete pattern to bolt on: log every (state, action, outcome), embed the state as a feature vector (you often don’t need a learned encoder — raw structured features work, as shown here), and retrieve nearest neighbors as few-shot evidence at decision time. It’s cheaper to build and iterate on than either prompt-tuning-by-hand or standing up an RL training loop.
• “Cold-start with RL logs, then run without RL” as a reusable pattern for your own automations. The w/ RL log variant is the paper’s strongest result and it’s a genuinely reusable trick: if you have any existing simulator or historical decision log — even a rough one — you can run a cheap RL pass or just mine historical outcomes, dump the trajectories into a vector store, and get an LLM agent that inherits a lot of that policy’s quality without training or maintaining a policy network yourself.
• A cheap alternative to full RL when you can’t afford a calibrated simulator. Multi-agent RL needs a simulator faithful enough to trust the learned policy in production — expensive and slow to build for real operations. This pattern needs only a state schema and some source of past outcomes (RL, heuristics, or even human decision logs), which is a much lower bar.
• Where it doesn’t fit: anything requiring hard guarantees (safety-critical control, financial limits) shouldn’t rely on “the LLM was shown similar cases and used its judgment” — there’s no constraint enforcement here, just evidence in a prompt the model is free to ignore (and the paper’s own conclusion admits it sometimes does).

Build Your Own (Minimal Recipe)

You could have a toy version of AIM-RM running in an afternoon; the pieces are unglamorous but well-specified in the paper.

Components, in build order:

1. State schema. Decide the fixed-length numeric vector that describes “a situation” in your domain (here: inventory, backlog, upstream backlog, recent shipments/receipts). This is the single most important design choice — everything downstream depends on this vector being a meaningful basis for similarity.
2. A memory store. A list of (state_vector, action, outcome) per agent/tier is enough at small scale — this paper’s is literally a Python-list-sized brute-force scan; graduate to a real vector DB (Chroma, pgvector, FAISS) only once you need approximate search at scale.
3. Similarity retrieval. Euclidean distance, top-K, threshold cutoff — three lines of numpy. No learned embedding required if your state is already structured/numeric; normalize features first (the paper doesn’t mention normalizing across differently-scaled fields like inventory vs. lead time — worth doing better than they did).
4. The prompt stack. Four prompt fragments, concatenated: (a) current-state decision prompt, (b) a step-by-step explanation of your environment’s mechanics — don’t assume the LLM will infer causality correctly from raw numbers, spell it out, (c) any known-good domain heuristic as explicit instructions (this paper’s biggest “free win”), (d) instructions for how to treat retrieved evidence (“similar cases, not rules”).
5. The decision loop + write-back. Call the LLM, parse its structured output (order quantity + reason), execute the action, append the resulting (state, action, outcome) back into memory. This online growth is what lets the system improve within a single run, even before you add any RL preloading.
6. (Optional, highest-leverage) Bootstrap from any RL/heuristic log you have. Even a rough RL run — you don’t need it to converge fully — gives you a memory seed that’s dramatically better than an empty one.

The 1–2 genuinely hard parts:

• State representation and normalization. Euclidean distance treats every feature as equally scaled; if your state mixes units (units of inventory vs. days of lead time vs. currency), naive Euclidean similarity will be dominated by whichever field happens to have the largest numeric range. The paper doesn’t address this — you should.
• Faithfulness — does the model actually use what you retrieved? The paper’s own conclusion admits AIM-RM “occasionally seems to place an order without considering the input similarity cases,” and cites evidence that reasoning models don’t always report what actually drove their output. If you build this, instrument it: have the model cite which retrieved case(s) it used, and spot-check that citation against its actual decision.

Reach for: a lightweight vector store (Chroma/pgvector for anything beyond a toy), your existing LLM API with structured/JSON output, and — if you want the RL-seed trick — any off-the-shelf single-agent RL library (Stable-Baselines3, RLlib) run just long enough to get plausible rollouts, not to convergence.

How to Improve It

1. Normalize and/or learn the embedding instead of using raw Euclidean distance on raw features. Differently-scaled state fields currently distort similarity. A z-scored feature vector, or a small learned metric (contrastive training: states that led to similar rewards should be “close”), would likely fix a chunk of the retrieval noise for free.
2. Add Reflexion-style critiques to memory entries (the paper’s own suggestion) — store not just the numeric triple but a one-sentence verbal post-mortem (“ordered too much given the incoming lead-time-2 shipment; overshot target by 8 units”). This gives the LLM causal, language-level evidence alongside the numeric evidence, which may be more persuasive and more faithfully used than a raw number.
3. Test faithfulness directly. Force the model to name which retrieved case(s) influenced its order, and measure how often the stated order is actually consistent with that case versus contradicts it. This turns “occasionally seems to ignore the evidence” from a hand-wave into a measured rate — and a target to improve.
4. Move to approximate nearest-neighbor search and stress-test at scale. The current O(|M|·d) linear scan is fine for a few dozen memories per tier; a real deployment accumulating months of decisions needs FAISS/HNSW, and it’s worth checking whether approximate retrieval degrades decision quality.
5. Run it under stochastic demand with a cheap local model — exactly the next step the authors name (gpt-oss-120B instead of paying per-token for o4-mini/GPT-5), which would let them run the many more trials that deterministic demand and cost constraints currently rule out, and would test whether the retrieved-evidence mechanism still helps when the future genuinely isn’t known in advance.

Glossary

• Multi-echelon inventory management — coordinating ordering/inventory decisions across multiple linked supply-chain tiers (retailer → wholesaler → distributor → manufacturer), where each tier’s decision affects the others.
• Lead time — the number of periods between placing an order and receiving it.
• Backlog — demand you couldn’t fulfill this period, carried forward (and usually penalized) until it’s met.
• Safety stock — an extra inventory buffer sized to cover demand uncertainty during the lead time, so you don’t stock out even if demand runs above forecast.
• Base-stock policy — a heuristic: always order enough to bring inventory back up to a fixed target level.
• Bullwhip effect — small demand fluctuations at the retail end get amplified into large, oscillating order swings further up the supply chain — a classic multi-echelon failure mode this paper reproduces when reasoning effort or demand trends push agents into abrupt corrections.
• MDP (Markov decision process) — the standard formalism for sequential decision-making: a state, an action, a transition to a new state, and a reward, repeated over time.
• IPPO / MAPPO — Independent/Multi-Agent Proximal Policy Optimization; reinforcement learning algorithms that train a policy network per agent (IPPO) or with a shared, globally-informed value function (MAPPO) to maximize reward through trial and error.
• CTDE (centralized training, decentralized execution) — an RL training pattern where agents can see global information while training but must act on local information only once deployed.
• Reasoning effort — a parameter on OpenAI’s reasoning models (o4-mini, GPT-5) that controls how many “thinking” tokens the model spends before answering; higher isn’t always better (see “overthinking”).
• Overthinking — the documented phenomenon where letting a reasoning model “think” more actually degrades task performance past a certain point, rather than improving it.
• Vector database / similarity search — a store of vectors (here, raw numeric state vectors) queried by nearest-neighbor distance to retrieve the most similar past entries.
• Euclidean distance / K-nearest-neighbors (KNN) — the straight-line distance between two vectors; KNN retrieval returns the K stored vectors closest to a query vector.
• Relative optimality gap (Δ) — this paper’s evaluation metric: how far a policy’s total reward falls from the solver-computed optimal reward, as a proportion of that optimum.
• AIM-RM — this paper’s proposed agent: an LLM decision-maker augmented with per-tier retrievable memory of past (state, order, profit) experience, optionally seeded from RL rollout logs.