Every conversation about AI-native product search eventually collapses into a single question: which framework do we build on? It's the wrong first question. The more useful one is what job each part of the system actually needs to do, because a product catalog puts different pressure on a retrieval pipeline than a static knowledge base does — it changes constantly, it has structured fields alongside free text, and the queries hitting it range from "waterproof jacket under $180" to an AI agent asking for exact stock and delivery dates.
That's why the pattern holding up in production by 2026 isn't one framework, it's two working together: a retrieval layer that owns indexing, chunking, and embeddings, and a workflow layer that owns the branching logic of what to do with what comes back.
Two jobs, not one
LlamaIndex has become the default choice for the retrieval layer because chunking, embedding, and querying are built into its index abstraction rather than left as separate concerns you have to wire together yourself. Point it at a data source, and it handles the ingestion pipeline end to end.
LangGraph handles the other half: stateful, graph-based orchestration. Instead of a single linear chain — query in, chunks out, answer generated — a graph lets the system branch. A question about order status doesn't need the same retrieval path as a question about a jacket's fit, and an agent placing a purchase on someone's behalf needs an approval step neither of those does. LangGraph is built specifically for that kind of looping, retrying, multi-step logic, which is exactly the shape agentic commerce takes in practice.
The pattern in one line: LlamaIndex decides what's relevant. LangGraph decides what to do about it.
Why a product catalog is a harder case than it looks
A support knowledge base is mostly static prose. A product catalog is not: prices change, stock levels change, descriptions get edited, and new items are added continuously. A retrieval system that requires a full re-index every time something changes doesn't survive contact with a real catalog. This is where metadata filtering earns its place alongside semantic search — the vector store needs to filter on price, category, and availability as first-class fields, not just rank by similarity, and it needs to support fast incremental updates rather than batch rebuilds.
What this means for agent-ready commerce specifically
The harder version of this problem shows up once AI agents — not just human shoppers — are the ones querying the catalog. An agent checking stock before completing a purchase needs an answer that's accurate at that exact moment, not an answer that was true when the index was last built. That pushes the architecture toward hybrid search (structured filters plus vector similarity) and toward treating freshness as a design constraint from the start, not a performance optimization added later.
Where governance fits in
Once agents are making retrieval calls and, eventually, purchase decisions, every step in that graph becomes something worth logging: what was retrieved, what threshold triggered an action, what approval was required. Building the workflow as an explicit graph rather than a black-box chain makes that traceability a natural byproduct of the architecture rather than something bolted on afterward — which matters as much for compliance as it does for debugging.