We have a very complex RAG setup with custom Vector Stores and Embeddings. If we switch to LangGraph, do we have to rewrite all our retrieval logic? I’m hoping we can just wrap our existing LangChain "Chains" as nodes within the graph to handle the "knowledge retrieval" part of the agent's workflow.
3 answers
Absolutely, and that is actually the recommended way to use them! Any LangChain "Runnable" (which includes Retrievers, Chains, and Prompt Templates) can be called directly inside a LangGraph node. You simply define a function for your node that takes the state, runs your existing chain with the state’s input, and then returns the retrieved documents back into the graph's state. This allows you to keep all your "hard work" in data engineering while adding a layer of sophisticated reasoning on top. It’s perfect for "Adaptive RAG," where the agent can decide to re-retrieve or refine the search if the first set of documents doesn't contain the answer.
Have you noticed any issues with "state bloat" when passing large document sets through the graph edges?
Wrapping chains as nodes is how I migrated my whole company. We didn't throw anything away; we just gave our chains a "map" to follow.
That’s a huge relief. Knowing I can incrementally adopt the graph architecture without a total rewrite makes the transition much more feasible for my department.
That can be an issue! I usually store just the "Document IDs" or a summary in the main state and keep the full text in a separate key. LangGraph allows you to be very selective about which parts of the state you update at each node, which helps keep the memory footprint small and manageable.