LangChain: What It Is, How It Compares, and When to Reach for It

If you’ve spent any time building with large language models, you’ve run into LangChain. With 100k+ GitHub stars it’s the most widely-adopted open-source framework in this space, and it has quietly shifted from “a library for chaining LLM calls” to what its own README now calls “the agent engineering platform.”

This post is a practical tour: what LangChain is actually for, how you install and use it, a couple of things you can build, whether you need to deploy it anywhere, how it compares to Google’s Agent Development Kit (ADK) and the rest of the 2026 framework crowd — and, honestly, where it falls short.

What it is

At its core, LangChain gives you a standard interface over the moving parts of an LLM application — chat models, embeddings, vector stores, retrievers, tools — plus a huge library of integrations that plug those parts into real data and systems. The pitch is that you write against LangChain’s abstractions once, and swap the concrete pieces (a different model, a different vector DB) without rewriting your app.

It’s worth being precise about scope, because it’s a common source of confusion: LangChain is the component library + high-level building blocks, while its sibling LangGraph is the low-level orchestration framework for stateful, controllable agent workflows (explicit graphs with branching, retries, human-in-the-loop). Around them sits an ecosystem: LangSmith for evaluation, observability and debugging, Deep Agents as a higher-level package for planning/subagents/file-system patterns, and LangSmith Deployment for hosting long-running agents. You can use the core framework standalone, but in practice “LangChain in production” usually means LangChain + LangGraph + LangSmith.

Why it matters

The reasons people reach for it:

Model interoperability. Swap providers as the frontier moves — the same code can target OpenAI, Anthropic, Gemini, or a local model.
Real-time data augmentation. A vast catalogue of integrations (600+ connectors) to data sources, tools, vector stores and retrievers, so your agent isn’t limited to what’s in the model’s weights.
Rapid prototyping. Modular, component-based — you can stand up a working pipeline quickly and iterate without rebuilding from scratch.
Production tooling. Monitoring, evals and debugging via LangSmith; deployment for stateful workflows.
Ecosystem and community. Templates, examples, and a steady stream of new integrations as the field changes.

Getting started

It’s a normal Python package (there’s an equivalent LangChain.js for JS/TS):

pip install langchain
# or
uv add langchain

You’ll also need credentials for whatever model provider you use (set as an environment variable), or a locally-served model. A first call is three lines:

from langchain.chat_models import init_chat_model

model = init_chat_model("openai:gpt-5.4")
result = model.invoke("Hello, world!")

The init_chat_model indirection is the whole philosophy in miniature: change the string to "anthropic:..." or "google_genai:..." and the rest of your code is untouched.

In practice

1. Question-answering over your own documents (RAG). The classic use case. You embed your documents into a vector store, retrieve the chunks relevant to a question, and hand them to the model as context. In LangChain terms that’s an embeddings model + a vector store + a retriever + a prompt + a chat model — each a swappable component. The win isn’t that RAG is hard to write by hand; it’s that the retriever and vector-store integrations already exist, so you wire rather than build.

2. A tool-using agent. Give the model a set of functions (a calculator, a web search, a database query) and let it decide which to call and when. LangChain standardises tool definition and tool-calling across providers, and LangGraph gives you the control loop — when to retry, when to stop, when to ask a human. This is where the “agent platform” framing earns its keep: orchestration, state, and observability are the actual hard parts, and that’s what LangGraph + LangSmith address.

Both examples are illustrative — treat the official docs as the source of truth for exact APIs, because they move (more on that below).

Local or deployed?

LangChain is a library, not a service — it runs wherever your Python (or JS) runs. For development that’s your laptop, a notebook, or a script; you do not deploy LangChain anywhere to use it. The only external dependency is the model: either a hosted provider’s API (you need a key) or a local model (e.g. via Ollama) if you want to stay fully offline.

For production, you deploy your application like any other code — a FastAPI service, a serverless function, a worker. The optional extras are LangSmith for observability and LangSmith Deployment / the LangGraph platform if you want a managed home for long-running, stateful agents. None of that is required to build or run; it’s there when you need scale and visibility.

How it compares

Google’s Agent Development Kit (ADK), launched at Cloud NEXT 2025 and now at v1.0 for Python, is the comparison people ask about — but they’re not quite the same kind of thing. ADK is a code-first orchestration framework for multi-agent systems, designed from the start around production deployment on Vertex AI, and built on the same infrastructure behind Google’s own agent products. It leans into Google’s protocols — Agent2Agent (A2A) for inter-agent communication — while staying model-agnostic through LiteLLM (so you can still use Anthropic, Meta, Mistral, not just Gemini).

A rough map:

Dimension	LangChain (+ LangGraph)	Google ADK
Primary nature	Component library + orchestration	Orchestration framework, production-first
Integrations	Very broad (600+ connectors)	Growing; Vertex AI Model Garden + LiteLLM
Deployment story	Bring-your-own; LangSmith optional	Vertex AI is the design target
Vendor lean	Neutral / multi-provider	Google Cloud-leaning
Maturity	Large, battle-tested ecosystem	Younger, fast-moving
Best when	Max flexibility, many integrations, model swaps	You’re on Google Cloud and want production-grade multi-agent out of the box

The honest summary: pick LangChain/LangGraph for breadth, flexibility and vendor-neutrality; pick ADK if you’re already on Google Cloud and want a production-and-deployment-first path. And note that many teams don’t choose just one — these tools compose, and it’s common to see two or three in the same stack.

Other frameworks worth knowing

The 2026 landscape is crowded, and the right pick depends on the shape of your problem:

LangGraph — LangChain’s own low-level orchestrator; the default for complex, stateful, controllable workflows.
LlamaIndex — data/RAG-first; the strongest story for indexing and retrieval over documents.
CrewAI — fastest path from idea to a role-based multi-agent prototype (researcher / writer / reviewer).
AutoGen / Microsoft Agent Framework — conversational multi-agent systems.
Semantic Kernel — enterprise-oriented, consistent across C#/Java/Python.
OpenAI Agents SDK — the native choice if you’re building on OpenAI’s tools (web search, file search, computer use).
PydanticAI — typed, schema-safe, minimal; for smolagents when you want maximum minimalism.

A reasonable heuristic: LangChain/LangGraph for breadth and control, LlamaIndex when the agent is knowledge-centric, CrewAI for quick role-based crews, OpenAI Agents SDK for OpenAI-native builds, PydanticAI when you want types and small surface area.

Tradeoffs

LangChain is powerful, but the criticism is real and worth taking seriously before you commit:

Abstraction overload. The most common complaint: layers stacked on layers — prompts inside chains inside agents — that obscure what’s actually happening and force you to think in the framework’s terms. For simple tasks, the indirection adds friction rather than removing it.
Debugging pain. Vague type hints, inconsistent tracing, and stack traces that routinely span 15–40 frames of internal framework code. Finding the line that actually broke is a different skill from normal Python debugging.
The 2026 argument. In 2022, the abstractions earned their place because vendor APIs were wildly inconsistent. In 2026 those APIs have largely converged, so for some teams the abstraction now hides little and costs overhead — which is why you’ll see write-ups about teams migrating production code back to raw provider SDKs.
Dependency and docs churn. Bloated dependency trees, fast-moving APIs, and documentation that can lag the code. Pin your versions.

None of this makes LangChain a bad choice — it makes it a choice with tradeoffs. The framework is at its best when you’re genuinely benefiting from the breadth (many integrations, frequent model swaps, real orchestration needs) and weakest when you’re using a sledgehammer for a single API call.

Takeaway

LangChain is the most complete, most integrated, most community-backed way to build LLM applications and agents — and that completeness is both its strength and its main criticism. Reach for it when you need the ecosystem and the orchestration; reach for a thinner tool (PydanticAI, the raw provider SDK, or a focused framework like LlamaIndex or CrewAI) when you don’t. If you’re on Google Cloud and production deployment is the priority from day one, evaluate ADK alongside it. The good news in 2026 is that these aren’t mutually exclusive religions — they’re tools, and the interesting builds increasingly use more than one.