The LangChain Ecosystem in 2026: Why Three Frameworks Exist (And When to Use Each)

The Problem That Started Everything

import openai
def get_response(user_message: str, history: list) -> str:
    messages = [
        {"role": "system", "content": "You are a helpful customer support agent."}
    ]
    # Manually re-construct history every call
    for turn in history:
        messages.append({"role": "user", "content": turn["user"]})
        messages.append({"role": "assistant", "content": turn["assistant"]})
    messages.append({"role": "user", "content": user_message})
        response = openai.ChatCompletion.create(
        model="gpt-3.5-turbo",
        messages=messages
    )
    return response.choices[0].message["content"]

The Three-Layer Stack

Here is the architecture diagram with data flow:

Interview checkpoint If someone asked you right now: “What is the relationship between LangChain and LangGraph?” could you answer it in two sentences? If not, re-read the section above before continuing.

langchain-core: The Foundation That Never Dies

Every senior developer who has watched frameworks come and go knows to ask one question before they invest time in a new tool: which parts are stable?

For the LangChain ecosystem, the answer is langchain-core.

langchain-core contains the abstract base classes and protocols that every component in the ecosystem implements. ChatOpenAI, ChatAnthropic, ChatGoogleGenerativeAI They all implement BaseChatModel from langchain-core. PromptTemplate, ChatPromptTemplatethey implement BasePromptTemplate. Every retriever, every output parser, every chain in the ecosystem implements one common interface.

That interface is Runnable.

The Runnable Interface

Runnable is the type contract that makes the entire ecosystem composable. Any object that implements Runnable supports these methods.

class Runnable:
    def invoke(self, input, config=None)           # synchronous, single input
    def batch(self, inputs, config=None)           # synchronous, list of inputs
    async def ainvoke(self, input, config=None)    # async single input
    def stream(self, input, config=None)           # generator, yields chunks
    async def astream(self, input, config=None)    # async generator

Why does this matter? Because the calling code does not care what it is calling.

# This works with any Runnable — model, retriever, parser, tool
def run_component(component: Runnable, input_data: dict):
    return component.invoke(input_data)

Want to swap your LLM provider from OpenAI to Anthropic? The calling code does not change, because both implement Runnable. Want to mock a retriever in tests? Write a FakeRetriever that implements Runnable and returns fixed documents. The test code does not change. Want to stream a response instead of waiting for the whole thing? Call .stream() instead of the .invoke() same object, different method.

This is the interface that makes LangChain modular in a way that actually holds up under refactoring. BeforeRunnable, swapping components meant rewriting call sites. After Runnableswapping components is a one-line change.

Trace any arrow. The input type and return type are different for each Runnable, but the method signature (.invoke()) is always the same. That is the contract.

The Pipe Operator: What It Was and Why It Changed

If you have used LangChain 0.x, you have seen this pattern:

# Old pattern — LCEL pipe syntax (deprecated in LangChain 1.0)
chain = prompt | llm | StrOutputParser()
result = chain.invoke({"question": "What is RAG?"})

This is called LCEL: LangChain Expression Language. The | pipe operator chains Runnables so the output of each feeds as input to the next. It was elegant for simple chains.

The problem was of medium complexity. Three steps - fine. Seven steps with branching logic and middleware injection, you ended up with chains that were unreadable and impossible to debug. Adding a logging step in the middle required rethinking the whole pipe structure. Error handling was non-obvious. And when the pipe pattern met agents (which are loops, not pipelines), it started to break down conceptually.

LangChain 1.0 moved to create_agent() and explicit middleware for the agent use case. The Runnable interface still exists; it is in langchain-core and it is used everywhere inside LangGraph nodes. But the chain-as-pipe pattern is no longer the primary API. You will still see it in older code and in some retrieval setups. Understand it when you encounter it. Do not build new agent architecture on top of it.

The pipe operator is deprecated in LangChain 1.0. The Runnable interface it was built on is not. That distinction matters more than most tutorials acknowledge.

Content Blocks — The New Reality of Model Responses

Before LangChain 1.0, every model response came back as a string. You called .invoke(), you got anAIMessage, and it message.content was a string. Simple.

In 2025, modern models return structured content: text blocks, tool-use blocks, reasoning tokens (from models that expose chain-of-thought), citations, and image outputs. A single response might contain a reasoning block, then a text block, then a tool use block. Treating this as a flat string loses the structure.

LangChain 1.0 standardized this with content_blocks:

# Old world (still works for simple cases):
response = llm.invoke("What is 2+2?")
print(response.content)  # returns "4" as a string
# New world — multi-modal, multi-block responses:
response = llm.invoke("Analyze this data and call the chart tool.")
for block in response.content_blocks:
    if block.type == "thinking":
        # Extended thinking block — model's internal reasoning
        # Only present if thinking is enabled in model config
        print(f"Model reasoned: {block.thinking}")
    elif block.type == "text":
        print(f"Response text: {block.text}")
    elif block.type == "tool_use":
        # The model wants to call a tool
        print(f"Tool call: {block.name}, args: {block.input}")

This matters most if you are working with Anthropic’s extended thinking, with multi-modal models that generate images, or with any provider that returns citation metadata. If you are writing a wrapper around model responses and you assume .content is always a string, you will get [{'type': 'text', 'text': '...'}] Back when you expected "...". That bug is subtle and annoying. Know that content_blocks exists.

Interview checkpoint If someone asked you right now: “Why does the Runnable interface exist and what problem does it solve?" could you answer it in two sentences? If not, re-read the section above before continuing.

LangChain 1.0: The Fast Path to Agents

LangChain 0.3 tried to be a general-purpose LLM toolkit. Chains for everything. Memory modules for everything. Dozens of agent types. The result was a framework with a massive, confusing API surface where six different ways to do the same thing existed simultaneously, and the docs never quite told you which one was current.

The 1.0 rewrite started from a different question: what does every developer actually build?

Agents. Almost always agents. Some form of “take user input, let the model reason, call tools as needed, return a useful response.”

So LangChain 1.0 stripped down to a clean core and focused on one thing: making it fast and correct to build agents, with a clear customization path when the defaults are not enough.

What create_agent() Actually Builds

from langchain.agents import create_agent
from langchain_anthropic import ChatAnthropic
agent = create_agent(
    model="anthropic:claude-sonnet-4-20250514",
    tools=[web_search, calculator],
    system_prompt="You are a helpful research assistant.",
)
response = agent.invoke({
    "messages": [("user", "What is the current GDP of India?")]
})

Before you run this, understand each argument:

• model: accepts either a string identifier ("provider:model-id") or a BaseChatModel instance. The string format auto-resolves the provider and model. "anthropic:claude-sonnet-4-20250514" is equivalent to passing ChatAnthropic(model="claude-sonnet-4-20250514").
• tools: a list of Python functions decorated with@tool, or StructuredTool instances. When the model decides to call one of these, the agent loop handles the execution and feeds the result back automatically.
• system_prompt: injected as a system message before every model call in the loop. If you need this to be dynamic, injecting per-user context, for example, that is exactly where middleware comes in. More on that shortly.

What create_agent() actually builds? It compiles a StateGraph a LangGraph construct with this structure:

Follow the loop: model → tools → model → tools → model → end. This is the ReAct loop — reason, act, observe, repeat, formalized as a directed graph.

The conditional edge coming out of model_node is the key: if the model's response contains tool calls, route to tools_node. If not, route to __end__. The loop exits when the model decides it has enough information to answer.

This graph is compiled with a MemorySaver Checkpointer by default, which means, within a single session, conversation history is automatically persisted across invocations. You do not manage the message list manually.

AgentState - Why the Messages Field Has an Annotation

# AgentState is what flows through every node in the graph
from typing import Annotated
from langchain_core.messages import BaseMessage
from langgraph.graph.message import add_messages
class AgentState(TypedDict):
    messages: Annotated[list[BaseMessage], add_messages]
    # The annotation is not documentation. It is a reducer.
    # add_messages tells LangGraph: when a node returns new messages,
    # append them to this list rather than replacing the whole list.

The add_messages annotation is not cosmetic. It is functional. In LangGraph, when a node returns a value for a state field, the default behavior is to overwrite the field. If model_node returned {"messages": [new_message]}You would lose your entire conversation history.

add_messages is a reducer - it tells LangGraph to merge by appending, not overwriting. This is how tool call results, model responses, and user messages all accumulate in the same list across every loop iteration without manual management.

If you ever build a custom StateGraph and your messages keep getting wiped between nodes, this is why. Check your annotation.

Interview checkpoint If someone asked you: “What happens between the model_node and the tools_node in a create_agent() graph?" could you trace through it? If not, re-read the diagram above and the AgentState explanation before continuing.

The Middleware System: Context Engineering, Not Just Hooks

Here is the wall that every agent framework eventually hits.

You start with create_agent(). Results are good. You demo it internally, get positive feedback, and move toward production. Then the edge cases start showing up. The model starts making poor tool decisions when the conversation gets long. It calls the wrong tool when three tools have similar descriptions. It runs away with tool calls and burns through your budget on a single bad request.

The instinct is to blame the model. Ninety percent of the time, the real problem is that the context going into the model is too long, has irrelevant history, includes tool descriptions for tools that are not relevant to this particular request, or lacks user-specific information the model needs.

The old solution was to subclass the agent class and override internal methods. That worked until the framework updated, and your subclass broke. It coupled your application logic to framework internals in a fragile way.

Middleware is the clean solution to this problem.

How Middleware Executes

The execution model is identical to Express.js middleware. Sequential on the way in, reverse sequential on the way out:

User input
    ↓
[Middleware 1: before_model]   e.g. summarize old messages if token count > threshold
[Middleware 2: before_model]   e.g. inject user preferences from database
[Middleware 1,2: modify_model_request]   e.g. select relevant tools only, add cache headers
    ↓
LLM call
    ↓
[Middleware 2: after_model]   e.g. validate structured output schema
[Middleware 1: after_model]   e.g. check if human approval needed for this tool call
    ↓
Response

If you have ever used Flask or Express, you already understand this. The middleware stack is declared once when you build the agent. Every LLM call in every loop iteration runs through it.

The Three Hooks

from langchain.agents import AgentState
from langchain.agents.middleware import AgentMiddleware
class AgentMiddleware:
    def before_model(self, state: AgentState, runtime) -> AgentState:
        # Runs before LLM is called.
        # Receives the full agent state — including all messages so far.
        # Returns a (potentially modified) AgentState.
        # You can: trim messages, inject context, redirect to another node.
        ...
    def modify_model_request(self, request: ModelRequest) -> ModelRequest:
        # Runs right before the API call, after before_model.
        # Receives the actual request object about to be sent to the provider.
        # You can change: tools, system_prompt, messages, model, temperature,
        # output format, cache headers — anything in the request.
        # This is the most powerful hook for context engineering.
        ...
    def after_model(self, state: AgentState, runtime) -> AgentState:
        # Runs after the LLM responds.
        # Receives the updated state with the new AIMessage appended.
        # You can: inspect tool calls, pause for human approval,
        # validate output structure, update custom state fields.
        ...

Three hooks because there are three distinct moments in every LLM call where you need to intervene: before the state is finalized for the call, at the exact API request level, and after the response comes back. The distinction between before_model and modify_model_request matters. before_model works with the agent's state as a whole. modify_model_request works with the raw API parameters, the exact tools list, the exact system prompt, and the exact temperature. If you want to dynamically change which tools the model sees, you do it in modify_model_request.

The Built-in Middleware

LangChain 1.0 ships with these middleware classes out of the box:

• SummarizationMiddleware compresses old messages when the token count exceeds a configurable threshold. Runs in before_model.
• HumanInTheLoopMiddleware pauses execution when the model produces a tool call, surfaces it for human approval via a configurable callback.
• AnthropicPromptCachingMiddlewareadds cache_control headers to long system prompts. Reduces cost significantly on Anthropic models when the system prompt is large and stable.
• ModelCallLimitMiddlewareenforces a hard cap on total LLM calls per invocation. Prevents runaway agents.
• ToolCallLimitMiddlewareenforces a hard cap on tool calls specifically.
• PIIRedactionMiddlewarescans messages for PII patterns and redacts them before they reach the model.
• TodoMiddlewaregives the agent an internal scratchpad for planning steps. Used internally by DeepAgents; available standalone.
• ToolSelectorMiddleware uses a smaller, cheaper LLM to pre-filter the full tool list down to the relevant subset before the main model call. Reduces token cost and reduces the chance of tool confusion when you have many tools.
• ToolRetryMiddleware automatically retries failed tool executions with exponential backoff.
• ModelFallbackMiddlewarefalls back to a configured alternate model on provider errors or rate limits.

A Custom Middleware in Practice

Say every user of your application has a preference profile, preferred response length, topics they care about, and communication style. You want the agent to be aware of this without hard-coding it into the system prompt (because it is different per user).

from langchain.agents.middleware import AgentMiddleware
class UserContextMiddleware(AgentMiddleware):
    def __init__(self, user_id: str, preferences: dict):
        self.user_id = user_id
        self.preferences = preferences
    def modify_model_request(self, request):
        # Inject user-specific context into the system prompt.
        # This runs right before the API call — not once at agent creation,
        # but every single LLM call in the loop.
        user_context = (
            f"\n\nUser profile for {self.user_id}:\n"
            f"Preferred response length: {self.preferences.get('length', 'medium')}\n"
            f"Topics of interest: {', '.join(self.preferences.get('topics', []))}"
        )
        request.system_prompt = (request.system_prompt or "") + user_context
        return request
# Using it:
user_prefs = {"length": "brief", "topics": ["finance", "technology"]}
agent = create_agent(
    model="anthropic:claude-sonnet-4-20250514",
    tools=[web_search],
    middleware=[UserContextMiddleware(user_id="u_1234", preferences=user_prefs)],
)

What the model receives on every call: the base system prompt fromcreate_agent(), followed by the user's preference context, appended by modify_model_request. The agent object itself has no hard-coded user preferences. You instantiate a new agent (or a new middleware stack) per user session.

This is context engineering. Not prompt engineering that is about the words you choose. Context engineering is about the architecture of what the model sees, and when.

Read this sequence top to bottom. Notice that before_model and after_model run for each middleware in order, but modify_model_request runs in reverse order. The middleware closest to the LLM in the chain gets to make the final modification to the request.

The Limitation: Middleware Is Not a Graph

Middleware runs sequentially, in a defined order, on every LLM call. It cannot branch to different nodes. It cannot pause execution indefinitely while waiting for an external event. It cannot conditionally skip steps based on graph state.

If you find yourself wanting middleware that routes to different sub-graphs based on complex conditions, or middleware that needs to persist its own state across multiple agent invocations independently from the agent state, you have outgrown middleware. You are building a LangGraph workflow, and create_agent() is the wrong abstraction.

That transition is not a failure. It is the correct evolution.

Interview checkpoint If someone asked you: “What is the difference between before_model and modify_model_request?" could you explain it clearly? If not, re-read the three hooks section above.

LangGraph 1.0 vs LangChain 1.0: The Honest Decision Tree

Every few weeks, someone asks: “Should I be using LangChain or LangGraph for this?” The answer is always: it depends on how much control you need over the graph structure.

Here is the honest answer

The column on the right is not a recommendation. It is a boundary. When your use case falls in the left column, using LangGraph directly means writing graph boilerplate that create_agent() would have been handled for you. When your use case falls in the right column, using create_agent() means fighting the abstraction.

Start at the top and follow the decisions. The rightmost nodes are not worse options — they are the correct tools for those specific requirements.

One more thing. LangGraph’s killer feature that create_agent() does not expose is time travel. Because LangGraph persists every state transition as a checkpoint, you can replay any execution from any previous point in time. For debugging a production agent that made a wrong decision three tool calls into a session, this is invaluable. LangChain’s MemorySaver gives you in-memory state for the current session. LangGraph's PostgresSaver gives you permanent, queryable state across all sessions, all time.

If you are building anything production-grade, understand what PostgresSaver gives you. We will go deep on the checkpoint lifecycle in Blog 3.

LangSmith: Non-Optional in Production

There is a version of this blog where LangSmith gets a footnote. This is not that version.

Here is the reality: a LangChain agent running in production without LangSmith is a black box. You know it returned an answer. You do not know which tools it called, how many tokens it used, what the full prompt looked like when it reached the model, whether the middleware ran correctly, or why it sometimes gives worse answers at 2x the cost. You are guessing.

LangSmith records a trace for every execution. A trace is a tree: at the root, the full agent invocation. Branching into it: middleware calls, model calls (with the full rendered prompt), tool calls (with inputs and outputs), nested sub-calls. Every node in the trace has: inputs, outputs, latency, token count, and cost.

The setup is four lines. Do this before you write any agent code:

import os
os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = "your-langsmith-api-key"
os.environ["LANGCHAIN_PROJECT"] = "my-agent-project"
# That's it. No instrumentation. No decorators.
# Every LangChain/LangGraph call is now automatically traced.

No code changes. No decorators. No wrappers. Once those three environment variables are set, the entire LangChain and LangGraph runtime traces automatically. The trace data appears in the LangSmith web UI within seconds.

📹 What this looks like in motion: Open the LangSmith UI while your agent is running. You will see a trace entry appear as soon as the invocation starts. It expands in real time: the middleware calls appear first, then the model call populates with the full rendered system prompt and message list — exactly what the model received. When the model returns tool calls, a child node appears for the tool execution. As the loop continues, the tree grows. By the time the agent returns a final response, you have a complete audit of every decision, every token, every tool result. If something goes wrong, you can find exactly which hop caused it in under a minute.

What LangSmith is not: a production monitoring platform for SLA tracking or alerting. For that, you still need standard observability tooling (Datadog, Grafana, whatever your stack uses). LangSmith is specifically for LLM application debugging, understanding why an agent made the decisions it made.

Use LangSmith for development. Use it for production tracing. Use it to build evaluation datasets (you can flag traces and export them as test cases). Use it to compare prompt versions. It is the tool that transforms “I think my agent is working” into “I know exactly what my agent is doing.”

What You Now Understand

After reading this blog, you now understand:

Why LangChain 1.0 is a focused rewrite, not a new framework, and why the focus on agents specifically was the right call.

That create_agent() compiles a LangGraph StateGraph internally, you are always on LangGraph's runtime, always running the ReAct loop, just with varying levels of visibility into the graph structure.

That langchain-core is the stable foundation, the Runnable interface and message types are what make every component in the ecosystem swappable, and they are not going anywhere.

That middleware is context engineering; the real leverage is not in writing better prompts but in dynamically controlling what the model sees on every call, based on the state of the conversation.

That the LangChain/LangGraph/DeepAgents split is a decision tree, not a preference, and now you have the criteria to make that decision correctly.

That LangSmith is not optional in production, and setting it up costs four lines of code.

What Comes Next

You now have the mental model. You can draw the stack. You can explain why the three layers exist. You understand the Runnable contract, what create_agent() builds, and why middleware solves a real problem that subclassing never solved cleanly.

The next blog goes one level deeper: memory. Specifically, the distinction between in-context memory (the messages the model sees right now), checkpoint-based memory (conversation history that persists across sessions), and long-term memory (facts about a user that should inform responses months from now). These are three fundamentally different mechanisms. Most developers conflate them. The conflation causes the most common class of production agent bugs.

Knowing which type of memory your use case needs and why is what Blog 2 is about.

This blog is part of a six-part series: Learning LangChain 1.0 by building real systems. If something is wrong, imprecise, or could be explained better, tell me in the comments — I am learning publicly, and corrections are welcome.

References

Everything in this blog is grounded in official documentation and release announcements. If you want to go deeper into any section, these are the primary sources.

LangChain 1.0: Official Announcements

LangChain Team. LangChain & LangGraph 1.0 Alpha Releases (September 2, 2025). The original announcement of the 1.0 rewrite, including the reasoning behind the create_agent() redesign and the introduction of content_blockshttps://blog.langchain.com/langchain-langchain-1-0-alpha-releases/

LangChain Team. LangChain 1.0 Now Generally Available (October 29, 2025). The stable release announcement covers the middleware system, structured output improvements, and the langchain-classic package for backwards compatibility. https://changelog.langchain.com/announcements/langchain-1-0-now-generally-available

LangChain Team. LangGraph 1.0 Now Generally Available (October 22, 2025). Covers durable execution, built-in persistence, and the promotion of langgraph.prebuilt functionality intolangchain.agents. https://changelog.langchain.com/announcements/langgraph-1-0-is-now-generally-available

Official Documentation

LangChain Docs. LangChain Overview : create_agent() quickstart and core concepts. https://docs.langchain.com/oss/python/langchain/overview

LangChain Docs. Memory and Persistence: Checkpointers, InMemorySaver, PostgresSaver, and cross-session state. https://docs.langchain.com/oss/python/langgraph/add-memory

LangChain Reference. langchain-core checkpoint API : BaseCheckpointSaverserialization protocols, checkpoint data structures. https://reference.langchain.com/python/langgraph/checkpoints

Source Repositories

LangChain AI. langchain-ai/langchain : GitHub. Source for langchain-core, langchain, and langchain-classic packages. The releases tab is the most reliable way to track what changed between versions. https://github.com/langchain-ai/langchain

LangChain AI. langchain-ai/langgraph: GitHub. Source for StateGraph, all checkpointer implementations, and the LangGraph runtime. https://github.com/langchain-ai/langgraph

LangChain AI. langchain-ai/deepagents: GitHub. Source for TodoMiddleware, the filesystem backend, and subagent spawning. https://github.com/langchain-ai/deepagents

LangSmith

LangChain. LangSmith: Agent Engineering Platform. Tracing setup, evaluation tooling, and production observability for LangChain and LangGraph applications. https://www.langchain.com/langsmith