LangChain
- LangChain
- LangChain is an open-source framework for building LLM applications—chains, agents, and RAG pipelines—by composing prompts, retrievers, models, and tools into reusable workflows, with the October 2025 release refocusing the core API around agent loops running on LangGraph.
LangChain is an open-source framework that connects large language models to data sources, tools, and memory, making it the most common starting point for building RAG pipelines and AI agents.
What It Is
A bare LLM can answer questions from its training data—and that’s it. Building anything practical, like a chatbot that searches your internal docs, an assistant that calls APIs, or a RAG pipeline that grounds answers in your knowledge base, means stitching together a retriever, a vector store, a prompt template, the model itself, an output parser, and often a memory store. LangChain provides those pieces as standard, swappable building blocks. For a product manager scoping an AI feature, LangChain is the answer to “how does the engineering team actually wire all this together without reinventing the wheel?”
Under the hood, the framework offers abstractions for the recurring parts of an LLM app: prompts, models (chat or completion), retrievers (anything that fetches relevant context), vector stores, tools (external functions the model can call), and memory. These pieces are composed using the LangChain Expression Language (LCEL)—a declarative syntax where components are piped together, similar to chaining filters in a Unix shell. A typical RAG pipeline becomes: question → retriever → prompt template with retrieved context → LLM → output parser. Swap the retriever or the model without touching the rest.
According to the LangChain Blog, LangChain 1.0 shipped on 22 October 2025 and refocused the framework around the core agent loop. Long-running, branching, multi-step agents now run on LangGraph—a lower-level graph runtime—while LangChain sits on top as the high-level agent and chain abstraction. LCEL still works for chain composition, but new agentic patterns, including agentic RAG, are typically built directly with LangGraph. The result: simple RAG and chains stay easy, while production agents get a runtime designed for state management, conditional branching, and human-in-the-loop checkpoints.
How It’s Used in Practice
The most common scenario is building a RAG pipeline over private documents—internal wikis, customer support tickets, product manuals, contracts. A team picks a vector database (Pinecone, Chroma, pgvector), an embedding model (OpenAI, Cohere, or open-source), and an LLM (Claude, GPT, Gemini), then uses LangChain to orchestrate: load and chunk the documents, embed and store them, retrieve top matches at query time, optionally rerank with a cross-encoder, and pass everything to the LLM in a prompt template. The whole pipeline is a few dozen lines of Python or TypeScript. When the team wants to upgrade—swap Pinecone for Weaviate, or add a Cohere reranker—they change the import, not the architecture.
Beyond RAG, LangChain is widely used for tool-using agents: assistants that read calendars, run SQL queries, search the web, or call internal APIs in response to natural-language requests. After 1.0, those agents are typically authored as LangGraph graphs and exposed through LangChain’s high-level agent API.
Pro Tip: Don’t reach for an agent loop until a straight RAG chain isn’t enough. Most “AI assistant” features people imagine are really retrieval plus a single LLM call. Start with LCEL, measure answer quality, and graduate to LangGraph only when the workflow genuinely needs durable state, branching, or multiple tool calls.
When to Use / When Not
| Scenario | Use | Avoid |
|---|---|---|
| Building a RAG pipeline over internal documents | ✅ | |
| Prototyping a chatbot that calls internal APIs and tools | ✅ | |
| Production agent with branching state and human approvals | ✅ | |
| One-shot LLM call with no retrieval, no tools, no memory | ❌ | |
| Locked into one model and vector store, no plan to swap | ❌ | |
| Latency-critical path where every millisecond counts | ❌ |
Common Misconception
Myth: LangChain and LangGraph compete—you have to pick one. Reality: Since the 1.0 release, LangGraph is the runtime that LangChain agents run on. They are layers, not alternatives. LangChain provides the high-level agent and chain API; LangGraph kicks in underneath when an agent needs durable state, conditional branching, or human-in-the-loop steps.
One Sentence to Remember
LangChain is the standard glue layer for LLM apps: it lets a small team go from “we need a RAG pipeline over our docs” to a working prototype in an afternoon, then swap any component—model, vector store, retriever, reranker—without rewriting the surrounding code, which is why “are we using LangChain or LlamaIndex?” is a useful early question when scoping any AI feature.
FAQ
Q: Is LangChain free to use? A: The framework itself is open-source and free. LangChain Inc. sells commercial add-ons—LangSmith for observability and evaluation, and LangGraph Platform for managed agent deployment—but production apps can ship on the OSS framework alone.
Q: What’s the difference between LangChain and LlamaIndex? A: LangChain is a general LLM-app framework covering chains, agents, and RAG. LlamaIndex specializes in data-centric RAG, with deeper indexing primitives. Many teams pair them: LlamaIndex for retrieval, LangChain for the surrounding agent and tool logic.
Q: Do I need to learn LangGraph if I use LangChain? A: Only when building agents with state, branching, or human-in-the-loop steps. Simple chains and basic RAG still work with LCEL alone. According to the LangChain Blog, after 1.0, complex agentic workflows are authored directly in LangGraph.
Sources
- LangChain Blog: LangChain and LangGraph Agent Frameworks Reach v1.0 Milestones - Official 1.0 release announcement covering the agent-loop refocus and the LangChain–LangGraph runtime split.
- LangChain Docs: Build a RAG agent with LangChain - Canonical tutorial showing how a RAG pipeline is composed with the current API.
Expert Takes
A framework is just a vocabulary for the parts of a problem. LangChain’s vocabulary—retriever, prompt, model, parser, memory—maps cleanly onto how language-model applications actually decompose, and that clarity is why it became the default. The risk is mistaking the vocabulary for the engineering. Composing components is easy; making them produce useful, grounded, accurate answers on real data is the hard part, and no framework removes that.
Spec the contract before reaching for the framework. LangChain shines when each step is decided—retrieve relevant chunks, rerank, pass into a prompt with these fields, parse this output—and the team wants a clean way to wire them up. It’s less helpful when that work is skipped and “the chain” hides an underspecified pipeline. Write the retrieval and prompt-template specs first; LangChain then becomes the implementation, not the design.
Pick the stack and ship. LangChain is the default for a reason: hiring, tutorials, and integrations all point at it. Teams are using either LangChain or LlamaIndex, paired with a vector database and a frontier model. Re-architecting the orchestration layer halfway through a project costs more than picking the popular option now. The strategic question is not which framework—it’s which retrieval quality and which model the customers will actually feel.
Frameworks set defaults, and defaults shape what gets built. LangChain has made it easy to wire a model to a retriever, easy to call tools, easy to run agents over private data. What it has not made easy is asking who owns the answers, who audits the prompt, or who is liable when a grounded-but-wrong response shapes a real decision. The wiring problem is largely solved. The accountability problem is not.