The best agentic frameworks, and what each one is good at

The short version

• There is no single best agentic framework: the right one depends on your model, your team's language and how much state the agent must hold.
• LangGraph suits long-running agents that need saved state, resumable runs and human approval steps.
• Model provider SDKs, such as the OpenAI Agents SDK and the Claude Agent SDK, are the fastest route to a working agent once the model is chosen.
• A single agent calling a few tools often needs no framework, because a plain tool-calling loop is easier to read and debug.
• Developer surveys show which frameworks are popular, not which ones suit your agent or hold up in production.

Which agentic frameworks are worth shortlisting?

Five frameworks cover most production work: LangGraph, the OpenAI Agents SDK, the Claude Agent SDK, Pydantic AI and Google's Agent Development Kit (ADK). CrewAI, Microsoft Agent Framework, LlamaIndex, Mastra and the Vercel AI SDK are strong choices in narrower cases. None of them is the best agentic framework in general. Each is best for a particular model, language and amount of control.

They fall into three groups. Model-agnostic frameworks, such as LangGraph and Pydantic AI, give you explicit control over the agent's flow and work with any major model. Model provider SDKs, such as the OpenAI Agents SDK, the Claude Agent SDK and Google's ADK, are the shortest path to a working agent on one vendor's models. Role-based multi-agent frameworks, such as CrewAI, let you describe a team of agents and leave the framework to run the conversation between them.

The group matters more than the brand. Choosing a group decides who owns the control flow: your code, the model vendor's SDK, or the framework's abstraction. That is the expensive decision to reverse. Moving between two frameworks in the same group is usually far cheaper.

How do the leading agentic frameworks compare?

When is LangGraph the right choice?

LangGraph is the right choice when an agent runs for a long time, holds state across many steps, or needs a person to approve something partway through. It models the agent as a graph of steps sharing one state object, and can save that state after each step, so a run can pause, resume, or recover from a failure without starting again.

That is the work most demos skip. Picture an agent that drafts a refund, waits two days for a manager to approve it, then continues where it stopped. It needs persistent state and a defined place to stop. LangGraph treats both as basic features. In a hand-written loop you build them yourself, usually the first time a run dies halfway.

The cost is concepts. Nodes, edges, state reducers and checkpointers are more to learn than a simple loop, and a small agent can end up with more framework than logic. LangGraph itself is open source. The smoothest tracing runs through LangSmith, LangChain's separate commercial product, which has a published list price for its Plus plan.

Should you use your model provider's agent SDK?

Yes, if you have already chosen a model and expect to keep it. The OpenAI Agents SDK and the Claude Agent SDK are the shortest route from nothing to a working agent on their vendor's models, and new model features tend to reach them first.

They are different tools. The OpenAI Agents SDK is a small set of primitives: agents, tools, handoffs between agents, guardrails and tracing. The Claude Agent SDK exposes the agent harness behind Claude Code, so an agent gets file access, shell commands, context management and subagents without you writing them. The first suits conversational and routing agents. The second suits agents that do work on a computer or in a codebase.

Google's ADK sits slightly apart. It is optimised for Gemini and Google Cloud, but designed to call other models too, and it supports agents arranged in hierarchies.

The trade-off is lock-in at the control-flow level. The OpenAI SDK can call other providers' models, but it is built around OpenAI's. The Claude Agent SDK runs Claude models only. If the model choice is still open, or procurement might force a change next year, a model-agnostic framework keeps that door open.

Are multi-agent frameworks like CrewAI worth using?

Sometimes, but less often than they are used. CrewAI makes it quick to describe several agents with roles and goals and let them collaborate, which suits prototypes and research-style tasks. For production workflows, one agent with good tools, or a fixed workflow with a single agent step, is usually easier to test and cheaper to run.

The reason is mechanical. Every handoff between agents is another model call, another chance to lose context, and another place for a failure to hide. When a five-agent crew produces a bad answer, the first question is which agent made the bad decision. The abstraction that made the crew quick to build is the thing hiding the answer.

Use several agents when the work genuinely splits into parts that need different tools, permissions or context, and each part can be checked on its own. Do not use them to mirror an org chart. If you do choose CrewAI for production, look at its Flows feature, which gives you explicit control over the order things happen in.

Which agentic framework suits a TypeScript or .NET team?

TypeScript teams should look at Mastra, the Vercel AI SDK, or the TypeScript versions of LangGraph, the OpenAI Agents SDK and the Claude Agent SDK. For .NET teams, the starting point is Microsoft Agent Framework. A framework in the language your team already ships beats a slightly better one in a language it does not.

Mastra bundles agents, workflows, memory and evaluation into one TypeScript package. The Vercel AI SDK is lighter: it handles model calls, tool loops and streaming to a user interface, and leaves state and persistence to you. That suits an agent living inside an existing web app. Where a framework exists in both Python and TypeScript, the Python version often gets new features first.

Microsoft Agent Framework is Microsoft's successor to AutoGen and Semantic Kernel, with Python and .NET support and a natural fit with Azure. New projects in that ecosystem should start there rather than on AutoGen.

When do you not need an agentic framework at all?

When one agent calls a handful of tools in a loop. Every major model API supports tool calling directly. A loop that sends the conversation, runs whichever tool the model asks for and returns the result is a few dozen lines of code you can read end to end.

That code has advantages no framework can match. Every prompt is visible. Every retry is yours to see. A stack trace points at your code, not at three layers of abstraction. When the model vendor ships a new feature, you can use it the same day.

Adopt a framework when you catch yourself rebuilding what it provides: persistent state, resumable runs, approval steps, tracing across many calls. That is the honest test. A framework added to an agent that needs none of those things adds dependencies without adding capability.

Many tasks described as agents are fixed workflows with one model call in the middle. Those need workflow automation, not an agent framework, and they are cheaper and easier to test for it.

How do you choose between agentic frameworks?

Answer four questions in order: which model you will run, which language your team ships, how much state the agent must hold, and how you will see what it did. The answers usually leave one or two candidates.

Model first. If the model is fixed, the vendor's SDK is the default and you need a reason to reject it. If the model is open, choose a model-agnostic framework such as LangGraph or Pydantic AI.

Language second. A framework in the language you already deploy and monitor will reach production faster than a better one you have to learn to operate.

State third. If runs are short and stateless, a plain loop or a light SDK is enough. If runs pause, wait for people, or must survive a restart, you need persistence, and LangGraph is built around it.

Visibility fourth. You will need a trace of every model call and tool call to debug and evaluate the agent. Check what tracing the framework supports, whether it can export to OpenTelemetry, and whether the useful version is a paid add-on.

How do you avoid lock-in to an agentic framework?

Keep the parts that carry your knowledge outside the framework: tool code, prompts, business rules and evaluation cases. The framework then becomes the loop that connects them, and replacing it is contained work rather than a rewrite.

Tools are the easiest place to start. Most current frameworks can call tools exposed through the Model Context Protocol (MCP), an open standard for connecting models to tools and data. Tools written as MCP servers, or as plain functions with thin wrappers, survive a framework change.

Keep evaluation independent too. A set of real inputs with expected behaviour, run outside the framework, is the only way to know whether a switch made the agent better or worse.

How much should developer surveys influence the choice?

A little. Surveys show which frameworks have communities, documentation and people you can hire, and that matters. They do not show which framework suits your agent, and the samples behind them shape the answers.

Stack Overflow's 2025 Developer Survey had about 49,000 respondents, and put its framework question only to those who build AI agents. Its AI agents question drew 31,877 answers. That is a large sample, but it measures use: what developers have tried, not what held up in production.

LangChain's State of Agent Engineering survey received 1,340 responses between 18 November and 2 December 2025. Its respondents come from LangChain's own audience, which leans towards people already building agents. That makes it useful for learning what agent builders worry about, and a weak guide to how LangChain's own frameworks compare with others. Read any vendor's survey of its own users the same way.

We are not aware of a neutral benchmark that ranks agent frameworks on production outcomes. Treat any ranking that implies one, including the shortlist above, as judgement rather than measurement.