Building the Same RAG Assistant 3 Ways: LangChain vs LangGraph vs Strands Agents

What changes when one document assistant is built as a chain, a controlled graph, and a tool-using agent?Why I built this projectRetrieval-Augmented Generation, usually called **RAG**, is one of the most practical patterns in modern AI engineering. A normal language model answers from what it…

What changes when one document assistant is built as a chain, a controlled graph, and a tool-using agent?Why I built this projectRetrieval-Augmented Generation, usually called **RAG**, is one of the most practical patterns in modern AI engineering. A normal language model answers from what it learned during training. A RAG system adds one extra step: before generating an answer, it searches a trusted knowledge source and brings relevant context into the prompt.That small change makes a huge difference.Instead of asking an AI model to guess from memory, we allow it to answer from files such as PDFs, Word documents, policy manuals, Excel sheets, training notes, product FAQs, creative briefs, or internal documentation. This is why RAG is now widely used in enterprise assistants, HR chatbots, customer support systems, legal research copilots, healthcare knowledge tools, and education platforms.For this project, I wanted to understand a bigger question:If the goal is the same — build a document-based AI assistant — how does the implementation change when we use LangChain, LangGraph, and Strands Agents?So I built the same Streamlit RAG assistant in three ways:1. LangChain — a chain-based RAG application.2. LangGraph — a stateful graph workflow for controlled RAG.3. Strands Agents — an agent-style implementation where document search is treated as a tool.The user experience is the same in all three versions. A user uploads documents, clicks a process button, asks questions in a chat box, and receives answers with retrieved source chunks. The difference is not what the user sees. The difference is how the system thinks behind the scenes.The common foundation: what every RAG system needsBefore comparing the frameworks, it helps to understand the shared RAG foundation.Every version in this project follows the same core pipeline:Documents↓Universal loader↓Text chunks↓Embeddings↓Vector database↓Retriever↓LLM answer↓Conversation memoryDocument loadingThe first step is ingestion. Real users do not always upload clean text files. They may upload PDFs, Word documents, Excel spreadsheets, CSV files, Markdown notes, or HTML pages. Because of that, this project includes a universal document loader.The loader detects file extensions and uses the right loading strategy:LangChain’s loader ecosystem is useful here because loaders standardize many external formats into a common document representation. That means downstream code can process documents consistently even when the source format is different.ChunkingAfter loading the document, the next step is chunking. Chunking means splitting long text into smaller pieces.This matters because language models and embedding models have token limits. More importantly, retrieval works better when each chunk contains a focused idea. If a chunk is too large, it may contain too many mixed topics. If a chunk is too small, it may lose useful context.A common starting point is:chunk_size ≈ 500 to 1000 tokenschunk_overlap ≈ 50 to 150 tokensOverlap is important because ideas often cross chunk boundaries. For example, a policy rule may start at the end of one paragraph and continue into the next. Overlap helps preserve that context.EmbeddingsEmbeddings convert text into vectors. A vector is a list of numbers that captures semantic meaning.For example, these two phrases are different at the keyword level:remote work policyworking from home rulesBut semantically, they are close. Embeddings help the system understand that closeness.Vector storeA vector store saves the embeddings and allows similarity search.When a user asks a question, the system embeds the question and compares it with stored document vectors. The most similar chunks are returned as context.This project is designed so the local demo can run without expensive infrastructure. For real production systems, teams might use FAISS, ChromaDB, Pinecone, Weaviate, Qdrant, Milvus, Elasticsearch vector search, or a cloud-native database.GenerationAfter retrieval, the selected chunks are sent to a language model with the user question. The model is instructed to answer using only the retrieved context.A good RAG prompt usually says something like:Use the provided context to answer the question.If the answer is not present in the context, say that the document does not provide enough information.This reduces hallucination and makes the answer more grounded.MemoryMemory stores the conversation history.Without memory, every question is isolated. With memory, the assistant can understand follow-up questions.Example:User: What is the remote work policy?Assistant: Remote work requires manager approval.User: Who approves it?The word “it” refers to remote work. A memory-aware assistant can understand that connection.Approach 1: LangChain — the fastest path to RAGLangChain is the most direct way to build a classic RAG application. It provides components for document loading, splitting, embeddings, vector stores, retrievers, prompts, chat models, and memory.In this project, the LangChain version follows a simple pattern:User question↓Retriever finds relevant chunks↓Prompt combines question + context + chat history↓LLM generates answer↓Conversation history is updatedWhy LangChain is useful:LangChain is useful because it gives developers ready-made building blocks. If you want to quickly build a document Q&A system, LangChain saves time.It is especially good for:Document Q&AInternal knowledge assistantsChatbots over policies or manualsCustomer support assistantsResearch copilotsFast prototypesLangChain mental modelI think of LangChain as a component framework. You connect components:Loader + Splitter + Embeddings + Vector Store + Retriever + LLM + MemoryThis is easy to explain and easy to teach.Strengths: LangChain’s main strength is speed. You can build a useful RAG app quickly. It also has a large ecosystem of integrations, which is helpful when dealing with many file formats and external services.Limitations: The challenge appears when the workflow becomes more complex. For example:What if the first retrieval result is weak?What if the answer needs validation?What if a human should approve the final answer?What if the assistant needs to retry with a better query?What if different question types should follow different routes?You can still handle these cases in LangChain, but the logic can become harder to organize. This is where LangGraph becomes useful.Approach 2: LangGraph — RAG as a stateful workflow ####LangGraph is designed for stateful workflows and agents. Instead of thinking only in terms of a chain, you define a graph of nodes and edges. A node is a step in the workflow. An edge controls where the workflow goes next.For this project, the LangGraph version can be understood like this:START↓retrieve_node↓generate_node↓critique_node↓Is the answer grounded?├── Yes → final_node → END└── No → retry_node → retrieve_nodeWhy LangGraph is useful:LangGraph becomes important when your RAG assistant needs more control.For example, a standard RAG system may retrieve chunks and answer immediately. A LangGraph system can add checks:Did retrieval return enough evidence?Is the generated answer supported by the source chunks?Should the assistant retry with a rewritten query?Should the system pause for human review?Should the workflow continue, branch, or stop?This makes LangGraph suitable for more serious AI workflows.LangGraph mental modelI think of LangGraph as a state machine for AI applications.Instead of hiding the process inside one chain, it exposes the workflow step by step:State = question + history + retrieved chunks + draft answer + critique + retry countEach node reads and updates the state. This is powerful because it makes debugging easier. You can inspect what happened at each step.Strengths: LangGraph is strong when you need.Stateful executionConditional routingRetry loopsHuman-in-the-loop checkpointsLong-running workflowsMulti-step reasoningBetter observabilityLimitations: LangGraph requires more design thinking. For a simple document Q&A assistant, it may feel like extra work. But when the system grows, graph structure becomes an advantage.Approach 3: Strands Agents — RAG as a tool-using agent ####Strands Agents takes a different approach. Instead of hardcoding each step as a chain or graph, you create an agent with tools. The model decides when and how to use those tools.In this project, document retrieval becomes a tool:Tool: search_uploaded_documents(query)The agent can decide:Should I search the documents?What query should I use?Do I need to summarize the results?Should I use memory before answering?A simplified Strands-style flow looks like this:User question↓Agent reads instructions and available tools↓Agent calls document_search_tool↓Tool returns relevant chunks↓Agent produces final answerWhy Strands Agents are useful:Strands Agents are useful when the assistant needs to act more autonomously.For example, a document assistant may start with search, but later it may need tools for:Web searchCalculationsFile writingDatabase lookupAPI callsTicket creationEmail draftingReport generationInstead of building a fixed route for every scenario, an agent can choose tools dynamically.Strands mental modelI think of Strands Agents as a model-driven tool agent framework.You define:Agent roleAvailable toolsModel providerSafety instructionsContext managementThen the model decides how to solve the task using those tools.Strengths: Strands Agents is strong when you want it. It is autonomous tool use, flexible model providers, agent-style task execution, multi-tool workflows, production-oriented agent patterns, and a lightweight SDK for agent development.Limitations: Agents are flexible, but flexibility needs guardrails. If an agent can call tools, you need to think about permissions, validation, logging, and human approval for sensitive actions.A little history: how we reached these three approachesThe evolution of LLM applications can be understood in stages.Stage 1: Prompt-only appsEarly LLM apps were mostly prompt templates. Developers sent a user question to a model and displayed the answer. This was simple, but limited. The model could not access private documents unless the developer pasted them into the prompt.Stage 2: RAG applicationsRAG became popular because it solved a practical problem: how do we connect LLMs to external knowledge? Instead of retraining the model, developers could store documents in a vector database and retrieve relevant chunks at runtime. This made LLMs much more useful for businesses.Stage 3: Chain-based orchestrationFrameworks like LangChain helped standardize the building blocks: loaders, splitters, embeddings, vector stores, retrievers, prompts, tools, and memory. This made it easier to build complete RAG applications quickly.Stage 4: Graph-based workflowsAs applications became more complex, developers needed better control over state, branching, retries, and human review. LangGraph emerged to solve these workflow problems.Stage 5: Agentic systemsThe next stage is agentic AI. In agentic systems, the model does not only answer. It can plan, choose tools, take actions, observe results, and continue working. Strands Agents fits into this direction by focusing on model-driven agents with tools and provider flexibility.Side-by-side comparisonWhy this mattersThis comparison matters because many AI beginners think frameworks are competitors. In practice, they solve different levels of the same problem.LangChain helps you build the RAG foundation quickly.LangGraph helps when the assistant needs structured reasoning, state, and reliability.Strands Agents helps when the assistant needs to use tools and act more autonomously.The best choice depends on the problem.Use LangChain when: You want a simple and reliable RAG chatbot over documents.Examples:- HR policy chatbot- Customer FAQ assistant- Course notes assistant- Legal document Q&A- Internal knowledge base searchUse LangGraph when: You need a controlled workflow.Examples:- Compliance review assistant- Legal research workflow- Multi-step report generator- RAG system with critique and retry- Human approval before final responseUse Strands Agents when: You want the model to use tools dynamically.Examples:- Research agent- Data analysis agent- Assistant that searches documents and writes reports- Agent that calls APIs- Multi-tool business workflow assistantThe Streamlit user experienceThe Streamlit app gives a simple interface:1. Choose implementation: LangChain, LangGraph, or Strands Agents.2. Upload documents.3. Process documents.4. Ask questions in the chat box.5. View retrieved chunks and sources.6. Ask follow-up questions using memory.This makes the project easy to demo.A user does not need to understand the backend to use it. They simply upload documents and chat. That is important because real AI applications are not only about models. They are also about user experience.The future: where RAG and agents are goingRAG is not going away. In fact, it is becoming more important. The future is likely to include:Multimodal RAG — Future assistants will retrieve not only text, but also images, tables, diagrams, audio, and video. For example, an education assistant may answer using lecture notes, slides, recorded videos, and diagrams.Agentic RAG — Instead of one retrieval step, agents will plan multiple retrieval steps.For example:Search policy documentSearch FAQCompare resultsAsk for approval if confidence is lowGenerate final answerBetter memory — Current memory is often short-term chat history. Future systems will combine short-term, long-term, user-specific, and task-specific memory.More evaluation — RAG systems need evaluation. Developers will increasingly test the retrieval quality, answer faithfulness, citation accuracy, hallucination rate, response latency, and user satisfaction.Final takeawayRAG is the bridge between language models and real knowledge.LangChain, LangGraph, and Strands Agents are three different ways to build that bridge:LangChain gives reusable components.LangGraph gives stateful control.Strands Agents give agentic tool use.They are not enemies. They are layers of maturity. Start simple with LangChain. Move to LangGraph when the workflow needs control. Explore Strands Agents when your assistant needs to choose tools and act more autonomously.That is the real value of building the same RAG assistant three ways.Solution ImplementedTest Solution Link: https://gitahub.com/subhashjugran/rag-three-ways-streamlit.gitReferencesLangChain documentation: https://docs.langchain.com/oss/python/langchain/overviewLangGraph documentation: https://docs.langchain.com/oss/python/langgraph/overviewStrands Agents documentation and AWS blogs: https://strandsagents.com/This story is published on Generative AI. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories.Subscribe to our newsletter and YouTube channel to stay updated with the latest news and updates on generative AI. Let’s shape the future of AI together!Building the Same RAG Assistant 3 Ways: LangChain vs LangGraph vs Strands Agents was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source: Generative AI Pub — Published August 12, 2026 at 15:00 UTC — Category: Image AI