Agentic LLMs in the Supply Chain: Towards Autonomous Multi-Agent Consensus-Seeking

TL;DR

Running a supply chain well means constantly agreeing on numbers — how much to order, when, how much to hold in reserve — between companies that don’t fully trust or see each other. Classical software agents and reinforcement learning both tried to automate this and both stalled: software agents needed too much bespoke engineering for small companies to afford, and RL needs mountains of interaction data before it’s any good (“cold start”). This paper asks whether pre-trained LLMs, which need neither, can step in instead. The authors build five increasingly sophisticated LLM “consensus-seeking” frameworks — from a lone agent guessing its own order quantity, up to two neighboring agents literally negotiating a number back and forth for three rounds, anchored by a real forecasting tool at each end. Tested on a 3-tier inventory simulation with two Gemini model sizes, the headline result is that letting neighboring agents talk to each other, especially negotiate, beats both a naive LLM and a classic textbook formula (EOQ) used on its own — cutting the bullwhip effect below the danger threshold and, in the best configuration, out-costing even the hard mathematical baseline. The catch: performance is fragile to prompt wording, doesn’t reliably improve with a bigger model, and still needs a human supply-chain expert hand-tuning the prompts — this is a promising proof of concept, not a drop-in autonomous system yet.

Problem & Motivation

Supply chains are made of separate, self-interested companies that nonetheless have to agree on shared numbers constantly: how much the retailer will order this week, how much the factory should produce, how much buffer stock to hold. When that agreement doesn’t happen well, you get the classic bullwhip effect — a small wobble in real customer demand turns into wild order swings as it propagates upstream, because each company overreacts to what its immediate neighbor tells it. Fixing this at scale requires end-to-end coordination, but end-to-end coordination is expensive: it eats staff time, and every company along the chain has to want to participate.

Two automation paths were tried before and both hit a wall:

1. Classical software agents (2000s-era multi-agent systems for SCM) required curated data, bespoke communication protocols, and skilled engineers to build and maintain. Small and medium enterprises — who make up most of the links in any real chain — simply can’t afford that, so these systems stayed academic.
2. Multi-agent reinforcement learning (MARL) promised to learn coordination policies directly, but suffers the cold-start problem: an RL agent starts knowing nothing and needs a huge number of trial-and-error interactions with the environment before it’s useful. Real companies don’t have spare inventory to burn on an agent’s early, bad decisions. MARL is also hurt by partial observability (each firm only sees its own patch of the chain) and by supply chains being neither fully cooperative nor fully competitive — most MAS research assumes one or the other.

Pre-trained LLMs sidestep both problems: they already “know” things from training (no cold start), they take natural-language input so two companies don’t need matching software (no interoperability tax), and they’re accessible via an API rather than a bespoke build. The open question this paper tackles: nobody had built or tested an LLM framework that respects the actual structure of a supply chain — sequential tiers, partial observability, neighbor-only communication — for a real coordination task. Prior LLM-agent testbeds were either general marketplaces (no tiered structure) or single-agent inventory management with no negotiation between firms at all.

What’s New (Core Contribution)

This is a systems/empirical paper — the novelty is a family of communication architectures plus the ablation study that ranks them, not a new model or training method.

• A ladder of five consensus-seeking frameworks, from silent to negotiating. Before: prior LLM-for-inventory work (Quan & Liu 2024) used a lone LLM agent per node with no communication with neighbors at all. Now: the paper defines and tests, in order of sophistication: (a) standalone LLM, (b) standalone LLM + a numeric tool, (c) LLM with information sharing from its upstream neighbor, (d) information sharing + tool, and (e) full negotiation between neighbors, bounded by both agents’ tool outputs. Each step isolates one variable (does communication help? does the tool help? does negotiating on top of both help further?).

• Negotiation as a bounded range, not free-form haggling. Before: “negotiation” in LLM-agent research is usually open-ended dialogue with no guardrail on the outcome. Now: each agent first computes its own EOQ (Economic Order Quantity) tool output; the two values become the lower/upper bounds of a negotiation interval. Agents then get 3 rounds to argue their way to a number inside that interval, and must commit to a final number at the end. This grounds the LLM’s free-text negotiation in a real operations-research quantity, so the conversation can’t wander off to nonsense values.

• A partial-observability-respecting, problem-agnostic implementation on LangGraph. Before: multi-agent SC frameworks in the literature are typically one-off, use-case-specific code. Now: the framework dynamically builds a graph of nodes/edges for a chain of any length, restricts each agent to talking only to its immediate upstream/downstream neighbor (mirroring how real firms actually interact — see Marty & Ruel 2024), and swaps between optimizing cost or the bullwhip effect just by changing the prompt, not the graph logic.

• A controlled 24-experiment ablation across model size, metric, and framework. Before: claims about LLM agents in SCM were mostly demonstrations, not controlled comparisons. Now: every framework × two metrics (cost, bullwhip) × two model sizes (Gemini 1.5 Flash, Gemini 1.5 Pro) is run against the same simulated demand stream and the same two baselines (a naive (s,S) restocking policy, and the raw tool output used directly with no LLM at all). This isolates whether gains come from the tool, the communication, or the model size.

Be honest about what’s not new: LangGraph orchestration, EOQ, and the bullwhip coefficient-of-variation metric are all off-the-shelf. The genuine contribution is the specific shape of the communication ladder — especially the bounded negotiation design — and the empirical result that negotiation, not model size, is the lever that moves performance.

How It Works (Technically)

Everything sits on top of an existing multi-tier inventory simulator (Liu et al. 2022): a sequential chain of 3 agents (think retailer → wholesaler → manufacturer), each with its own inventory, backlog, and a 2-step lead time between placing an order and receiving stock. Customer demand at the bottom of the chain follows a Merton jump-diffusion process (mostly smooth, with occasional demand spikes) — realistic enough to trigger a bullwhip effect if agents coordinate badly.

The building blocks common to every agent, every framework:

• Perceive — read the environment: current inventory, backlog, last order placed, incoming shipments, and the demand just seen from the downstream neighbor.
• Memory — a rolling window of the last 10 steps’ inventory/backlog/order history, stuffed into the prompt as in-context examples (no fine-tuning, no vector database — just plain text in the prompt).
• Decide — the LLM is given a natural-language description of the problem, the objective (minimize cost, or minimize the bullwhip-effect metric), its observation, and its memory, and asked to output a single order quantity.
• Execute — that number is applied to the simulator, which advances one time step.

The five frameworks are what changes between “Decide” and “Execute”:

Two tools are used, one per metric being optimized:

• Demand-forecasting tool (for the cost metric): plain linear regression over the last 30 periods of observed demand, predicting the next order quantity. Early in the simulation, when there isn’t 30 periods of history yet, it just falls back to the last observed order.
• EOQ tool (for the bullwhip metric): the classic Economic Order Quantity formula, computed per agent from its own recent demand history.

Architecture & data flow

flowchart TD
  ENV[("Environment<br/>inventory / backlog / demand")] --> PER["Perceive<br/>read own local state"]
  PER --> MEM["Memory<br/>last 10 steps as in-context examples"]
  MEM --> TOOL{"Tool available?"}
  TOOL -->|no| TENT["Tentative decision<br/>(LLM, own view only)"]
  TOOL -->|yes: forecast or EOQ| TENT
  TENT --> COMM{"Communication stage?"}
  COMM -->|none: standalone| FINAL["Final decision"]
  COMM -->|info sharing| SHARE["Receive upstream neighbor's<br/>observation, re-decide"]
  COMM -->|negotiation| NEG["Negotiate 3 rounds<br/>bounded by both agents' tool outputs"]
  SHARE --> FINAL
  NEG --> FINAL
  FINAL --> EXEC["Execute order on environment"]
  EXEC --> ENV

The five frameworks from the paper’s Fig. 3 are just different paths through this one diagram: (a) skips the tool and communication branches, (b) takes the tool branch only, (c)/(d) take the “info sharing” branch (with or without tool), (e) always takes both the tool branch and the “negotiation” branch.

A schematic replay of the negotiation stage: two neighboring agents each start from their own EOQ tool output (the dashed lines), then trade proposals for 3 rounds inside the bounded interval between them, converging on a final agreed order. Illustrative, built from the paper's described mechanism, not raw experiment data.

Trace one real interaction (bullwhip-mitigation, negotiation framework, wholesaler ↔ manufacturer):

1. The wholesaler (downstream in this pair) computes its EOQ tool output from its own recent demand history — say 42 units.
2. The manufacturer (upstream) computes its own EOQ from what it’s seen — say 68 units.
3. The wholesaler opens the conversation (the paper finds the downstream agent, by convention, initiates and tends to behave “stubbornly,” i.e. anchors hard near its own number), proposing something close to 42 and explaining why (recent demand has been flat).
4. The manufacturer responds — the paper observes upstream agents tend to be “suggestible,” moving further toward the downstream number than vice versa — proposing a value inside [42, 68].
5. This repeats for up to 3 rounds; most commonly, without explicit instructions, both agents converge toward something close to the average of the two starting points, though occasionally one side holds firm or they fail to agree.
6. Both agents commit to a final number, which becomes each side’s actual order for that step.

Why this specific design helps: without negotiation, each tool operates in isolation, so an upstream agent’s EOQ might reflect stale or noisy downstream demand and overcorrect — the classic bullwhip mechanism. Making the two agents literally talk through the gap between their two forecasts is a natural-language version of the textbook fix for the bullwhip effect: share information and agree on order amounts (Wang & Disney 2016; Dejonckheere et al. 2004).

Demystifying the math

There are two formulas doing real work here, both simple ratios — no gradients, no probability theory.

• Bullwhip coefficient of variation, per agent i: $$\text{coeffvar}_i = \frac{\sigma(\text{demand}_i)}{\mu(\text{demand}_i)}$$ Plain English: take the agent’s stream of past order quantities, divide their standard deviation (how jumpy they are) by their mean (how big they typically are). A value below 1 means orders are relatively stable versus their average size — no bullwhip. Above 1 means the agent’s orders are swinging wildly relative to typical demand — the bullwhip effect is present. The aggregate bullwhip effect for the whole chain is the product of every echelon’s coefficient — one jumpy agent anywhere in the chain drags the whole product up.

• Economic Order Quantity (EOQ), the tool computation and negotiation anchor: $$EOQ = \sqrt{\frac{2 \times \text{Demand} \times \text{Ordering Cost}}{\text{Holding Cost}}}$$ Plain English: this is the textbook “sweet spot” order size that balances two competing costs — order too often and you pay ordering fees every time; order too rarely (in big batches) and you pay to hold excess inventory. The square root shape means doubling demand doesn’t double the ideal order size — it only grows by about 41% (√2), because bigger batches amortize the fixed ordering cost across more units. Each agent computes its own EOQ from its own recent demand; the paper’s insight is that when neighboring agents’ EOQs disagree, negotiating the gap between them (rather than each blindly using their own) is what actually suppresses the bullwhip effect.

• Total cost, the other optimization objective, is just a sum: inventory holding cost + backlog (unmet demand) cost + variable ordering cost + fixed ordering cost, all summed per agent per step and then across every agent and every step. No formula demystification needed here — it’s literally an accounting sum, but it’s worth noting that this metric is what the demand-forecasting linear-regression tool targets, while EOQ targets the bullwhip metric — the two tools are metric-specific, not interchangeable.

The algorithm, simplified

The heart of the paper — reduced to the loop that actually differs between frameworks — is the negotiation stage. Everything else (perceive/memory/execute) is bookkeeping around this:

# One round-trip negotiation between two neighboring agents (framework "e").
# tool_low/tool_high are each agent's own EOQ (or forecast) output — the "anchors".

def negotiate(agent_down, agent_up, obs_down, obs_up, rounds=3):
    anchor_down = tool_output(agent_down, obs_down)   # e.g. EOQ from own demand history
    anchor_up = tool_output(agent_up, obs_up)
    lo, hi = min(anchor_down, anchor_up), max(anchor_down, anchor_up)

    proposal = anchor_down          # downstream typically opens, anchored on its own number
    transcript = []
    for r in range(rounds):
        # each side reasons in natural language, but must land inside [lo, hi]
        counter = llm_propose(agent_up, obs_up, proposal, transcript, bounds=(lo, hi))
        transcript.append((agent_up.name, counter))
        proposal = llm_propose(agent_down, obs_down, counter, transcript, bounds=(lo, hi))
        transcript.append((agent_down.name, proposal))

    final_down = llm_commit(agent_down, transcript, bounds=(lo, hi))
    final_up = llm_commit(agent_up, transcript, bounds=(lo, hi))
    return final_down, final_up      # each agent executes its own committed number

Note what’s not here: no shared objective function, no arbiter, no guarantee of exact agreement — final_down and final_up can differ if the agents don’t converge. That’s a deliberate design choice reflecting real self-interested firms, not a bug: the paper explicitly studies how “stubborn” vs “suggestible” behavior emerges from this loop rather than enforcing consensus.

Built on Prior Work

The honest read: almost every individual ingredient (LangGraph, EOQ, linear regression, the bullwhip coefficient) is borrowed wholesale from operations research or off-the-shelf tooling. What’s genuinely new is the combination — wiring these into a graded ladder of LLM communication frameworks and empirically showing which rung of the ladder actually earns its complexity.

Results & Evidence

24 experiments: 2 metrics (global cost, global bullwhip effect) × 2 models (Gemini 1.5 Flash, Gemini 1.5 Pro) × up to 5 frameworks each, all against the same simulated demand stream, at low temperature (0.1, near-deterministic).

Cost minimization (Gemini Flash):

• Adding the tool to a standalone agent: 63.5% cost reduction.
• Info sharing vs. standalone (no tool): 92.8% cost reduction.
• Adding the tool to info-sharing agents: 67.9% further reduction.
• Adding negotiation on top of info-sharing + tool: 50.7% further reduction.
• Only the plain standalone-no-tool agent underperformed the weak (s,S) baseline; everything else beat it.

Each bar is the reported percentage reduction from adding one more rung of sophistication (Gemini Flash, cost metric). Communication (info sharing) is the single biggest jump — bigger than adding the tool either time. Built directly from the paper's reported percentages, not a re-run of the experiment.

Bullwhip minimization: Standalone agents, even with the EOQ tool, did not reliably bring the bullwhip coefficient below the safe threshold of 1 — in fact, for Gemini Flash, adding the tool to a standalone agent made the bullwhip effect worse. Communication is what fixed it: information sharing, information sharing + tool, and negotiation all pushed the metric below 1 for both models. Negotiation was the best performer, beating “info sharing + tool” by 66.2% (Gemini Pro) and 33.2% (Gemini Flash).

Model size didn’t reliably help. Gemini Pro (larger) did not consistently outperform Gemini Flash (smaller) — sometimes it did worse. The authors’ own explanation: prompts were manually optimized against the smaller model, and the larger model is known from other research to behave non-monotonically with prompt changes. This is a genuinely important negative result for anyone assuming “bigger model = better agent.”

What the evidence does establish: communication (sharing information, and especially negotiating) is a bigger performance lever than either raw model size or a standalone tool; negotiation can beat even the strong mathematical baseline (raw EOQ/forecast used directly) in several configurations — a case where LLM orchestration outperforms the pure formula it’s built around.

What it does NOT establish, and the authors are candid about this:

• Only a 3-agent chain, one demand-generation process (Merton jump diffusion), one lead time (2 steps) — no test of longer chains, branching networks, or different demand regimes.
• Near-deterministic temperature (0.1) means the reported numbers are close to single runs, not averaged over many stochastic rollouts — no confidence intervals or statistical significance testing in the main results.
• Prompts were hand-tuned manually and admittedly not optimized per model — the Pro results in particular may understate what a properly-tuned larger model could do.
• No test against non-Gemini model families (GPT, Claude, Llama) — unclear how much of this generalizes across providers.
• No real company or live data involved anywhere; this is entirely a simulation.
• The paper is explicit that human-in-the-loop oversight is still required — outputs aren’t yet reliable or explainable enough for autonomous production use.

How You’d Use It

This maps less to “ship the exact framework” and more to a reusable pattern for any bilateral, repeated, numeric negotiation between two automatable parties:

• The negotiation-bounded-by-a-tool pattern is the reusable idea. Wherever two sides need to agree on a number and each side has (or can compute) its own reasonable estimate — SLA credits, capacity allocation between departments, discount negotiation with a supplier, staffing levels between two teams — you can reuse exactly this shape: compute both sides’ anchor with a real formula/model, then let two LLM agents negotiate inside that bounded range instead of hallucinating a number from scratch. The bound is what keeps this production-safe; free-form LLM negotiation without it is much riskier.
• A concrete application: an “inventory consensus copilot.” For an SMB manufacturer or distributor already running an ERP, this framework could sit as a lightweight layer that proposes order quantities to a counterpart company (or to a human buyer) and explains its reasoning in natural language — no EDI integration or shared data schema required, since it’s all natural-language I/O. That directly addresses the “interoperability barrier” the paper identifies as the historical blocker for supply-chain automation.
• LangGraph is the right tool for the orchestration, confirmed by this paper’s own choice — if you’ve built agent graphs before, this maps cleanly: perceive/memory/decide nodes, a conditional edge into a communication subgraph, and a fan-in to a final-decision node. The “dynamically build the graph for a chain of any length” detail is worth stealing directly — don’t hand-wire N agents’ edges.
• Steal the ablation methodology, not just the framework. The paper’s biggest practical lesson: test whether communication or tooling is the actual lever before reaching for a bigger/more expensive model. This is a cheap, valuable diagnostic to run on your own stack before deciding “should we use GPT-4 instead of a smaller model” — the answer here was no, the framework mattered more.

Build Your Own (Minimal Recipe)

You can reproduce the shape of this (not the exact simulation) in a few days.

Components, in build order:

1. A toy 3-node inventory simulator. Even a 50-line numpy script: each node has inventory, backlog, a lead time, and a cost function (holding + backlog + ordering costs). Feed it a demand stream with occasional spikes (a Poisson jump process is enough — you don’t need exact Merton jump-diffusion).
2. A single-agent decision node. One LLM call per agent per step: prompt = problem description + objective + current observation + last-10-steps memory → parse a single number back. Get output parsing solid first (constrained/JSON output, or retry-on-malformed-output at low temperature) — this is more fiddly than it sounds and is exactly why the paper runs at temperature 0.1.
3. One tool. Pick the cost metric and implement linear regression over the last 30 demand observations (sklearn.linear_model.LinearRegression in five lines) — this alone gets you most of the framework-vs-baseline gap the paper reports.
4. Information sharing. Before the decide step, fetch the upstream neighbor’s last observation and append it to the prompt. This is a LangGraph edge, not new logic.
5. The negotiation loop. The negotiate() shape above: compute both agents’ tool outputs as bounds, run a fixed number of LLM↔LLM turns (a sequenceDiagram-shaped exchange), each turn constrained to propose a number inside the bound, then force a commit.
6. Metrics + logging. Compute total cost and the coefficient-of-variation bullwhip metric per run so you can actually ablate frameworks against each other, the way the paper’s Table 1/2 do.

The 1–2 genuinely hard parts:

• Getting the LLM to actually weight the tool output, rather than ignoring it or overriding it with a “gut feeling” number. The paper solves this with blunt prompt directives (“give strong weight to the tool output”) — expect to iterate on this by hand; it’s brittle and model-specific, exactly as the paper reports.
• Negotiation convergence. With no arbiter, two LLM agents can simply fail to converge, or one can be pathologically “stubborn.” Decide up front what you do on non-convergence (average the two final numbers? re-run one more round? fall back to the tool value?) — the paper doesn’t force convergence, and neither should you pretend it always happens.

Reach for: LangGraph (proven fit for this), any tool-calling-capable LLM API (Gemini, Claude, GPT), scikit-learn for the forecasting tool, and a simple numpy-based simulator rather than trying to reproduce Liu et al. (2022) exactly.

How to Improve It

The authors’ own Limitations section hands you a punch list; here’s how to make each one concrete and testable:

1. Automate the prompt engineering. The paper’s biggest admitted weakness is that all results depend on manually-tuned, per-model-fragile prompts. Swap in an automatic prompt optimizer (the paper names DSPy/Khattab et al. 2023) and measure whether the Gemini Pro results stop underperforming Flash once prompts are optimized for Pro specifically — that would directly test their “we only tuned for the smaller model” explanation.
2. Add long-term conversational memory. Currently negotiation memory resets every simulation step; observation memory only covers the last 10 steps. Give agents a persistent log of past negotiation outcomes with each specific neighbor (not just past observations) and test whether repeated interactions build better-calibrated trust/anchoring over time — a natural-language analog of repeated-game learning.
3. Add chain-of-thought reasoning and self-reflection. The paper explicitly flags this as unexplored: have each agent reason step-by-step before committing to a number, and/or reflect on whether last round’s decision was good before the next one. Cheap to test, directly addresses the “unexplainable outputs” limitation.
4. Test multi-objective negotiation. Right now cost and bullwhip are optimized in separate experiments. Real firms trade off cost against emissions, lead time, or resilience simultaneously — extend the negotiation bound to a small Pareto frontier (both agents’ tool outputs become vectors, not scalars) and see whether the negotiation dialogue can reason about trade-offs rather than just a single number.
5. Stress-test uncooperative/adversarial agents. The paper only studies well-intentioned agents; a genuinely useful extension is to seed one agent with an incentive to game the negotiation (e.g., always lowball) and measure how badly it breaks the framework — this is exactly the robustness question a real deployment would need answered before trusting the pattern with real money.

Glossary

• Supply chain management (SCM) — coordinating the flow of goods and information across companies from raw material to end customer.
• Consensus-seeking — a process where multiple parties with different goals interact to agree on one decision (e.g., an order quantity) they all accept.
• Bullwhip effect — small fluctuations in real customer demand get amplified into large order swings as you move upstream through a supply chain, because each company overreacts to the signal from its neighbor.
• Echelon / tier — one link (one company or stage) in a sequential supply chain.
• Partial observability — each agent only sees its own local slice of the system (its own inventory, its immediate neighbor’s data), never the whole chain at once.
• Multi-agent system (MAS) — multiple interacting software agents, each with its own goals, operating in a shared environment.
• Multi-agent reinforcement learning (MARL) — agents that learn coordination policies through trial-and-error reward signals rather than being pre-trained; suffers from the cold-start problem in data-scarce settings like SCM.
• Cold-start problem — an RL agent starts with no useful knowledge and needs many real interactions before it performs well, which is costly or risky in a live supply chain.
• LLM agent — a large language model wrapped with perception (reading data), memory, and the ability to take actions or use tools, rather than just answering a chat prompt.
• Tool usage / tool calling — giving an LLM access to an external function (here: a regression model or a formula) whose output gets folded into the prompt to ground the LLM’s decision in real computation.
• Zero-shot prompting — asking the LLM to perform a task directly from its pre-trained knowledge, with no worked examples given in the prompt.
• Economic Order Quantity (EOQ) — a classic operations-research formula giving the order size that minimizes the combined cost of ordering too often versus holding too much inventory.
• Coefficient of variation — standard deviation divided by the mean; used here as the bullwhip-effect metric (below 1 = stable, above 1 = the bullwhip effect is present).
• (s, S) restocking policy — a simple traditional rule: reorder up to level S whenever inventory falls below threshold s.
• LangGraph — a graph-based orchestration framework (built on LangChain) for wiring together multi-step, multi-agent LLM workflows as nodes and edges.
• Temperature — a sampling parameter controlling LLM output randomness; near 0 gives near-deterministic, repeatable outputs.
• Negotiation range/bound — in this paper, the interval between two agents’ own tool-computed values, inside which their negotiated agreement must fall.