#AI Agent#DevOps

LangChain vs. LangGraph vs. LlamaIndex: Choosing an Agent/RAG Framework

AI framework choices are unavoidable, but LangChain, LangGraph, and LlamaIndex are often complementary, not competitors. This article maps their roles: full-stack glue, agent orchestration, and data/RAG; explains how to choose; and covers an underrated option: using no framework and writing it yourself.

Key Points

  • Topic Focus: AI Agent、DevOps
  • Suitable for: indie hackers, full-stack engineers, AI application developers
  • Core value: quickly understand background, practical paths, common pitfalls, and engineering advice
Author @admin·Published July 26, 2026·Updated July 26, 2026

When building an AI application, the first framework hurdle is choosing among LangChain, LangGraph, and LlamaIndex. Their names sound alike, their features overlap, and their documentation borrows from one another. Choose poorly and everything feels awkward; choose well and the work becomes much easier. This article is not about which one is "best," but what each one is best suited for.

1. First, correct a misconception: they are not competitors

Many people think choosing among them is an either-or decision, but each covers a different part of the stack, and they are often used together:

  • LangChain: full-stack "glue" for LLM calls, prompts, tools, memory, and document loading, with broad, all-in-one abstractions.
  • LangGraph: agent orchestration that represents complex agent workflows as state graphs, making them controllable and observable.
  • LlamaIndex: data and RAG, including document ingestion, chunking, indexing, and retrieval, where its specialization runs deepest.

LangChain and LangGraph come from the same company, and the latter is the former's "agent orchestration upgrade." LlamaIndex focuses on data/RAG. You can use LlamaIndex for RAG + LangGraph to build agents + LangChain for miscellaneous glue work. They complement one another.

2. LangChain: broad, all-in-one glue

Positioning: the Swiss Army knife of AI applications. It covers almost every stage, including LLM calls, prompt templates, tools, memory, various document loaders, vector database integrations, and chains (chained calls).

Advantages:

  • The most complete ecosystem. Whatever you need to connect, such as a vector database, document source, or tool, probably has an existing integration.
  • Fast to learn. It has the most documentation, tutorials, and examples.
  • Well suited to rapid prototyping.

Disadvantages:

  • Over-abstracted. Layers of wrappers make problems difficult to debug, with too much "magic."
  • The chain abstraction is poorly suited to complex agents because its control flow is inflexible. This is why LangGraph was created.
  • Frequent version churn, with APIs changing often.

Best suited to: rapid prototypes, applications that need many off-the-shelf integrations, and simple workflows. Once an agent becomes complex, LangChain's chains start to struggle, and it is time to use LangGraph.

3. LangGraph: the right form for agent orchestration

Positioning: orchestrating complex agents with state graphs. It was created specifically to solve the problem that LangChain's chain model cannot handle complex, controllable agents.

The core mental model is: Agent = state graph. Nodes are agents/functions, edges define control flow, and state flows between nodes. Conditional edges, loops, parallelism, and human intervention are all supported natively.

Advantages:

  • Control over complex agents. State graphs make control flow clear, traceable, and debuggable.
  • Production-grade features: human-in-the-loop, persistence (pause and resume), streaming, and tracing (with LangSmith).
  • Decoupled from any specific model or library. You can use it to orchestrate any LLM/tool.

Disadvantages:

  • Heavyweight for simple tasks. Using it for single-step RAG is overkill.
  • A learning curve. You need to adapt to the state-graph mental model.

Best suited to: multistep agents with branches/loops that must be controllable and observable (research agents, multi-agent collaboration, and complex workflows). The earlier "Multi-Agent Collaboration" and "Research Agent" articles both used it.

4. LlamaIndex: depth in data and RAG

Positioning: taking "bringing data into an LLM" as far as possible. It specializes most deeply in document loading, parsing, chunking, indexing, retrieval, query engines, and various advanced RAG techniques.

Advantages:

  • The most complete data pipelines. It offers dozens of document loaders and multiple chunking/parsing strategies.
  • Advanced RAG features built in. Hybrid retrieval, reranking, query transformation, and small-to-big retrieval work out of the box.
  • Strong structured-data querying, including Text-to-SQL and knowledge graphs.

Disadvantages:

  • Agent orchestration is weaker than LangGraph. It has agents, but complex orchestration is not its strength.
  • Its abstractions are also somewhat heavy, although more focused than LangChain's.

Best suited to: RAG / data-intensive applications (knowledge-base Q&A, document Q&A, and structured-data querying). For RAG, LlamaIndex is usually easier to work with than LangChain.

5. Decision framework

text
What do you need?
├ Simple prototype with many integrations → LangChain
├ Complex, controllable agent (multistep/branches/loops) → LangGraph
├ Primarily RAG / data ingestion → LlamaIndex
└ Combination → Common: LlamaIndex (retrieval) + LangGraph (orchestration)

In one sentence: for agent orchestration, choose LangGraph; for RAG/data, choose LlamaIndex; for rapid glue code, choose LangChain. The three often coexist.

6. An underrated option: use no framework

Frameworks are not mandatory. Especially when your application is simple or requires extremely tight control, using a model SDK directly and writing the orchestration yourself is often cleaner:

  • Simple RAG: chunk the data yourself + pgvector + one LLM call. It takes a few dozen lines and is clearer than adopting LlamaIndex's entire abstraction stack.
  • Simple agent: the earlier "ReAct Agent from Scratch" article demonstrated this with a 50-line loop containing the core agent itself.
  • Control first: a framework's "magic" becomes a liability when bugs arise. Writing critical systems yourself gives you more control.

A framework's value is "saving you boilerplate," while its cost is "learning + debugging + lock-in". For small projects, writing it yourself may be faster; for large projects, a framework reduces effort. Do not use a framework merely for the sake of "using a framework."

7. Practical framework-selection tips

  1. Clarify your requirements before choosing a framework. Do not use LangChain just because you heard it is popular. First ask, "Am I building RAG, an agent, or glue code?"
  2. Prioritize writing it yourself for small projects. Do not introduce a framework for something you can write yourself; this reduces dependencies and debugging pain.
  3. Combine frameworks as needed in large projects. LlamaIndex for RAG + LangGraph for agents is a common production combination.
  4. Watch for lock-in risk. Once framework abstractions permeate a project, migration costs are high. Keep core data/logic framework-independent by storing data/state in standard formats to reduce lock-in.
  5. Check maintenance activity. AI frameworks evolve rapidly, so choose actively maintained projects with good documentation, as all three of these are.

Summary

The three frameworks are not competitors; each covers a different part of the stack:

  • LangChain: full-stack glue, with fast prototyping and many integrations.
  • LangGraph: complex agent orchestration through controllable, observable state graphs.
  • LlamaIndex: data and RAG, where its specialization is deepest.

Choose according to your needs: agent orchestration → LangGraph, RAG/data → LlamaIndex, glue code → LangChain, often in combination. For simple scenarios or those requiring tight control, writing it yourself is often better. A framework is not the default choice.

Remember: a framework is a tool, not a belief system. Choose the option that makes your project simpler and more controllable, even if that option is "no framework." This is especially true in AI, where models and requirements change so quickly that overreliance on one framework often becomes a burden within six months.

Related

Related Content