LangChain
A fast start, and a dependency worth keeping on a short leash
The parts that survive to production are narrow and worth naming. The provider interface and the agent runtime stay. Most chains get replaced by your own code.
The verdict
LangChain is worth using to get an AI feature working quickly and worth reviewing hard before launch, because the abstractions that speed up week one are the ones you most often replace with fifty lines of your own code by month three.
Two things earn their place: a common interface across model providers, and the agent runtime built on LangGraph. Most of the rest is a convenience you can write yourself once you know what you need.
Be honest about where you are on that curve. Early exploration rewards the framework. A system you now understand rewards owning the code.
In short
5 things that decide this
- 01LangChain v1 narrowed the namespace to agents, messages, tools, chat models and embeddings, and moved legacy chains, retrievers, the indexing API and the hub module to langchain-classic.
- 02LangChain describes its agents as built on top of LangGraph, taking advantage of durable execution, human-in-the-loop support and persistence.
- 03The provider interface is the durable value: one way to call chat models and embeddings, so switching providers is a small change.
- 04The v1 migration is a real breaking change, since legacy imports move to langchain_classic.
- 05A model swap still changes behaviour. Portability is not equivalence, and only your own test cases show the difference.
For someone who has not used it
LangChain is a framework for building applications on language models. It gives you one interface for chat models and embeddings across providers, plus building blocks for tools and agents.
Its stated pitch is portability: use one interface across providers, switch models with minimal code changes, and keep the application portable as requirements change. That is the promise to judge it on.
How it fits our work
It earns its place at the start, when the shape of a feature is still unclear and a wrong abstraction costs little. Getting a retrieval loop answering questions in an afternoon is genuinely useful. It makes the next conversation with a client concrete instead of theoretical.
What survives to production is narrower. The provider interface stays, because swapping a model should never be a refactor. The agent runtime stays wherever an agent needs persistence, which is the LangGraph part. Chains wrapping a single prompt call rarely survive review. The wrapper is usually longer than the code it hides.
That is not a criticism of the library so much as of how it gets used. A framework earns its keep where it removes real complexity, and a prompt with a model call is not complex.
- ProviderOne interface. Keep it.
- AgentOn LangGraph. Keep it.
- ChainsUsually replaced with code.
- PromptsVersion them yourself.
- EvalsYours, whatever you use.
The last station never belongs to a framework. Your test cases are the asset, and they outlive every library decision.
Where it stands
Good at
- One interface across chat models and embeddings, so changing provider is a configuration decision rather than a rewrite.
- The v1 namespace is genuinely tidier, and moving legacy chains to langchain-classic made the core easier to reason about.
- Agents build on LangGraph, so durable execution and human-in-the-loop come from a runtime we do run in production.
- It is the fastest way we know to get a working prototype in front of a client.
Weak at
- Thin wrappers around a single model call add indirection without removing work, and reading library source to understand your own prompt is a bad trade.
- The v1 restructure was a real breaking change: legacy imports had to move to langchain_classic, and an upgrade is a scheduled project rather than a bump.
- The abstraction can hide the exact request sent to the model, which is the thing you most need to see when output goes wrong.
- Provider portability does not make models interchangeable. The call site moves cleanly and the behaviour still shifts.
- The pace of change means pinning versions is not optional, and a tutorial six months old may not run.
Agent systems we run in production
Common questions
01Do we need LangChain at all?
No, and plenty of good systems call the provider SDK directly. The framework pays for itself when you genuinely switch models, or when you want the agent runtime underneath. If neither applies, direct SDK calls are less code and far easier to debug.
02What changed in LangChain v1?
The core namespace got much smaller. It focuses on agents, messages, tools, chat models and embeddings, with create_agent replacing the older prebuilt agent helper. Legacy chains, retrievers, the indexing API and the hub module moved to langchain-classic. An upgrade therefore means updating imports rather than tweaking a version number.
03Is LangChain the same thing as LangGraph?
They are separate pieces with a stated relationship. LangChain's documentation says its agents are built on top of LangGraph, using its durable execution, human-in-the-loop support and persistence. You can adopt the graph runtime alone, which is what our production work does.
04Does using a framework protect us when a model is retired?
Only the plumbing. A common interface means the call site barely changes when you switch, which is worth having. The new model still answers differently, and nothing but your own scored test cases will tell you where that matters.
