Graph RAG — Seeing the Hidden Connections in Your Warehouse

In our last article, we gave our AI agents a "library card" with Retrieval-Augmented Generation (RAG). We grounded them in the reality of your SOPs, contracts, and playbooks — turning them from generic assistants into knowledgeable specialists who cite your facts. This was a massive leap.

But in my 20+ years on the warehouse floor, I learned the costliest mistakes rarely come from a single missing fact. They come from a missed connection. The problem isn't just knowing a component is out of stock — it's knowing the ten customer orders, three kits, two carrier rules, and one dock constraint that depend on it, and what happens when you change any one of them.

Standard RAG finds the right page in the playbook. Graph RAG draws the map that connects every page. This is where we evolve from a knowledgeable assistant to a wise advisor — one that sees the system, not just the parts.

From a Library Card to a Map of Your Warehouse

Let's extend our analogy. If RAG gives an agent a library card to look up information in a specific book, Graph RAG gives it the institutional knowledge of a 30-year veteran. Someone who doesn't just know where to find the carrier contracts, but knows that the rules in that contract are linked to the packaging requirements in the customer SOP, which in turn depend on the dimensions in the item master. They see the invisible threads connecting everything.

That's what a Knowledge Graph does. It maps your business as a network of entities — called nodes — and their relationships — called edges.

Nodes are things like a specific SKU, a shipment, a kit, a dock, a customer, or a carrier. Edges are the relationships between them: "is part of," "is supplied by," "requires," "substituted by," "routed via," "affects."

Here's the key distinction between RAG and Graph RAG:

• RAG is best for finding a precise answer inside a document — for example, "What are Customer X's labeling rules for frozen foods?"
• Graph RAG is best for tracing dependencies across entities — for example, "If this SKU is short, which orders, kits, shipments, docks, and costs are impacted in the next four hours?"
• RAG retrieves document passages and reveals facts. Graph RAG retrieves connected paths plus document passages and reveals ripple effects.

The Late Shipment Scenario: Graph RAG Prevents the Cascade Failure

Let's revisit our Late Shipment Alert for Shipment S-123. The inventory for SKU #ABC-123 is short.

In Article 6, our RAG-enabled agent did a great job. It consulted the customer SOP, found an approved substitute, and recommended the swap. The shipment was saved. Or was it?

A seasoned operations manager knows a simple substitution can trigger a cascade of downstream problems. Now let's give that same agent Graph RAG capabilities. When the alert triggers, the agent follows a hybrid retrieval pattern — live APIs first for facts, graph second for impacts, documents third for policies.

First it confirms live inventory via the WMS API. Then it queries the Knowledge Graph: "Show me all first and second degree relationships for this SKU, the substitute, and Shipment S-123."

The graph instantly reveals a critical chain of connections that a document search would miss:

• The original SKU is a component in a kit that is also on Shipment S-123.
• The substitute SKU has a different weight — two pounds heavier — which pushes the total shipment weight over the carrier's cost tier limit, triggering a freight re-rate.
• The shortfall is due to a delay from a supplier whose inbound truck also impacts two other shipments sharing the same dock window.

Armed with this context, the agent then performs a precise document retrieval — pulling the specific carrier contract clause on weight limits and the customer SOP for kit packaging.

The result is a recommendation with two clear paths: cross-dock the original SKU from the inbound truck if it arrives within the window, or execute the substitution with the cost delta already calculated and the Finance Agent already notified for approval. It also flags the two other shipments at risk from the same supplier delay.

The RAG agent prevented a stock-out. The Graph RAG agent prevented a stock-out, a carrier billing dispute, and a multi-shipment dock pile-up — all in one pass.

How to Build Your First Warehouse Graph RAG System

This sounds complex, but the approach is the same as everything in this series: start small and prove value.

Model One Critical Relationship First

Don't try to model your whole business. Start by mapping the relationships that cause the most pain when they break. A good starting set of entities is SKU, order, shipment, dock door, carrier, customer, kit, and supplier. Begin with just three or four key relationships:

• Shipment includes order includes SKU — this traces what's at risk when a SKU is short.
• SKU is supplied by vendor — this identifies upstream root cause.
• SKU is substituted by another SKU — this enables automated fallback plans.
• Shipment is routed via carrier and dock — this reveals scheduling and cost impacts.

Every edge in the graph needs metadata: which site and client it belongs to (for access controls), which source document or system it came from, its version, and a time-to-live (TTL). Dock assignments and ETAs go stale in minutes. SLAs and contracts are valid for months. Tag accordingly.

Where does this data come from? WMS and TMS exports for operational edges like orders to shipments and picks to orders. Master data for structural edges like customer SLA and SKU to kit relationships. SOPs and contracts for policy edges like approved substitutions and cutoff rules. For that last category — use an LLM to propose relationships, but require human approval before merging them into the graph. A hallucinated "approved substitution" that isn't actually approved could be catastrophic.

Implement Hybrid Retrieval

This is the most critical architectural decision. Your agent must use the right tool for the right question:

• Use APIs for live facts — current inventory, pick status, dock schedules, ETAs. Never embed volatile operational data in a graph. Call the WMS API for the real-time number.
• Use the graph for relationships — which orders are affected by that inventory level? Which shipments share that dock? Query the graph to understand the ripple.
• Use RAG for unstructured context — the specific policy clause, the carrier contract term, the SOP step.

This pattern — API first, graph second, docs third — keeps your agent grounded in operational reality while giving it the power to reason over connections.

Build with Guardrails from Day One

Every answer must cite the graph path it traversed along with the source document, version, and validity dates. This makes the reasoning transparent and auditable — essential in multi-client environments. Assign TTLs to volatile edges so they automatically expire, and use event streams to refresh them on picks, putaways, dock changes, and ETA updates. And just like in RAG, enforce site and client partitions at the graph layer. An agent helping Site A must never traverse into Site B's data. Test for leakage paths explicitly.

Fitting Graph RAG into Your Agent Stack via MCP

Graph RAG isn't a standalone system — it's a new set of tools your agents use, registered in the MCP Server from Part 5:

The Alert Agent detects a late-shipment risk and posts the event to the MCP Server. The Orchestrator routes it to a Reasoning Agent. The Reasoning Agent calls a "retrieve facts" tool via MCP to get live status from the WMS and TMS. Then it calls a "retrieve subgraph" tool via MCP to traverse the knowledge graph and discover impacted orders, kits, docks, and carriers. Then it calls a "retrieve docs" tool to pull relevant SOP clauses and contract terms for the entities on the path. The Reasoning Agent synthesises a plan and passes it to the Action Agent. The Action Agent executes — cancel picks, update the bill of lading, notify finance, flag related shipments — all via MCP-registered tools. The Governance Layer logs the full path: what was anchored, what was traversed, what action was taken, what the confidence was, and who approved.

Two Pilot Playbooks to Prove Value Fast

Pilot 1 — Inventory Shortfall Ripple Analysis

Trigger: A pick is short or a lot is quarantined. The agent anchors real-time status via APIs, expands to affected orders, shipments, kits, and docks via the graph, then retrieves substitution rules, carrier terms, and labeling requirements from documents. It delivers a plan with cutoffs and cost impacts. Measure MTTR for late-shipment exceptions and on-time dispatch rate.

Pilot 2 — Recall and Hold Propagation

Trigger: A vendor recall or QA hold for a specific lot. The graph traces all affected inventory across locations, open picks, wave allocations, and staged shipments. The agent pauses affected picks and manifests, notifies customers per their SLA, and generates relabeling or rework tasks if required. Measure time to full containment — this is where the value is undeniable. I've seen recall scenarios where it took a team days of spreadsheet work to trace a single lot through a warehouse. With Graph RAG, that trace happens in seconds.

Your 30-60-90 Day Rollout Plan

Days 1 to 30 — Minimal Graph, One Site

Build your first ontology with 8 to 10 entity types and 3 to 4 relationships. Ingest nightly WMS and TMS snapshots to build the core graph, and parse two SOPs and one carrier contract into edges — with human approval on every policy-derived edge. Expose a "retrieve subgraph" tool via MCP and wire it into your Late Shipment agent in shadow mode, where recommendations go to a human supervisor for validation before any action is taken. Your baseline metric: how long does it currently take to perform a manual impact analysis? That's what you're replacing.

Days 31 to 60 — Real-Time Edges and Guardrails

Add event-driven updates for picks, putaways, dock assignments, and ETA changes. Enforce TTLs, access control partitions, and confidence thresholds. Pilot the recall and hold propagation use case. Stand up a graph quality dashboard that tracks stale edges, orphan nodes, and conflicting rules. Measure first-contact resolution rate and reduction in time planners spend searching for related documents during an exception.

Days 61 to 90 — Productionise and Expand

Cache commonly accessed subgraphs — for example your top customer's rules, or your busiest dock's network — to keep retrieval fast. Formalize governance: assign an ontology owner, set a monthly document update cadence, and schedule quarterly graph quality reviews. Go live with automated agent decisions, with human-in-loop gates for cost or compliance actions above defined thresholds. Measure reduction in downstream errors — billing adjustments, compliance issues, incorrect shipping documents. That's your ROI story.

When NOT to Use Graph RAG

Not every question needs a graph. If a question has a single-document answer with no cross-entity reasoning, use classic RAG. "What are the labeling rules for Customer X?" doesn't need a graph traversal. And if you just need a numeric fact, call the WMS API directly. "How many units of this SKU are on hand?" is a database query, not a graph question.

What to Watch Out For

The biggest trap is trying to model everything. If every noun becomes a node, you'll slow retrieval and drown in maintenance. Start with entities that actually change decisions. A graph of your supplier dependencies and kit structures is enormously valuable. A graph of every forklift movement is probably not.

Never auto-merge LLM-extracted relationships. A "substituted by" edge that doesn't exist in your customer's SOP could trigger a wrong shipment. Require a human gate for every policy-derived edge.

Without TTLs and event streams, you'll make yesterday's plan with today's confidence — the single fastest way to lose floor trust.

And in multi-client environments, always test your access controls explicitly. Don't assume a traversal that crosses client boundaries is blocked — prove it.

Final Thoughts: From Knowledge to Foresight

In this series, we gave our agents a purpose (Part 4), a way to collaborate (Part 5), and a factual grounding in your business documents (Part 6). Today, with Graph RAG, we've given them foresight — the ability to see the system, not just the parts.

This is the essence of the shift from automation to reasoning I mentioned back in Part 1. True reasoning isn't about finding an answer in a book — it's about understanding how that answer impacts everything else on the shelf. By mapping the hidden connections in your warehouse, you empower your AI agents to act not just with speed, but with wisdom.

We said it at the start of this series: in AI, context is the king. RAG gave your agents the right paragraphs. Graph RAG gives them the connections that drive real-world outcomes. When agents can see the map, they stop firefighting and start anticipating.