Overview
What LangChain is, why runnables and LCEL matter, and where LangChain Core, LangChain, and LangGraph split.
Third-party documentation. This is independently authored analysis of the public LangChain codebase — not the official docs, and not reviewed or endorsed by the LangChain team.
Overview
LangChain is a framework for building applications on top of large language models (LLMs). Its core bet is that LLM apps are composable pipelines — prompt → model → parser → tool → retriever — and that those pipelines should be expressed with plain objects and operators, not bespoke glue code. It is the most widely adopted framework of its kind, and it exists in both Python and TypeScript with the same conceptual model.
Why it exists
Raw LLM APIs are powerful but primitive: you call a model, get text back, and hand-roll everything else — prompt templating, output parsing, memory, tool-calling loops, retrieval. LangChain standardizes those pieces behind one interface (the Runnable), so you can move from prototype to production without rewriting the plumbing each time.
Three layers, one mental model
- LangChain Core — the primitives: runnables, chat messages, prompts, output parsers, tools, retrievers. Provider-agnostic; no integrations.
- LangChain — orchestration: chains, agents, and the higher-level helpers (e.g. retrieval chains) built on Core.
- LangGraph — the stateful, graph-based runtime for agentic systems: loops, branching, human-in-the-loop, and persistence. Modern agent building happens here.
Plus a large ecosystem of integrations (langchain-openai, langchain-anthropic, langchain-community, vector stores, loaders, and more), each a thin adapter over a provider or tool.
What it is not
LangChain is not a model, not a vector database, and not a hosted service (though LangSmith and LangGraph Platform are related commercial products). It's the composition layer between your code and the models/tools you use.
Reading this documentation
The modules move from the architecture (the Runnable contract and LCEL) to core concepts (the pieces you compose), configuration (actually wiring a provider), and finally working examples and an API reference. The examples assume Python, but the TypeScript package mirrors them.
