Contents
- What each framework is actually for
- LangChain/LangGraph: orchestration-first
- LlamaIndex: retrieval-first
- Head-to-head: the dimensions that matter in production
- The LangSmith dependency is the decision you’re not making consciously
- What LangSmith costs
- The June 2025 incident and the sentiment shift
- What lock-in costs if you switch mid-project
- When each wins: the decision tree
- What we’ve actually shipped
- The verdict
- Frequently Asked Questions
Most comparison guides end with “use both.” This post starts with a decision. If you’re choosing a framework for production RAG in 2026, you’re really choosing between three architectures: LlamaIndex for retrieval-first builds without complex stateful agents, LangGraph for durable orchestration, and the hybrid stack (LlamaIndex retrieval as a LangGraph tool) for builds where both matter. Culturro has shipped LangChain on three production builds. LlamaIndex hasn’t appeared in a shipped Culturro system yet. That’s context, not bias: the constraints we’ve encountered (offline deployment, multi-LLM routing, stateful agents) consistently favored LangGraph. For a new retrieval-first build without those constraints, LlamaIndex is what we’d evaluate first. If you need RAG fundamentals before the framework decision, start with our RAG architecture breakdown.
What each framework is actually for
The two frameworks solve different problems. Treating them as interchangeable is the first mistake teams make.
LangChain/LangGraph: orchestration-first
LangGraph hit 1.0 stable on October 22, 2025, the first stable major release with a formal “no breaking changes until 2.0” commitment. That matters. It signals durable state, persistence, human-in-the-loop, cycle support, and multi-agent coordination as production-grade primitives, not experimental ones.
LangChain itself is at 1.2.15 (April 3, 2026). The legacy chains and agents most older tutorials reference now live in langchain-classic. If you read a tutorial written before October 2025, assume the code is wrong on imports.
LangGraph’s mental model is a graph: nodes do work, edges decide what runs next, state persists across steps. That structure pays off when your workflow needs to pause for human approval, resume after a failure, or branch on conditions that aren’t known until runtime. It pays nothing extra when your workflow is “retrieve, then answer.”
LlamaIndex: retrieval-first
LlamaIndex is at 0.14.21 (April 21, 2026), still on 0.x versioning. We’ll come back to that under stability, because it cuts both ways.
The retrieval primitives are the reason teams pick it. Hierarchical chunking with parent-child relationships, auto-merging retrievers, RouterQueryEngine, sub-question decomposition, structured data extraction from complex document types: these are first-class citizens, not patterns you assemble. For document-heavy RAG (legal, medical, technical corpora) the abstractions feel purpose-built because they are.
LlamaIndex Workflows handle agentic patterns through an event-driven, async-first model. They’re capable, but they’re not LangGraph. If your “agent” is multi-hop retrieval or sub-question decomposition, Workflows are clean. If your agent needs durable state, human-in-the-loop, and cycles across hours or days, LangGraph is the right tool. For agentic RAG specifically, see our agentic RAG breakdown.
Head-to-head: the dimensions that matter in production
Nine dimensions. Hard verdicts per row. No “both have strengths” hedging.
| Dimension | LangChain/LangGraph | LlamaIndex | Winner |
|---|---|---|---|
| Document loading | 70+ loaders, broad but inconsistent quality | Purpose-built connectors, cleaner abstraction | LlamaIndex |
| Chunking | Basic splitters, manual config | Hierarchical, auto-merging, parent-child | LlamaIndex |
| Vector stores | 500+ integrations | 300+ connectors | LangChain (breadth) |
| Query/retrieval | Chains and LCEL, verbose assembly | QueryEngine removes boilerplate | LlamaIndex |
| Agentic | LangGraph: stateful, durable, HITL, v1.0 stable | Workflows: event-driven, async-first | LangGraph (complex) / Tie (simple) |
| Observability | LangSmith first-party ($39/seat/month) | Langfuse/Phoenix assembled | LangChain with LangSmith / LlamaIndex for portability |
| Overhead (per published benchmarks) | ~14ms / ~2.4K token framework overhead | ~6ms / ~1.6K token framework overhead | LlamaIndex |
| Ecosystem | 119K stars, ~8.3M pip downloads/day | 44K stars | LangChain |
| Stability | LangGraph 1.0 stable Oct 2025 (formal commitment) | 0.14.21, still 0.x, no 1.0 | LangGraph (formally) / LlamaIndex (historically smoother in practice) |
Two notes on the table. First, the overhead numbers come from third-party benchmarks (Morph LLM and other independent comparisons), not Culturro instrumentation. Verify on your workload before treating them as load-bearing. Second, LlamaIndex is reportedly 30-40% less code for equivalent RAG pipelines (from multiple developer comparisons). We haven’t measured that ourselves, so we report it as “reportedly” and not a hard number.
The LangSmith dependency is the decision you’re not making consciously
When teams pick LangChain, they’re often picking LangSmith without realizing it. The framework gets prettier, the debugger gets harder to live without, and three months in you’ve built an evaluation pipeline that only runs on LangSmith infrastructure. That’s a vendor decision dressed up as a framework decision.
What LangSmith costs
LangSmith Plus runs $39/seat/month with a 10K-trace free tier and $2.50/1,000 trace overages after that. Run the math at production scale:
- 50K traces/month: roughly $100/month in overages on top of seat licenses
- 500K traces/month: roughly $1,225/month in overages
- 5M traces/month (real for high-volume agent apps): more than $12,000/month in overages alone
That’s a real budget line that doesn’t show up when an engineer evaluates the framework on a Friday afternoon.
The June 2025 incident and the sentiment shift
In June 2025 LangSmith had a security incident that was patched but discussed widely. The incident is a fact; what the reader does with it is judgment. By March 2026 the r/LangChain subreddit was running threads on the perception that LangChain has been “drifting toward LangSmith”: APIs increasingly optimized for LangSmith adoption, debugging UX degraded for non-LangSmith users, breaking changes that nudged self-hosted observability into corners.
Read that as evidence, not verdict. If you’re already a LangSmith customer, the drift is fine. If you’re not, plan around it.
What lock-in costs if you switch mid-project
Migration estimates from teams who’ve done it: 3-4 weeks to re-instrument retrieval logic, plus another 2-3 weeks for the observability layer if you’re switching off LangSmith. The eval suite, CI pipelines, trace storage format, and test dataset shape are all framework-coupled in ways that aren’t visible until you try to leave. LlamaIndex has no first-party observability tax. Langfuse plus OpenTelemetry is the portable alternative most teams pick.
When each wins: the decision tree
Three buckets. Hard criteria. Bullets, because prose hides decisions.
Pick LangGraph if:
- Stateful, durable agents (workflows that pause, persist, resume across hours or days)
- Human-in-the-loop or async approval flows
- Complex conditional branching, cycles, or multi-agent coordination
- LangChain already in production and migration cost exceeds framework benefit
- You need a niche data source LangChain has but LlamaIndex doesn’t
Pick LlamaIndex if:
- Retrieval quality is the primary success metric (doc-heavy RAG, enterprise search, legal/medical/technical corpora)
- Faster time-to-first-working-RAG matters (hierarchical chunking and QueryEngine remove boilerplate)
- Lower per-query operational overhead at scale (roughly 2.3x less token overhead per published benchmarks)
- You want observability portability (Langfuse, Phoenix, OpenTelemetry, no first-party lock-in)
- Structured data extraction from complex document types is a core requirement
- Agent complexity is RAG-focused: multi-hop, sub-question decomposition, CRAG-style fallback
Pick the hybrid stack (LlamaIndex retrieval + LangGraph orchestration) if:
- Both retrieval quality and complex stateful orchestration matter as first-order requirements
- You want LlamaIndex’s QueryEngine wrapped as a LangGraph tool, with LangGraph holding state
- This is increasingly the production default for complex RAG-plus-agent builds, not a footnote
What we’ve actually shipped
Three Culturro builds, three framework calls, anonymized.
The offshore energy vessel management build (LangChain). Classical RAG on hybrid retrieval: Azure Cognitive Search for text, vector search for semantics, GPT-4 Turbo on top. No agent complexity. LangChain won on Azure integration depth and a simple pipeline structure that didn’t need state.
The legal research build (LangChain/LangGraph). AgenticRAG with multi-LLM routing across GPT-4o, Claude, Gemini, and DeepSeek R1. CRAG with Tavily fallback when retrieval confidence drops. Cohere Rerank in the loop. Anomaly detection on outputs. LangGraph won because the orchestration was the product: stateful agent loops, conditional routing, durable execution across long-running tasks.
The maritime simulation build (Agnos framework, not LangChain or LlamaIndex). Four specialized agents, fully offline deployment, local Qdrant plus Qwen. We mention this because the LangChain-vs-LlamaIndex axis isn’t the only choice in 2026. For air-gapped builds with constrained dependencies, neither framework was the right answer.
LlamaIndex hasn’t shipped in a Culturro production build yet. We’ve evaluated it on every retrieval-first project; the constraints we faced (offline deployment, multi-LLM routing, stateful agents) sent the decision elsewhere each time. For a build without those constraints, LlamaIndex would be our default starting point. If you’re earlier in the decision and asking whether to build a RAG system at all, we wrote a build-vs-buy framework for that question.
The verdict
For a new production RAG build in 2026 with retrieval quality as the primary concern and no complex stateful agents, LlamaIndex is the better starting point. For durable stateful orchestration, human-in-the-loop, or multi-agent coordination, LangGraph wins. For complex builds where both matter, the hybrid stack (LlamaIndex retrieval wrapped as a LangGraph tool) is the architecture we’d evaluate first.
If you’re choosing a framework for a production RAG build and want a second pair of eyes, that’s a 30-minute conversation, not a sales call. Talk to us. For the architectural decisions that apply regardless of framework, our RAG architecture deep-dive is the next read.
Frequently Asked Questions
Can you use LangChain without LangSmith?
Yes, but the debugging experience degrades. Stack traces are deep, error messages aren’t always useful, and the API is increasingly optimized for LangSmith adoption. If you’re not paying for LangSmith, plan to assemble Langfuse or OpenTelemetry instrumentation manually and budget the engineering time.
Is LlamaIndex production-ready at 0.14?
Yes. Multiple production deployments use it. The 0.x versioning is a yellow flag for enterprise teams who want a formal stability commitment, but in practice LlamaIndex has had fewer breaking changes than LangChain did pre-1.0. Pin your versions either way.
What’s the actual token overhead difference in production?
Per published benchmarks (Morph LLM and others), LlamaIndex adds ~1.6K input tokens of framework overhead per query versus LangChain’s ~2.4K, roughly 2.3x less. At 100K queries/month on GPT-4o that’s a meaningful cost difference. Always verify on your own workload before treating it as a budget assumption.
When does the hybrid stack make sense?
When both retrieval quality and complex stateful orchestration are first-order requirements. Wrap LlamaIndex’s RetrieverQueryEngine or QueryEngine as a LangGraph tool. You get LlamaIndex’s retrieval primitives plus LangGraph’s state management. This is increasingly the production default for complex RAG-plus-agent builds.
How long does migrating mid-project actually take?
Plan 3-4 weeks for a non-trivial migration of retrieval logic, plus another 2-3 weeks for the observability layer if you’re switching off LangSmith. The eval suite, CI pipelines, trace storage, and test dataset format are usually framework-coupled in ways that aren’t visible until you try to leave. Migration cost is rarely the headline reason to switch; it’s almost always smaller than the cumulative benefit of being on the right framework.