LangChain vs raw OpenAI SDK: when does each make sense?

Use the raw SDK when you have a well-defined task that requires one or two LLM calls with structured outputs. Use LangChain when you need retrieval, document loading, or a RAG pipeline and want to avoid wiring those components yourself. The SDK is more debuggable; LangChain is faster to prototype with for retrieval-heavy workflows.

LangChain vs LlamaIndex: how do they differ?

LlamaIndex is more focused on data ingestion and indexing. It has better tooling for structuring complex document collections, handling different file formats, and building hierarchical indexes. LangChain has a broader scope including agents, chains, and tools. For pure RAG over documents, LlamaIndex is often the cleaner choice. For multi-step agent workflows, LangGraph wins.

LangGraph vs CrewAI: which should I use for multi-agent workflows?

LangGraph gives you explicit control over state and transitions. You define the graph, the conditions, and the state shape. CrewAI is higher-level and gets you to a working multi-agent setup faster, but the abstraction makes it harder to debug and customize. We use LangGraph for production systems where we need to understand exactly what's happening. CrewAI is reasonable for demos and lower-stakes automation.

When is LangSmith worth setting up?

LangSmith is useful once you're running LangChain in production and need to trace why a chain produced a particular output. It gives you the full call tree, the prompts that were sent, and the responses that came back. For debugging complex chains and RAG quality issues, it's the fastest way to understand what happened. For simple implementations, the overhead of setting it up isn't worth it.

Stack Guide · LangChain & LangGraph

LangChain: when it helps, when it gets in the way.

LangChain is one of the most widely used AI frameworks, and one of the most frequently misapplied. It earns its place in RAG pipelines and retrieval-heavy workflows. It gets in the way when you need simple, debuggable LLM calls or full control over prompts.

These are notes from using LangChain and LangGraph in production builds: the patterns that hold up, the abstractions we've stopped using, and the cases where we reach for something else.

Agent development services All stacks →

Building something with LangChain?

What LangChain is actually good for.

The honest answer is narrower than the marketing suggests. LangChain genuinely saves time in a specific set of scenarios.

RAG chains with standard retrieval patterns

LangChain's retrieval abstractions (vector store loaders, document splitters, retrieval chains) map well to the 80% of RAG implementations that follow the same pattern. If you need a retriever that queries Pinecone, passes results through a reranker, and sends them to an LLM, LangChain has that wired up already.

Quick prototypes

You can go from zero to a working RAG chain in an afternoon with LangChain. The ecosystem has pre-built integrations for most vector databases, document loaders, and LLM providers. That speed matters when you're exploring whether something is worth building.

Teams already invested in the ecosystem

If your team has existing LangChain chains, deployment patterns, and monitoring set up through LangSmith, the marginal cost of adding a new chain is low. The switching cost away from it is real. Context matters.

What LangGraph adds.

LangGraph is a separate library that models agent workflows as explicit state machines. It solves a different problem than LangChain, and solves it better than LangChain's own agent abstractions.

Stateful agent graphs with conditional branching

LangGraph models an agent workflow as a directed graph where nodes are functions and edges are conditional transitions. A node can run a tool, check a condition, and route to a different node based on the result. This is exactly what you need when an agent needs to decide what to do next based on what it just did.

Human-in-the-loop patterns

LangGraph has built-in support for interrupting a workflow at a named node and waiting for human input before continuing. This is useful for approval workflows, review checkpoints, and any case where an agent should pause and ask before taking an irreversible action.

Multi-agent coordination

A supervisor agent can spawn worker agents, collect their outputs, and make decisions about what to do next, all modeled as nodes in a LangGraph. The state is passed between agents explicitly, which makes debugging much more tractable than passing messages through a shared queue.

When to skip LangChain entirely.

The framework has real costs: deep call stacks, API churn between versions, and abstractions that obscure what's actually being sent to the model. Those costs are worth paying for the right use cases. Here's when they're not.

One LLM call with structured output
If your use case is: send a prompt, parse the JSON response, done: LangChain is overkill. The raw OpenAI or Anthropic SDK is three lines of code. LangChain wraps those three lines in enough abstractions to make debugging harder without giving you anything useful. Use the SDK directly.
When you need full control over prompts
LangChain's built-in prompts and chat templates add a layer of indirection between you and the string that gets sent to the model. For simple use cases, that's fine. For cases where the exact wording, whitespace, and formatting of the prompt matters for output quality, fighting the framework to get the prompt exactly right costs more than just managing the strings yourself.
When debugging needs to be straightforward
LangChain has deep call stacks. When something goes wrong (wrong output format, unexpected retrieval results, a chain failing silently) finding where the bug is takes real work. With a raw implementation, the code is yours. With LangChain, you're tracing through framework code that you didn't write. If your team isn't already familiar with the internals, plan for debugging to be slow.

How we use it in actual builds.

We've settled into a consistent pattern across projects: use LangChain for retrieval, LangGraph for agent orchestration, and the raw SDK for everything else.

Chains we keep

We use LangChain's retrieval chains for standard RAG, its document loaders for parsing PDFs and web pages, and its output parsers for structured JSON extraction. These are genuine time-savers and the abstractions are stable.

Abstractions we avoid

We don't use LangChain agents in production. The ReAct agent loop has unpredictable behavior on complex tasks and the prompts are hard to tune. For agentic workflows we use LangGraph directly, or write the loop ourselves. We also avoid LangChain's memory implementations. They make assumptions about conversation history that rarely fit actual product requirements.

LangGraph as the agent layer

For anything that requires multi-step agent behavior, we use LangGraph. The explicit state machine model makes it possible to read the code and understand exactly what the agent does and when, which matters a lot when you're debugging a production system at 2am.

The mistakes we see most often.

These aren't edge cases. They're the patterns we see in almost every codebase that uses LangChain without careful thought about when and how to apply it.

Over-chaining
Chaining five components together when two would do. Every extra link in a chain is another place where the input or output format can mismatch, another layer of abstraction to trace through when debugging, and another component that needs to be updated when the underlying API changes.
Using deprecated APIs
LangChain has changed its API surface significantly across versions. The documentation is full of examples that use patterns from 0.0.x that were deprecated in 0.1.x and removed in 0.2.x. If you're copying code from tutorials without checking the version, expect silent failures and confusing error messages.
Fighting the framework for simple use cases
We've seen teams spend days trying to configure LangChain to do something that would take an hour to implement directly. The framework has opinions. When your requirements don't match its opinions, building around them is expensive. The right call in those cases is to drop down to the raw SDK.

Frequently asked questions.

LangChain vs raw OpenAI SDK: when does each make sense?: Use the raw SDK when you have a well-defined task that requires one or two LLM calls with structured outputs. Use LangChain when you need retrieval, document loading, or a RAG pipeline and want to avoid wiring those components yourself. The SDK is more debuggable; LangChain is faster to prototype with for retrieval-heavy workflows.
LangChain vs LlamaIndex: how do they differ?: LlamaIndex is more focused on data ingestion and indexing. It has better tooling for structuring complex document collections, handling different file formats, and building hierarchical indexes. LangChain has a broader scope including agents, chains, and tools. For pure RAG over documents, LlamaIndex is often the cleaner choice. For multi-step agent workflows, LangGraph wins.
LangGraph vs CrewAI: which should I use for multi-agent workflows?: LangGraph gives you explicit control over state and transitions. You define the graph, the conditions, and the state shape. CrewAI is higher-level and gets you to a working multi-agent setup faster, but the abstraction makes it harder to debug and customize. We use LangGraph for production systems where we need to understand exactly what's happening. CrewAI is reasonable for demos and lower-stakes automation.
When is LangSmith worth setting up?: LangSmith is useful once you're running LangChain in production and need to trace why a chain produced a particular output. It gives you the full call tree, the prompts that were sent, and the responses that came back. For debugging complex chains and RAG quality issues, it's the fastest way to understand what happened. For simple implementations, the overhead of setting it up isn't worth it.

Need help choosing the right stack?

Tell us what you're building and where you're stuck. We can give you an honest opinion on whether LangChain is the right tool for it, and if not, what is.