Multi-Agent LLM System for Logistics Planning Optimization

amazon_logistics · E-commerce · 2023 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Last-mile logistics planning

Amazon Logistics needed planners to reason over millions of delivery-planning parameters and causal relationships affecting promised delivery dates without relying on slow Excel-based deep dives.

Constraints:

• The EU example involved 119-day plans, multiple cycles per day, over 100 metrics, 249 stations, and 10 countries.
• Human planners relied on tribal knowledge that was hard for new planners to acquire.
• Causal relationships between parameters mattered more than simple correlations.
• Missed promises and churn could create large financial losses.

Architecture

Amazon Logistics built a LangChain custom-agent and AWS Bedrock plan-evaluation engine using Claude 3.7. The system uses the LACQUER algorithm to derive causal graphs from parameter heat maps, combines those graphs with weighted formulas based on planner tribal knowledge, and lets planners ask conversational questions about planning bottlenecks and optimization options.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  planning-data-store["Planning Data Store"]
  lacquer-causal-graph-generator["LACQUER Causal Graph Generator"]
  plan-evaluation-agents["Plan Evaluation Agents"]
  planner-conversational-interface["Planner Conversational Interface"]
  planning-data-store --> lacquer-causal-graph-generator
  lacquer-causal-graph-generator --> plan-evaluation-agents
  plan-evaluation-agents --> planner-conversational-interface
  planner-conversational-interface --> plan-evaluation-agents

Components

Data flow

Planning data and heat maps feed the LACQUER algorithm, which generates causal graphs across parameters. LangChain agents and Claude 3.7 use those graphs plus weighted formulas from planner expertise to evaluate plans, explain dependencies, and help planners optimize delivery routes conversationally.

Why this architecture

The architecture combines causal graph generation with LLM-based conversation because the core challenge is explaining dependencies across large planning matrices, not simply producing a plan. Tribal knowledge becomes weighted formulas, while agents make the analysis accessible to planners.

Models used: Claude 3.7 · AWS Bedrock models

Scale

• The planning process involved more than 10 million data points annually.
  “Amazon Logistics faced challenges managing 10+ million data points annually for delivery planning”summary, stated
• The EU example produced approximately 15 million numbers to analyze.
  “With 249 stations across 10 EU countries, planners face approximately 15 million numbers to analyze and make sense of.”summary, stated
• The opportunity was framed as up to 150 million dollars in avoided losses.
  “potentially saving up to $150 million in losses from customer churn and missed delivery promises.”summary, stated

Alternatives considered (roads not taken)

Continue offline Excel-based planning templates

Rejected because: The approach was slow, error-prone, and depended heavily on experienced planners.

Analyze correlations without causal structure

Rejected because: Planners needed to know which parameters were causally related versus merely associated.

Patterns

multi-agent-orchestration (architecture)

Custom agents collaborate around planning evaluation, causal graph interpretation, and conversational analysis.

tool-use-orchestration (execution)

The system uses LACQUER causal-graph tooling and weighted formulas inside the planning workflow.

Tradeoffs

Use causal graphs plus LLM interaction

Chose LACQUER-generated causal graphs with conversational agents over Manual spreadsheet deep dives.

Rationale: The system needed to explain dependencies and bottlenecks at a scale humans could not inspect manually.

Encode tribal knowledge as formulas

Chose Weighted formulas based on planner expertise over Leaving all dependency interpretation to the LLM.

Rationale: Causal interpretation had domain-specific operational knowledge that the model alone should not invent.

Gotchas (what bit them)

Spreadsheet-based planning did not scale to the data volume.

Root cause: Planners had to analyze millions of numbers across stations, cycles, days, and metrics.

Resolution: The system exposed causal graph analysis through conversational agents.

Planner expertise was trapped as tribal knowledge.

Root cause: New planners needed months of experience to understand nuanced delivery optimization factors.

Resolution: The system encoded weighted formulas based on tribal knowledge and surfaced them through agents.

Evaluation

The case reports scale and business-risk framing; it does not provide a formal benchmark in the visible summary.

Metrics: 10+ million annual data points · approximately 15 million EU planning numbers · up to $150 million potential savings

Outcomes

• Planners gained conversational access to complex planning data.
• The system converted heat maps and tribal knowledge into causal graph analysis.
• The business case targets avoided churn and missed-promises losses.

The source cites 10+ million data points annually and about 15 million numbers in an EU planning example.