LangChain alternatives
Sorted by what you are actually trying to fix, because a framework swap rarely fixes it.
The verdict
For stateful agents, LangGraph is the right layer; for document-heavy retrieval, LlamaIndex fits better; for most single-purpose features, a provider SDK and your own code beats any framework, and that last option is the one most teams asking this question actually need.
Most complaints about LangChain are complaints about a thin chain wrapping one model call. The fix is deleting the chain, not adopting a different framework to wrap it in.
The genuine reasons to move are narrower: durable state across a long-running agent, or retrieval over a large document set. Both have a real answer below.
How we judged these
Verified
We run LangChain and LangGraph in production, including the agent behind Cruise Search AI. LlamaIndex and the no-framework approach are evaluated from their own documentation and public benchmarks, not shipped client work. We have marked that distinction rather than blurring it.
Options were included only if they solve a problem LangChain is actually chosen for: model portability, agent orchestration or retrieval over private documents.
- What it actually replaces
- Whether the tool solves the reason people leave, rather than a different problem with a similar name.
- State and persistence
- Whether a long-running or paused process can resume without you building that yourself.
- Visibility into the model call
- Whether you can see the exact prompt that reached the model, or have to read library source to find out.
- Cost of leaving later
- What of the current build carries over if this choice turns out wrong.
The field
| Option | Best for | Adds a runtime | Retrieval built in | Learning cost |
|---|---|---|---|---|
| LangChain (incumbent) | Fast prototyping, provider portability | Optional (via LangGraph) | Legacy, moved to langchain-classic | Low to start, rises with chains |
| LangGraph | Agents that must pause, resume or persist | Yes | No | Medium |
| LlamaIndex | Answering questions from your documents | No | Yes, its core focus | Low |
| Provider SDK, no framework | A single well-defined feature | No | No | Lowest |
Ranked, by what you are trying to fix
- 01
No framework, provider SDK direct
The answer framework vendors will not publish
If the app calls one model, for one purpose, and does not need to switch providers next quarter, a chain buys you nothing. The OpenAI and Anthropic SDKs already give you a typed client, streaming and retries. Writing the prompt assembly yourself means the exact request reaching the model is always visible in your own code.
This is not a beginner's answer. It is where most production features we have shipped end up once the shape of the problem is known.
Best for
- A single feature calling one provider
- Teams who want the exact prompt visible in a code review
- Anyone who has already found the chain they removed was longer than the code it replaced
Not for
- Teams that genuinely swap model providers often
- An agent that must pause for a human and resume later
The agent runtime, without the rest of LangChain
The right choice when an agent must survive a restart, hold state across many turns, or stop and wait for a person. Checkpointers persist the run so it can resume, and that is genuinely hard to build well yourself.
LangChain's own documentation says its agents are built on top of LangGraph. You can adopt the graph runtime on its own, inside a plain service, without the wider LangChain package. The agent behind Cruise Search AI is built that way: FastAPI plus LangGraph, no other LangChain layer.
Best for
- A conversation that must survive a crash or a redeploy
- An agent that pauses for human approval mid-run
- Anyone who wants persistence without hand-rolling a state store
Not for
- A single request that answers in one pass, where the graph adds nothing
- Teams unwilling to design around a node re-running fully on resume
Retrieval over your own documents, as the main job
Choose this when the feature is fundamentally a question-answering tool over documents you own. Its documentation centres on ingestion, parsing and indexing, which is the unglamorous work that decides whether a retrieval feature actually works.
The old split, where LangChain does agents and LlamaIndex does retrieval, is no longer accurate. LlamaIndex now describes itself as a framework for building agents over your data too. What still holds is emphasis, not capability: retrieval sits at the centre of LlamaIndex, and as one tool among several in LangChain.
Best for
- A tool that answers mainly from a document set
- Teams whose hardest problem is parsing, not orchestration
- Projects that need connectors to many document sources out of the box
Not for
- An agent that mostly takes actions and touches documents occasionally
- Anywhere retrieval is one step inside a larger branching workflow
Still correct for prototyping and provider portability
Staying is often the right call, used narrowly. The v1 release narrowed the core namespace to agents, messages, tools, chat models and embeddings. Legacy chains, retrievers and the indexing API moved to langchain-classic. The provider interface is still useful: one way to call chat models and embeddings. A model swap becomes a small change, not a rewrite.
Keep it for exactly that: the provider interface and, where needed, the agent runtime underneath. Drop the chains wrapping a single prompt call, which is the part that generates most of the frustration behind this search.
Best for
- Early-stage work where the shape of the feature is still unclear
- Teams that genuinely need to switch model providers
- Getting a working prototype in front of a client fast
Not for
- A production feature calling one provider with one purpose
- Anyone who cannot pin versions and revisit the app on the v1 migration schedule
An agent built on LangGraph, without the rest of LangChain
Common questions
01Do I need LangChain at all?
Often not. If your app calls one model for one purpose, a provider SDK and your own prompt code is less to debug. It also keeps the exact request visible. LangChain earns its place when you need provider portability, or want the LangGraph agent runtime underneath.
02What does moving off LangChain actually cost?
Your own prompt logic and business code carry over almost unchanged, since a chain calling a model is a thin wrapper around that code. What you rebuild is the wiring: the chain composition and any retriever setup. Expect to rewrite the plumbing, not the thinking.
03Is LangGraph a replacement for LangChain, or part of it?
Part of it, but usable alone. LangChain's documentation says its agents are built on top of LangGraph. You can adopt the graph runtime by itself, inside a plain service with no other LangChain package. Our production agent work is built that way.
04LlamaIndex or LangChain for a document question-answering tool?
LlamaIndex, if the tool is mainly answering from documents — its documentation centres on ingestion, connectors and indexing. Choose LangChain instead when retrieval is one step inside a broader agent that also takes actions.
