What LangChain Is For: Six Problems Every LLM App Runs Into

A model API is simple: text goes in, text comes out. Every real application then rebuilds the same plumbing around that one call. LangChain is that plumbing, packaged once.

It helps to know which problem each part solves, because that also tells you when you do not need it. Here are the six problems, in the order most projects hit them.

1. Every provider speaks a different dialect

OpenAI, Anthropic, Gemini, Mistral and a local model on Ollama all accept a list of messages and return a reply. They disagree on almost everything else: how a message is shaped, how tools are described, how a tool call comes back, how streaming and errors work. Code written against one provider does not run on another.

LangChain's answer is a set of shared interfaces in langchain-core (a chat model, a message, a tool, an embedding model, a vector store) and one integration package per provider: langchain-openai, langchain-anthropic, langchain-ollama and so on. Your code talks to the interface, so switching providers, or running a cheaper model for some calls, is a configuration change rather than a rewrite.

2. The model does not know your data

A model knows what it was trained on. It does not know your documents, your tickets or yesterday's decision. To answer from your data, you have to find the right passages and put them in the prompt, every time. That is retrieval-augmented generation, or RAG.

Every box in that pipeline is a part LangChain provides: document loaders, text splitters, embedding models, vector stores (Chroma, Qdrant, pgvector and others) and retrievers. You still choose how to chunk, which embedding model to use and how many passages to send. Those choices decide answer quality far more than the framework does.

3. The model cannot act

A model cannot delete a file, call an API or query a database. The most it can do is say "call this tool, with these arguments". Something has to describe the tools to the model, read its tool call, run the real function, hand the result back, and repeat until the model says it is done. That loop is what people mean by an agent.

In LangChain this is create_agent: you pass a model and a list of tools, and it runs the loop. The important detail is in the second box. The model only ever proposes. Your code decides what actually runs.

4. An agent that can act needs rules

Once an agent can act, you need control over how it acts. You want a person to approve anything destructive, retries when a model or tool fails, a limit on how many calls a single request can make, long conversations trimmed or summarised so they fit the context window, and personal data kept out of prompts.

LangChain calls these middleware: hooks that run before and after the model, and around each tool call. It ships middleware for human approval, model and tool retries, call limits, summarisation, PII handling and more, and you can write your own. This is the part I find most useful, because it is where the safety of an agent actually lives. An approval rule belongs at the point where the action happens, not in the conversation that led to it.

5. Long-running work needs memory and a pause button

A conversation spans many requests. An approval might come back an hour later, from a phone. Something has to save the agent's state and continue exactly where it stopped.

That is what LangGraph does, and it is the runtime underneath create_agent. It runs the agent as a graph of steps and, when you give it a checkpointer, saves the state after each one. When a middleware needs a person, the graph pauses with an interrupt. When the answer arrives, the agent resumes from the checkpoint instead of starting over. You can also use LangGraph directly when your workflow is not a simple loop: branches, parallel steps, several agents.

6. You cannot see why an answer was bad

When an answer is wrong you need to know which prompt was sent, which passages were retrieved, which tools ran and what they returned. LangSmith, LangChain's hosted product, records a trace of every step and runs evaluations over sets of questions. Any tracing tool works; what matters is that you can see the steps.

What it costs

LangChain is a lot of abstraction, and it has changed fast. The original "chains" API now lives in a separate langchain-classic package, and code written two years ago often needs work to run on v1. When a call fails, you sometimes debug the framework before your own code.

For a single model and a single prompt, call the provider's SDK directly. LangChain pays off when you need several of the six at once: more than one provider, retrieval over your own data, an agent with tools, rules around its actions, or state that has to survive a pause.

How this differs from Claude Code

Claude Code, Codex CLI and Gemini CLI are agents too, so it is fair to ask how they relate. They sit one level up. LangChain is a toolkit for building an agent; Claude Code is a finished agent that you use. It already has the loop, tools for reading and editing files and running commands, permission prompts before risky actions, hooks around each action, and memory between sessions, all tuned for working on code on your own machine.

Use a finished agent when the job is work on your own machine. Use LangChain or LangGraph when you are building an AI feature into your own product, with your own tools, your choice of model and your own rules. Anthropic's Claude Agent SDK sits in between: Claude Code's loop and permission model as a library. Tools built on the Model Context Protocol (MCP) work with all of them.

The ideas are the same in each: the model proposes, a loop runs the tools, rules decide what is allowed, and state lets the work pause and resume. My own agent that drafts GitHub replies and waits for a Telegram tap before posting is the same pattern again, built by hand.