LangChain Alternatives: 11 Agent Frameworks Compared (2026)

The best alternative depends on why you want to leave. If LangChain feels too abstract for a tool-calling agent, look at Pydantic AI, the OpenAI Agents SDK or Promptise Foundry. If you need explicit control flow and durable runs, LangGraph is the closest step. For teams of agents, CrewAI. For retrieval over your documents, LlamaIndex or Haystack.

The effort column is our estimate of how much of a typical LangChain agent carries over.

• Check the current LangChain first. LangChain 1.0 (October 2025) slimmed the package down to one agent constructor, create_agent, plus middleware. Many "leave LangChain" articles describe the 0.x versions.

• A small agent moves quickly. The tool functions and the system prompt carry over. The agent setup, memory wiring and tracing are what you rewrite.

• Serve tools over MCP to stay portable. Every alternative here can call MCP tools, so the next switch won't touch them.

• Stay if LangChain works for you. Its integration list is among the largest, and 1.x promises no breaking changes until 2.0.

For the best AI agent frameworks ranked by use case, with the same agent built in nine of them, see Best AI agent frameworks (2026).

The complaints are consistent across years of public discussion, and LangChain's team has acknowledged several.

• Abstraction overhead. In 2023, Max Woolf argued that LangChain makes simple things more complex than calling the provider's SDK directly. A widely discussed 2024 Hacker News thread about a team that dropped LangChain is full of comments about digging through layers of classes to change a small detail. As late as October 2025, a LangChain forum post asked why simple model calls need so many abstractions.

• Debugging. The same thread describes not seeing what each step sent to the model, and trouble adding logging between calls.

• Breaking changes and package churn. The v1 migration guide lists the changes: create_react_agent became create_agent, prompt= became system_prompt=, hooks became middleware, and chains, retrievers and the hub moved to a separate langchain-classic package. In 1.4 the MCP client moved from the separate langchain-mcp-adapters package to a beta langchain.mcp module.

• Two layers to learn. A LangChain agent runs on LangGraph, so advanced features such as interrupts and checkpoints mean learning both.

What changed in LangChain 1.x

Be fair to the current version before you leave. The 1.0 announcement (October 22, 2025) says the team heard that its abstractions were sometimes too heavy. 1.0 answered with one agent constructor, create_agent, middleware for approvals, summarization, PII redaction and call limits, and a much smaller namespace. The versioning policy makes 1.x a long-term release with no breaking changes until 2.0, and keeps 0.3 in maintenance until December 2026. If your pain is with 0.x code, upgrading to 1.x may solve it without a switch.

A LangChain agent is a stack of parts. An alternative has to cover the parts you use.

┌────────────────────────────────────────────────────────────────┐
│ your app: API, UI, auth                                        │
├────────────────────────────────────────────────────────────────┤
│ agent loop        create_agent + middleware (runs on LangGraph)│
│ memory            checkpointer + thread_id                     │
│ prompts           system_prompt string, templates              │
│ tools             @tool functions, MCP tools via an adapter    │
│ models            ChatOpenAI, ChatAnthropic, init_chat_model   │
│ retrieval         loaders, splitters, vector stores            │
├────────────────────────────────────────────────────────────────┤
│ tracing and deployment: LangSmith (optional, hosted)           │
└────────────────────────────────────────────────────────────────┘

Most alternatives replace the top four layers: the loop, memory, prompts and tools. Few replace the integration layers, which is why some teams keep LangChain's models and document loaders and move only the agent. What is an agent framework explains each layer.

Get the tool layer right. A plain Python function, or a tool on an MCP server, moves to any framework. A tool that depends on LangChain classes needs rework.

Stay when:

• You are on LangChain 1.x and the agent works. Middleware covers approvals, limits and summarization, and the API is stable until 2.0.

• You depend on many integrations: model providers, document loaders and vector stores behind one interface.

• You already use LangSmith for tracing, evaluation and deployment, and it fits your budget and data rules.

• You need durable runs that pause for days. LangGraph's checkpointers are among the most mature options.

Consider switching when:

• You are still on 0.x and would rewrite the agent anyway.

• You want strict types on inputs and outputs (Pydantic AI), the shortest path on OpenAI (Agents SDK), or a team-of-agents model (CrewAI).

• Your team spends more time on framework internals than on agent behavior.

• You need features around the agent that LangChain leaves to you, such as an MCP server framework, cost budgets or a project runner.

Versions were checked on PyPI on 20 October 2026, and each profile comes from the project's own documentation.

LangGraph (staying in the ecosystem)

LangGraph 1.2 is the lower-level runtime under LangChain agents. You define state, nodes and edges, and compile the graph with a checkpointer. Pick it when your workflow has real branches, parallel steps or human pauses that must survive a restart. It keeps LangChain's concepts but hides nothing: every step is code you wrote, at the cost of more wiring for simple agents. LangGraph alternatives covers the options if the graph itself is the problem.

Pydantic AI

Pydantic AI 2.58 treats an agent as a typed function: validated dependencies in, validated output out. Tools are plain functions, limits cover requests, tokens and tool calls, and approvals use deferred tools. It has an MCP client, supports many providers, and integrates with Temporal, DBOS and Prefect for durable runs. Pick it if your team likes Pydantic and wants type errors before runtime.

OpenAI Agents SDK

The OpenAI Agents SDK 0.24 is a small library around agents, handoffs, guardrails and sessions. MCP servers are built in, and approvals pause a run into a serializable RunState. Other providers work through adapters, but it is designed around OpenAI, and its tracing exports to OpenAI by default. Pick it for the least code on OpenAI models.

CrewAI

CrewAI 1.15 describes agents by role, goal and backstory and groups them into crews that work through tasks, in sequence or under a manager agent. Flows add event-driven steps with persisted state, and MCP servers plug in with mcps=. It sends anonymous telemetry unless you set CREWAI_DISABLE_TELEMETRY=true. Pick it when your problem maps to a team. See CrewAI alternatives for the reverse view.

LlamaIndex

LlamaIndex 0.14 started as a data framework and still centers on indexing and querying your data. Its agents run as event-driven workflows, AgentWorkflow hands work between agents, and MCP tools come from llama-index-tools-mcp. Pick it when your agent mostly searches and reasons over documents.

Haystack

Haystack by deepset builds applications from components connected in pipelines. Version 3.0 (July 2026) moved the Agent component to the center, with hooks around model and tool calls, and itself had breaking changes. AgentTool lets one agent call another, and mcp-haystack provides MCPToolset. Tracing is off by default and supports OpenTelemetry, Datadog and Langfuse. Pick it for search-heavy production systems.

smolagents

smolagents 1.26, from Hugging Face, is a small library whose main agent, CodeAgent, writes Python code as its action instead of JSON tool calls. It has managed agents and an MCP client, which in 1.26 needs mcp<2, and its docs recommend a sandbox such as E2B or Docker for the generated code. Pick it for code-writing agents. Its latest release is from May 2026.

DSPy

DSPy 3.4 solves a different problem. You declare what each step takes and returns, and its optimizers, such as MIPROv2 and GEPA, tune the prompts against your metric. It has a ReAct module, converts MCP tools with dspy.Tool.from_mcp_tool, and traces through MLflow. Pick it when quality on a measurable task matters more than orchestration; you can use it alongside an agent framework.

Microsoft Agent Framework (formerly AutoGen and Semantic Kernel)

Microsoft Agent Framework 1.22 is the successor to AutoGen and Semantic Kernel, built by the same teams. It has agents, graph workflows with checkpoints, middleware, MCP tools and OpenTelemetry built in, for Python and .NET, with Go in preview. AutoGen's repository now says it is archived. Pick it for Azure and .NET teams; migrate from AutoGen covers that path.

Google Agent Development Kit (ADK)

Google ADK 2.12 has LLM agents plus workflow agents that run sub-agents in sequence, in parallel or in a loop, and 2.0 added graph workflows. McpToolset connects MCP servers. It runs in Python, TypeScript, Go, Java and Kotlin, supports other models through adapters, and deploys to Google Cloud. Pick it when you build on Gemini.

Promptise Foundry

Promptise Foundry 1.4, which we make, builds an agent from MCP servers and LangChain tools with one call, build_agent(), and adds approvals, budgets, guardrails, sandboxed code execution, an MCP server framework and promptise run for deployment. It depends on LangChain's packages and accepts LangChain chat models and @tool objects unchanged, so it replaces how you build and run agents, not the LangChain library. Two limits: a pending approval waits in the running process and doesn't survive a restart, and 1.4 pins mcp<2, so it can't share an environment with langchain[mcp] 1.4.

Other options in other lists

• No framework. For one model call or two read-only tools, the provider SDK and a short loop are easier to debug. How to build an AI agent in Python writes the loop by hand.

• Vendor SDKs and other languages: the Claude Agent SDK; Mastra and the Vercel AI SDK for TypeScript.

• Visual builders: Flowise, Langflow and n8n suit prototypes and automations more than code-first agents.

Each cell comes from the project's documentation. "Opt-in" means nothing is sent until you configure it.

• Python 3.11 or later (Pydantic AI requires it) and an OpenAI API key in OPENAI_API_KEY. Every example uses gpt-5-mini.

• One virtual environment per framework, so their dependencies don't collide:

pip install "langchain==1.4.6" "langchain-openai==1.7.2" "langgraph==1.2.16"   # LangChain
pip install "pydantic-ai-slim[openai]==2.58.0"                                 # Pydantic AI
pip install "openai-agents==0.24.0"                                            # OpenAI Agents SDK
pip install "promptise==1.4.3"                                                 # Promptise Foundry

The agent answers order questions with two tools, and it must remember the conversation: the second question, "Can I still return it?", only makes sense if it remembers which order "it" is. That covers the three things every migration moves: tools, the prompt and memory.

The tools are plain functions with type hints and docstrings, and nothing in this file imports a framework:

"""Shared by every version: two plain Python tools, the prompt and the questions."""
from datetime import date, timedelta

TODAY = date(2026, 10, 20)  # fixed so the example gives the same answer every day
ORDERS = {
    "O-1001": {"item": "Desk lamp", "amount_usd": 49.00, "status": "delivered", "delivered_on": "2026-10-02"},
    "O-1002": {"item": "Office chair", "amount_usd": 219.00, "status": "in transit", "eta": "2026-10-23"},
}

PROMPT = "You are a support agent for an online store. Use the tools. Answer in one or two short sentences."
QUESTIONS = ["What's the status of order O-1001?", "Can I still return it?"]


def get_order(order_id: str) -> dict:
    """Look up an order by ID: item, amount in USD, status and dates."""
    return ORDERS.get(order_id.strip().upper(), {"error": f"No order {order_id}"})


def return_window(order_id: str) -> dict:
    """Check whether an order can still be returned, and until which date."""
    order = ORDERS.get(order_id.strip().upper())
    if order is None:
        return {"error": f"No order {order_id}"}
    if "delivered_on" not in order:
        return {"returnable": False, "reason": "Returns open once the order is delivered."}
    last_day = date.fromisoformat(order["delivered_on"]) + timedelta(days=30)
    return {"returnable": TODAY <= last_day, "last_day": last_day.isoformat(), "days_left": (last_day - TODAY).days}

LangChain

import asyncio

from langchain.agents import create_agent
from langchain.tools import tool
from langgraph.checkpoint.memory import InMemorySaver

from store import PROMPT, QUESTIONS, get_order, return_window

agent = create_agent(
    model="openai:gpt-5-mini",
    tools=[tool(get_order), tool(return_window)],
    system_prompt=PROMPT,
    checkpointer=InMemorySaver(),  # memory: the checkpointer stores each thread
)


async def main():
    config = {"configurable": {"thread_id": "customer-42"}}
    for question in QUESTIONS:
        result = await agent.ainvoke({"messages": [{"role": "user", "content": question}]}, config)
        print(f"> {question}\n{result['messages'][-1].content}")


asyncio.run(main())

> What's the status of order O-1001?
Order O-1001 (Desk lamp) was delivered on 2026-10-02 and the charge was $49.00.
> Can I still return it?
Yes — order O-1001 is returnable until 2026-11-01 (12 days left).

tool() wraps each function, reading the name, type hints and docstring into a schema. create_agent builds the loop on LangGraph, and the checkpointer stores each conversation under its thread_id. Without a checkpointer, each call starts fresh, and "it" in the second question refers to nothing.

Pydantic AI

import asyncio

from pydantic_ai import Agent

from store import PROMPT, QUESTIONS, get_order, return_window

agent = Agent("openai:gpt-5-mini", instructions=PROMPT, tools=[get_order, return_window])


async def main():
    history = []  # memory: you pass the message history into the next run
    for question in QUESTIONS:
        result = await agent.run(question, message_history=history)
        history = result.all_messages()
        print(f"> {question}\n{result.output}")


asyncio.run(main())

> What's the status of order O-1001?
Order O-1001 (desk lamp) was delivered on 2026-10-02.
> Can I still return it?
Yes — Order O-1001 is returnable until 2026-11-01 (12 days left).

Plain functions go straight into tools=. Memory is explicit: each run returns its messages, and you pass them into the next run. That makes the conversation easy to store anywhere, and easy to forget when you port code. Pydantic AI 2.58 also prints a banner to stderr suggesting you turn on tracing; set PYDANTIC_AI_NO_BANNER=1 to hide it.

OpenAI Agents SDK

import asyncio

from agents import Agent, Runner, SQLiteSession, function_tool, set_tracing_disabled

from store import PROMPT, QUESTIONS, get_order, return_window

set_tracing_disabled(True)  # traces are exported to OpenAI unless you turn them off

agent = Agent(
    name="support",
    instructions=PROMPT,
    model="gpt-5-mini",
    tools=[function_tool(get_order), function_tool(return_window)],
)


async def main():
    session = SQLiteSession("customer-42")  # memory: an in-memory SQLite session
    for question in QUESTIONS:
        result = await Runner.run(agent, question, session=session)
        print(f"> {question}\n{result.final_output}")


asyncio.run(main())

> What's the status of order O-1001?
Your order O-1001 (Desk lamp, $49.00) was delivered on 2026-10-02.
> Can I still return it?
Yes — order O-1001 is returnable until 2026-11-01 (12 days left).

function_tool() wraps each function. A session holds the memory: SQLiteSession keeps it in memory unless you give it a database file. Tracing is on by default and goes to OpenAI, so this file turns it off.

Promptise Foundry

import asyncio

from langchain.tools import tool
from promptise import InMemoryConversationStore, build_agent

from store import PROMPT, QUESTIONS, get_order, return_window


async def main():
    agent = await build_agent(
        model="openai:gpt-5-mini",
        instructions=PROMPT,
        extra_tools=[tool(get_order), tool(return_window)],  # the same LangChain tools
        conversation_store=InMemoryConversationStore(),  # memory: one session per conversation
    )
    try:
        for question in QUESTIONS:
            answer = await agent.chat(question, session_id="customer-42")
            print(f"> {question}\n{answer}")
    finally:
        await agent.shutdown()


asyncio.run(main())

> What's the status of order O-1001?
Order O-1001 for a Desk lamp (USD 49.00) was delivered on 2026-10-02.
> Can I still return it?
Yes — it's returnable until 2026-11-01 (12 days left).

The tools are the same LangChain tool objects as in the LangChain version, passed through extra_tools=. Memory is a conversation store, and agent.chat() loads and saves the session for you. Swap InMemoryConversationStore for the SQLite or Postgres store to keep conversations across restarts.

What changed between the four versions

All four reached the same answers: delivered on October 2, returnable until November 1. With the same model, prompt and tools, the framework changes the code around the model much more than the answers.

Move one layer at a time, and keep the old agent running until the new one passes the same tests.

Tools

Keep tool logic in plain functions, as store.py does, and wrap them per framework. The body of a LangChain @tool function usually moves as it is; check anything that uses ToolRuntime, InjectedState or returns LangChain messages.

For tools shared by several agents, serve them over MCP. Every framework here connects to the same server, and the next switch doesn't touch the tools:

"""The same two functions served over MCP, so any framework can use them."""
from promptise.mcp.server import MCPServer

from store import get_order, return_window

server = MCPServer(name="store")
server.tool(read_only_hint=True)(get_order)
server.tool(read_only_hint=True)(return_window)

if __name__ == "__main__":
    server.run()  # stdio by default

Connect MCP servers to an AI agent shows the client side, and MCP vs LangChain explains how the two fit together.

Prompts

Move the system prompt into a file or a constant, not a framework class. ChatPromptTemplate variables become an f-string. CrewAI splits a prompt into role, goal and backstory, so plan to rewrite rather than copy. Keep the exact wording at first; rephrasing during a migration hides what changed the behavior.

Memory

Memory is where frameworks differ most:

• Short-term memory (the conversation) maps from a checkpointer and thread_id to message history (Pydantic AI), a session (OpenAI Agents SDK), or a conversation store (Promptise).

• Long-term memory (facts across conversations) usually lives in your own database or vector store. Keep it there and expose it as a tool.

• Existing threads don't transfer. Checkpoints use LangGraph's format. Let open conversations finish, or export the messages and load them as history.

AI agent memory in Python covers both kinds.

A safe migration order

1. Write evals for the current agent: the tools it must call, the actions it must never take, and facts the answers must contain. How to evaluate AI agents in Python shows how.

2. Move tools into plain functions or an MCP server.

3. Rebuild the agent in the new framework with the same prompt and model.

4. Wire memory, then approvals and limits.

5. Set up tracing before the first real traffic. AI agent observability lists what to record.

6. Run the same evals on both versions, then switch new conversations over.

Before the first unattended run in the new framework, check four things. Pin the framework and its mcp dependency together, because MCP SDK 2.x changed imports and some adapters still need 1.x. Know where traces go by default. Test that step and tool-call limits stop a run with an error, not a half-finished answer. And keep the migration evals in CI, because framework upgrades change behavior too.

• This is not a benchmark. It compares documented features and shows one small agent. It doesn't rank accuracy, speed or cost.

• The ecosystem moves fast. Most frameworks here shipped a release in the ten days before this guide. Check the docs for the version you install.

• Python only. TypeScript teams should also look at Mastra, the Vercel AI SDK and LangChain.js.

• We make Promptise. We sourced every claim about other frameworks from their documentation, said where they are stronger, and noted that Promptise builds on LangChain's packages rather than replacing them.

What is the best alternative to LangChain?

There is no single best one. For typed agents, Pydantic AI. For the least code on OpenAI models, the OpenAI Agents SDK. For explicit graphs and durable runs, LangGraph. For teams of agents, CrewAI. For document-heavy agents, LlamaIndex or Haystack. For MCP tools with approvals and budgets in one package, Promptise Foundry.

Is LangChain still the best agent framework in 2026?

It is still one of the most used, with one of the largest sets of integrations and a stable 1.x API. Whether it is the best depends on the project: smaller frameworks need less code for a single agent, and some ship features LangChain leaves to LangSmith or to you. If LangChain 1.x works for you, there is little reason to switch.

Is LangGraph an alternative to LangChain?

Partly. LangGraph is the runtime under LangChain 1.x agents, from the same company. Moving from create_agent to a StateGraph gives you explicit control over every step, but you stay in the same ecosystem with the same models and tools. It is the right move when you need more control, not fewer abstractions.

What are the best LangChain alternatives for production?

Look for durable state, approvals, limits that stop a run, and tracing you control. LangGraph, Pydantic AI, the OpenAI Agents SDK and Microsoft Agent Framework can pause runs and resume them later. Pydantic AI and Promptise Foundry limit tokens and tool calls. Microsoft Agent Framework has OpenTelemetry built in. Test each against your own failure cases.

Which LangChain alternatives for Python support MCP?

All 11 in this guide can use tools from MCP servers. Pydantic AI, the OpenAI Agents SDK, CrewAI, smolagents, Microsoft Agent Framework, Google ADK and Promptise have a client built in. LangGraph uses LangChain's adapter, and LlamaIndex, Haystack and DSPy use an integration package or helper.

Do I need a framework at all?

Not always. A single model call, or an agent with one or two read-only tools, is easier to debug with the provider's SDK and a short loop. A framework pays off when you need memory across turns, approvals, limits, several agents or deployment.

• Compare nine frameworks feature by feature: Best AI agent frameworks (2026).

• Understand how MCP and LangChain fit together: MCP vs LangChain.

• Leaving the graph rather than LangChain: LangGraph alternatives.

• Protect the migration with tests: how to evaluate AI agents in Python.

• Reference: the Promptise docs for building agents and conversations.