LangChain vs LangGraph (and LlamaIndex): Which One to Use?

LangChain, LangGraph and LlamaIndex are open-source Python (and TypeScript) frameworks for building applications on large language models. In one sentence each:

• LangChain gives you building blocks and integrations: a common interface to many models, prompt templates, document loaders, retrievers, tools and output parsers.
• LangGraph (from the same team) is for orchestrating agents and multi-step workflows as a graph of steps with shared state, so you can build loops, branches, retries, saved progress and human approval steps.
• LlamaIndex focuses on connecting models to your data: loading, indexing and querying documents for retrieval-augmented generation, plus its own agent and workflow tools.

They are not strict alternatives. LangChain and LangGraph are designed to be used together, and recent LangChain versions build their agent features on LangGraph’s runtime.

Side by side

	LangChain	LangGraph	LlamaIndex
Main purpose	Components and integrations for LLM apps	Stateful agents and workflows as graphs	Data ingestion, indexing and retrieval for LLM apps
Level	Higher-level building blocks	Lower-level orchestration with full control of steps	Higher-level data and query abstractions
Best at	Quickly wiring models, prompts, tools and retrievers	Long-running, multi-step agents with loops, persistence and human approval	RAG over many document types and data sources
State and memory	Simple chains and agents	Explicit shared state, checkpoints, resume after failure	Indexes and query engines; workflows for multi-step logic
Typical project	A chatbot with tools and retrieval	A support agent that investigates, asks for approval, then acts	A question-answering system over thousands of PDFs

How they fit together

A common setup: use LangChain’s model and tool integrations, orchestrate the agent’s steps with LangGraph, and use either LangChain retrievers or LlamaIndex for the document search. Many teams mix them with their own code; none of them is required.

When to use plain code instead

For a simple application, such as one prompt, one retrieval call and a structured output, a framework can add layers you do not need. Calling the model’s API directly, plus a small retrieval function, is easier to read, debug and upgrade. Frameworks pay off when you need many integrations, complex control flow, persistence and observability, or when your team already knows them.

How to choose

1. Mostly retrieval over documents? Look at LlamaIndex, or LangChain’s retrievers.
2. An agent with loops, branching, saved state or human approval? LangGraph.
3. Lots of model and tool integrations, quick prototypes? LangChain.
4. Small, stable feature? Plain code may be best.

Whatever you choose, keep your prompts, tools and evaluation set independent of the framework, so you can switch later.

Common mistakes

1. Choosing a framework before understanding the problem. Build the simplest version first.
2. Hiding prompts inside framework defaults. Make sure you can see and test the exact prompt sent to the model.
3. Skipping evaluation because the framework “handles it”. It does not; you still need an evaluation set.
4. Copying old examples. These frameworks change quickly; follow the current documentation.

Interview angle

Interviewers want to know whether you understand what problem each tool solves and when not to use one. A strong answer: “LangChain for components and integrations, LangGraph for controlled, stateful agent workflows, LlamaIndex for data indexing and retrieval; for simple features I use plain code.” More in the AI engineer interview questions.