LangChain in 2026: When to Use It, When to Skip It

Updated May 2026. Rewritten with three years of production LangChain experience: what it replaced, where it fell down, and the Claude Agent SDK / OpenAI Agents SDK / LangGraph alternatives we now reach for first.

LangChain is an open-source Python and JavaScript framework for building applications on top of large language models. That definition has not changed since 2022. What has changed is everything around it: provider SDKs got better, the framework got bigger, the agent landscape multiplied, and the question “should I use LangChain” went from obvious yes to “it depends, and most of the time, no”.

We are a Brisbane-based AI consultancy and we have shipped LangChain in production for clients since 2023. This guide is what we wish we had read in 2024. It covers what LangChain actually solves, where it falls down at scale, and what the 2026 alternatives are when you do not need the abstraction layer.

Related reading: our guide to building an AI agent on Claude, our guide to OpenAI’s agent stack, and our piece on building AI agents in Python without a framework.

What LangChain Actually Is

LangChain is an abstraction layer over LLM providers, plus a library of patterns for the common building blocks: prompts, retrieval, memory, tool calls, chains of operations, and agents. In 2022 those abstractions were genuinely useful because every provider’s API was different and the common patterns were not in any standard library.

In 2026 the provider SDKs are mature, structured outputs are first-class, tool calling is standardised across the major providers, and the “common patterns” have been built into the SDKs themselves. The case for an abstraction layer is narrower than it was.

The LangChain ecosystem in 2026 actually splits into three pieces:

• LangChain core. The original framework. Chains, prompts, retrievers, output parsers, document loaders. Still maintained, still widely used, less essential than it was.
• LangGraph. The agent and stateful workflow part, spun out into its own framework. This is the part of the LangChain ecosystem that gained ground in 2025. We use it on production builds where the workflow is genuinely a graph.
• LangSmith. The hosted observability and evals product. Separate price point, separate decision. Useful if you have not already standardised on something else.

When people ask “what is LangChain” in 2026, they usually mean one of those three. The answer depends on which.

When LangChain Is the Right Call in 2026

Three cases where we still reach for LangChain (or LangGraph) first.

Multi-provider routing. If you genuinely need to fall back from Claude to GPT to a self-hosted Llama based on cost, latency, or availability, LangChain’s provider abstraction earns its keep. We have one client running this pattern for cost optimisation across Claude Sonnet 4.5, GPT-4o-mini, and a fine-tuned Llama 3.3.

Document loaders for messy enterprise sources. SharePoint, Confluence, Notion, Slack, S3, every flavour of database. LangChain has a loader for almost everything. Writing those yourself is a week each. Using the loader is an hour each.

Complex stateful workflows with LangGraph. When the workflow is genuinely a graph (multiple agents, conditional routing, human-in-the-loop checkpoints, durable state), LangGraph is the cleanest way to express it in Python. Our piece on AI workflow patterns in n8n covers when n8n is the better choice for the same pattern.

Where LangChain Falls Down

Three places where we have stopped using LangChain on new builds. None of these are LangChain doing anything wrong. They are situations where the abstraction layer costs more than it pays.

Simple agent loops. A two-tool, one-LLM agent is 50 lines of Python directly against the Anthropic or OpenAI SDK. The LangChain equivalent is 50 lines plus a stack of abstractions you have to understand to debug it when it breaks. The Claude Agent SDK and OpenAI Agents SDK both ship agent loops as a primitive now. We default to those.

Single-provider builds. If you have committed to Claude or to GPT for the next two years, the provider SDK gives you the same primitives without the version churn that LangChain has experienced. We have hit four LangChain-breaking version updates in three years on production builds. Provider SDKs change more slowly.

Performance-sensitive paths. LangChain adds non-trivial overhead. For a high-throughput service hitting an LLM thousands of times per minute, the framework layer matters. We have measured 30 to 80ms of extra latency per call on standard LangChain agent setups versus a direct SDK call.

Working LangChain Example: RAG Over Policies

Here is a compact production-style example. RAG over an internal policy library, using LangChain 0.3 with the OpenAI embedding model and Claude Sonnet 4.5 as the generator.

from langchain_anthropic import ChatAnthropic
from langchain_openai import OpenAIEmbeddings
from langchain_postgres import PGVector
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough
from langchain_core.output_parsers import StrOutputParser

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = PGVector(
    connection_string="postgresql://...",
    collection_name="policies",
    embedding_function=embeddings,
)
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})

llm = ChatAnthropic(model="claude-sonnet-4-5", temperature=0)

prompt = ChatPromptTemplate.from_messages([
    ("system", "Answer using only the policy excerpts. Cite the policy ID for every claim. If the policies do not cover the question, say so."),
    ("human", "Context:\n{context}\n\nQuestion: {question}"),
])

chain = (
    {"context": retriever, "question": RunnablePassthrough()}
    | prompt
    | llm
    | StrOutputParser()
)

answer = chain.invoke("What is our refund policy for AU customers?")

This is a fair amount of LangChain doing real work: the PGVector retriever, the prompt template, the chain composition. It is also where the framework genuinely earns its keep. Writing the equivalent against the raw Anthropic SDK plus psycopg plus an embedding call is twice as long and worse documented.

LangChain Alternatives in 2026

Five frameworks we evaluate against LangChain for new builds. Each wins in a specific scenario.

Claude Agent SDK. Anthropic’s official agent framework. First-class tool use, first-class subagent support, hosted observability. Best for builds that are committed to Claude as the primary model. Smaller surface area than LangChain. Lower learning curve.

OpenAI Agents SDK. The OpenAI equivalent. Same trade-offs: smaller, opinionated, ties you to the provider. Best for builds where most of the stack is GPT plus OpenAI hosted vector stores.

LlamaIndex. Spiritual cousin of LangChain. Stronger on data ingestion and retrieval, weaker on agents. We sometimes pick LlamaIndex specifically for RAG-heavy builds with diverse data sources.

Pydantic AI. A newer framework leaning heavily on Pydantic’s type-safety. Excellent for builds where structured output and type validation matter (extraction, classification, anything that hands data to downstream systems).

Raw provider SDKs. No framework at all. The Anthropic Python SDK and OpenAI Python SDK are good enough for most simple builds. We ship more code without LangChain than with it now.

LangChain vs LangGraph vs LangSmith

The most common question we get from engineering teams new to LangChain.

LangChain is the original. Chains, prompts, retrievers, agents. The agent piece of LangChain has been largely superseded by LangGraph.

LangGraph is a separate framework from the same team, focused on stateful agent workflows expressed as graphs. Better than LangChain’s original agent abstraction. Worth picking up if you build agents with branching logic, parallel execution, or durable state. Our existing pattern docs on autonomous AI agents cover when this complexity is warranted.

LangSmith is the hosted observability product. Trace storage, eval framework, prompt regression testing. Useful, paid, and not required to use LangChain or LangGraph. Free tiers exist. We have clients who use LangChain without LangSmith and clients who use LangSmith without LangChain.

LangChain Production Gotchas

Things we have hit in production that are worth flagging.

• Version churn. LangChain 0.1, 0.2, 0.3 each shipped breaking changes. Pin langchain, langchain-core, and every langchain-* integration package. Upgrade deliberately, not automatically.
• Hidden retries. Some integrations retry silently on rate limit. Set retry config explicitly. We had a build burn through a quarter of a daily token budget on a single user query because of an accidentally exponential retry.
• Streaming surprises. The streaming interface across providers is harmonised but not identical. Test streaming endpoints under the actual network conditions your users have.
• Tool name collisions. When you compose agents from multiple tool sets, name collisions are silent. We name every tool with a verb-noun-domain pattern (search_policies_au) to avoid surprises.
• Memory leaks in long-running services. LangChain callbacks can hold references longer than you expect. We had a worker process grow from 200MB to 4GB over 48 hours until we audited callback handlers.

LangChain Costs in AUD

The framework itself is free and open-source. The costs come from what it calls and where it runs.

• LLM tokens. Whatever Anthropic, OpenAI, or your other provider charges. LangChain adds zero. A typical RAG service running at 50,000 queries per month costs $200 to $600 AUD in inference.
• Vector store. Pinecone, Qdrant, or self-hosted pgvector. $0 to $200 AUD per month for under 1M vectors.
• LangSmith (optional). Free tier covers low-volume builds. Paid tiers start around $39 USD per user per month, roughly $60 AUD.
• Hosting. Render, Fly.io, Railway, or your existing cloud. $20 to $300 AUD per month for a modest LangChain service.

When LangChain Is the Wrong Choice

Five cases where we recommend something else.

• You only need one LLM call. Use the provider SDK directly. The framework overhead is not worth it for a single API call.
• You are not a Python or JavaScript shop. LangChain’s Go, Rust, and Ruby ports lag the main libraries badly. Use a provider SDK in your language.
• The workflow is genuinely visual. n8n or Make with the AI nodes can ship the same workflow in a quarter of the time, with non-engineers able to maintain it.
• You need extreme low latency. Direct SDK calls or a fine-tuned smaller model self-hosted.
• The team has not written Python in production. LangChain magnifies Python complexity. If your team is mostly TypeScript, use LangChain.js or skip LangChain entirely.

Want a second opinion on whether LangChain belongs in your stack? Send us a note via the contact page or book a call. We have shipped enough LangChain in production to tell you honestly whether the abstraction is paying for itself in your context.

Frequently Asked Questions

What is LangChain in plain English?

LangChain is an open-source Python and JavaScript framework for building applications on top of large language models. It provides pre-built components for prompts, retrieval, memory, tool calls, and chains of operations, so you do not have to write the plumbing from scratch.

Is LangChain still relevant in 2026?

Yes, but less central than it was. The provider SDKs (Anthropic, OpenAI) have absorbed many of LangChain’s primitives. LangGraph (the agent piece spun out separately) remains very relevant for stateful workflows. The core LangChain framework is still useful for RAG and multi-provider routing.

LangChain vs LlamaIndex: which is better?

LlamaIndex is stronger for data ingestion and retrieval over diverse sources. LangChain is broader, covering chains, agents, and orchestration. For pure RAG-heavy work on messy data, LlamaIndex. For multi-pattern apps that include agents, LangChain or LangGraph. Many teams use both.

Is LangChain free to use?

Yes. The framework is MIT-licensed and free. You pay for the underlying LLM tokens (Anthropic, OpenAI), for any vector store, and optionally for LangSmith if you choose to use the hosted observability product.

Do I need LangChain to build an AI agent?

No. The Claude Agent SDK and OpenAI Agents SDK both ship agent loops as a primitive in 2026. For most single-provider builds we recommend the provider SDK over LangChain. LangChain or LangGraph wins on multi-provider routing or genuinely complex stateful graphs.

What language is LangChain written in?

The two first-class libraries are Python (langchain) and JavaScript / TypeScript (langchain.js). Ports exist for Go, Ruby, and others, but they lag the main libraries in features and stability. Pick Python or JavaScript for serious work.

How do I learn LangChain?

The official docs at python.langchain.com are the right starting point. After that, build a real project: a RAG over your own documents or a small agent that uses two tools. Reading without building does not teach LangChain. Most of what you learn comes from debugging your own code.

What is the biggest mistake teams make with LangChain?

Picking LangChain when a 30-line direct SDK call would have done the job. The framework earns its keep on RAG, multi-provider routing, and stateful graphs. Outside those, it tends to add complexity without adding capability. Start with the provider SDK, add LangChain when you can name the specific abstraction you need.