The Hard Problem Isn't Storage — It's Retrieval

The Data Lake Fallacy

For the last decade, the enterprise playbook has been: consolidate your data. Build the data lake. Get everything in one place. Then you'll have "a single source of truth" and everything will be better.

Most companies that followed this playbook ended up with a very expensive data lake that nobody uses for operational decisions. The data is there — technically — but when your planner needs to know whether Supplier X can cover the shortage from Supplier Y's late delivery, they don't query the data lake. They call someone. They check a spreadsheet. They walk over to purchasing.

The problem was never storage. You had the data all along. The problem is retrieval in context — getting specific, relevant information at the exact moment a decision needs to be made, in a format that's useful for that decision.

What Retrieval Actually Means in Operations

When we say "retrieval," we don't mean search. Search is what happens when someone knows they need information and goes looking for it. That's fine for occasional questions. It's not fine for operational decisions that happen hundreds of times per day.

Real operational retrieval means:

• Proactive delivery: The right information arrives at the decision point before anyone asks for it. When a PO exception comes in, the relevant supplier history, alternative options, and impact assessment are already assembled.
• Contextual assembly: Not just pulling data, but assembling it into the context needed for a specific decision. A raw list of supplier lead times is data. "Supplier Y can cover this order 3 days faster than Supplier Z, but costs 8% more and hasn't been qualified for this part" is retrieval for a decision.
• Cross-system synthesis: The information needed for most operational decisions lives in multiple systems. The ERP has the order. The WMS has the inventory. The QMS has the supplier qualification. The email has the delivery confirmation. Useful retrieval stitches these together.
• Temporal awareness: What was true yesterday may not be true today. Good retrieval knows recency matters — the price from last month's PO isn't today's price, and the lead time from three months ago doesn't reflect current conditions.

Why Traditional Approaches Fail Here

The tools companies typically use for retrieval are dashboards and reports. Both are pull-based — someone has to go look at them. And both are generic — they show the same view to everyone regardless of what decision they're actually making.

Think about how your planner actually works:

They're managing 200+ active production orders. An exception comes in — material shortage on Order 4517. To make a decision, they need to know: what's the customer priority? what's the current schedule impact? is there substitute material? when does the supplier expect to ship? are there other orders we can pull material from? what did we do last time this happened with this supplier?

That information lives in 4-5 different systems. Assembling it takes 20-45 minutes. By the time they have the full picture, the decision window has narrowed. Multiply this by the 10-15 exceptions they handle per day and you understand why they're always behind.

The planner doesn't need a dashboard. They need a system that understands what decision they're facing and delivers exactly the information that decision requires — assembled, contextualized, and ready to act on.

Where AI Actually Helps: Retrieval for Decisions

This is where AI — specifically the combination of retrieval-augmented generation and agentic workflows — becomes genuinely useful in manufacturing. Not because it "knows more" than your team, but because it can assemble information from across your systems at machine speed and deliver it in the context of a specific decision.

The Pattern

Every operational decision follows the same pattern: a trigger happens, context is needed, options are evaluated, and an action is taken. AI is spectacularly good at the middle two steps — assembling context and evaluating options — when it has access to the right data sources and understands the decision being made.

What This Looks Like in Practice

• Quality hold decision: Inspector flags a dimension out of tolerance. Agent retrieves: the engineering drawing tolerance, historical disposition for similar deviations on this part, customer quality requirements, current inventory of conforming parts, and the cost of rework vs. scrap. Presents it to the quality engineer in 30 seconds instead of 30 minutes.
• Reorder decision: Inventory hits reorder point. Agent retrieves: current demand forecast, supplier current lead times (not the ones in master data from 6 months ago), price history, open POs already in transit, and whether any engineering changes are pending that would affect this part. Generates a recommended PO or flags if the situation is non-routine.
• Schedule change decision: Customer requests an expedite. Agent retrieves: current production schedule, material availability for the order, capacity constraints on the required work centers, impact on other orders, cost of overtime if needed, and the customer's priority tier. Presents the planner with options and tradeoffs instead of requiring them to check five systems manually.

The RAG Architecture for Manufacturing

The technical approach that makes this work is called Retrieval-Augmented Generation (RAG) — but the name is misleading because it sounds like a search problem. In manufacturing, the architecture is more accurately described as "decision-context assembly."

The components:

• Structured data connections: Live connections to your ERP, MES, WMS, QMS, and CMMS. Not a copy of the data — real-time access so the information is always current.
• Unstructured knowledge: Supplier communications, engineering change notices, quality procedures, maintenance records, and the tribal knowledge that lives in emails and people's heads. Indexed so it's retrievable in context.
• Decision models: An understanding of what information each type of decision requires. A reorder decision needs different context than a quality hold decision. The retrieval is shaped by the decision type.
• Temporal logic: Understanding that recent data is usually more relevant than old data, but that some things (engineering specs, customer requirements) are stable while others (supplier lead times, material prices) change frequently.

What This Means for Your Operation

If your team spends significant time gathering information before making decisions — pulling from multiple systems, chasing people down for context, assembling spreadsheets to see the full picture — that's a retrieval problem, not a data problem.

You don't need a data lake. You don't need to consolidate your systems. You don't need a 12-month data project before AI can help.

You need a system that understands the decisions your team makes every day, knows where the information for those decisions lives, and can assemble it in context at machine speed.

That's the hard problem. Storage was solved 20 years ago. Retrieval is where the value is — and it's what makes agentic workflows actually useful in production rather than just impressive in demos.

The Bottom Line

Every AI vendor will tell you their product "works with your data." But most of them mean: you dump your data into their system and they search it. That's not retrieval — that's a glorified search bar with an LLM on top.

Real retrieval for manufacturing means: understanding the operational decisions your team makes, knowing what information each decision requires, pulling that information from wherever it lives (and it lives everywhere), assembling it in context, and delivering it at the moment of decision — or better yet, having the agent make the routine decisions itself.

The companies that get this right will have faster decision cycles, fewer exceptions that escalate unnecessarily, and team members who spend their time on judgment — not on information gathering. That's the actual promise of AI in manufacturing. Not answering questions. Feeding decisions.