The LangChain You Learned in 2024 Doesn't Exist Anymore

Priyansh Singhal — Wed, 23 Sep 2026 09:23:46 +0000

LLMChain and its siblings moved to a legacy package. The new core is one function, create_agent, plus middleware.

Open a LangChain tutorial from 2024, follow it against a fresh install, and the imports fail before you write any logic. LLMChain is not in the main package anymore. Neither is initialize_agent, nor most of the chain zoo that tutorials spent two years teaching. That is not deprecation drift. It was a deliberate rebuild: in October 2025 LangChain shipped 1.0 and cut the framework down to what its team calls essential abstractions, moving everything else into a separate legacy package.

I hit this wall while working through the agentic AI stage of my own learning roadmap, with a browser full of tutorials describing a library that no longer matches what pip installs. This article is the map I wanted that week: what actually changed, what the new core looks like, and how to read older material without getting burned.

What 1.0 actually changed

LangChain 1.0 went generally available on October 22, 2025, alongside LangGraph 1.0. Two changes matter more than the version number.

First, the scope cut. The main langchain package no longer tries to be a warehouse of every chain pattern from the last three years. It focuses on agents, models, messages, and tools. Everything legacy, including LLMChain and the old pre-built chains, moved to a package literally named langchain-classic (@langchain/classic in JavaScript). Old code did not stop existing, it changed address. In current code the old import reads from langchain_classic.chains import LLMChain, and that rename is doing honest work: the framework is telling you this is the museum wing.

Second, a stability promise. 1.0 commits to no breaking changes until 2.0. That sounds boring, but for a library famous for breaking tutorials every few months it is arguably the biggest feature in the release. What you learn on the 1.x core should keep compiling for a while.

The reason for the cut is visible in what survived. Chains were LangChain's answer to a 2023 question: how do I glue prompts together? The 2026 question is different, how do I run a model in a loop with tools, safely. Agents won, and the package now says so.

The new core is one function

Here is a complete working agent on the current API, straight from the quickstart shape in the docs. One prerequisite the snippet itself won't remind you of: export the API key for whichever provider you're calling first (ANTHROPIC_API_KEY, OPENAI_API_KEY, and so on), or the agent has nothing to authenticate with.

from langchain.agents import create_agent

def get_weather(city: str) -> str:
    """Get weather for a given city."""
    return f"It's always sunny in {city}!"

agent = create_agent(
    model="anthropic:claude-sonnet-4-6",
    tools=[get_weather],
    system_prompt="You are a helpful assistant",
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "What's the weather in San Francisco?"}]}
)
print(result["messages"][-1].content_blocks)

create_agent is the whole story. You hand it a model, a list of plain Python functions as tools, and a system prompt. The model argument is a provider-prefixed string ("anthropic:claude-sonnet-4-6", "openai:gpt-5.5", or any "ollama:" model tag), which makes trying your agent against a local model a one-line experiment. At runtime it loops: the model reads the messages and either emits tool calls or a final answer. Tool calls get executed, their results are appended to the message list as tool messages, and the model runs again. A response with no tool calls ends the loop.

Two details worth knowing before you build anything real. This function replaces create_react_agent from LangGraph, which is now deprecated, so treat any tutorial teaching that name as pre-1.0. And it runs on the LangGraph runtime underneath, which matters later. Note also content_blocks on the final message: 1.0's standardized way to read reasoning traces, citations, and tool calls in one consistent shape across providers.

Middleware is the actual headline

create_agent got the announcement-post attention. The part I think matters more day to day is middleware, which the docs describe as hooks that let you customize behavior at every step of the agent loop.

Before 1.0, controlling the middle of an agent's execution meant callback handlers, subclassing, or forking a prebuilt graph. Most tutorials just skipped the problem. Now there are three obvious seams, named for exactly where they cut in:

@before_model runs before each model call. This is where you trim context or enforce a call budget. The docs' own example counts model calls in state and jumps to the end past a limit, which is a real runaway-agent guard in about ten lines.
@after_model runs after each model response, before anything acts on it. Output validation and redaction live here.
@wrap_tool_call wraps each tool execution like an HTTP middleware wraps a request. You get the request, you own calling the handler, you can log, retry, or replace the result.

There are also built-ins for the three things everyone eventually hand-rolls: human-in-the-loop approval for dangerous tools, PII redaction, and conversation summarization. The human-in-the-loop one is configured per tool, so HumanInTheLoopMiddleware(interrupt_on={"send_email": True}) pauses the loop for approval before that one tool fires while every read-only tool runs untouched. One catch before you demo it: the pause is a LangGraph interrupt underneath, so the middleware line alone does not give you a working approval flow. You also need a checkpointer attached to the agent (InMemorySaver for local work, something persistent in production) and a thread ID passed with every invoke, and resuming means calling the agent again with a Command carrying the decision. Three extra lines, but the docs only make this clear once you are deep in the human-in-the-loop page, and every demo that skips them dies at the first pause. The summarization one is configured with a token threshold and a keep-last-N-messages count, and it quietly solves the failure mode where a long-running agent drowns in its own history. That used to be a weekend of custom code. My honest read: if you evaluate LangChain 1.0 by create_agent alone it looks like a nicer constructor, and the middleware system is the actual argument for using the framework instead of writing the loop yourself.

How to read old tutorials without getting burned

A practical triage, since most LangChain material online is still pre-1.0:

Date the code, not the post. Anything showing LLMChain, initialize_agent, or create_react_agent predates October 2025 in spirit, whatever its publish date says. The concepts often still transfer. The imports will not.

Treat langchain-classic as an escape hatch, not a destination. It exists so working systems keep running, and if you maintain one, updating an import path beats a rewrite. I would not point new code at it. You would be learning the museum wing while the actual exhibit is one function with clean seams.

Expect some patterns to have moved into the loop. Structured output is the clearest example: it now happens inside the main agent loop rather than as a separate follow-up LLM call, which is one less round trip and one less place to disagree with your own schema. If a tutorial bolts an output parser onto the end of a chain, that is the old world showing.

Where LangChain ends and LangGraph begins

The framework's own framing is that you start with LangChain's high-level API and drop down to LangGraph when you need more control. In practice the boundary is shape: one model looping over tools is create_agent territory, even with heavy middleware. The moment you need multiple agents, branching workflows, or explicit state machines, you are describing a graph, and pretending otherwise just means building a graph badly out of middleware.

The two worlds compose rather than compete. An agent built with create_agent can be added as a single node inside a LangGraph StateGraph, middleware and all, so graduating to a graph does not mean rewriting the agent you already have. You wire it in next to your routing and classification nodes and it keeps behaving exactly as it did standalone.

Which suggests a learning order I wish more roadmaps made explicit. Learn the loop first, then middleware, and only then LangGraph. Every graph node you will ever write is easier to reason about once you can explain what one agent loop does, because underneath, that is what is running.

If you are working through this stage yourself and want to talk through any of it live, I keep a slot open on Topmate.