Skip to main content
/Pydantic AI

The best Python AI agent frameworks in 2026

Douwe Maan avatar
Douwe Maan
15 mins
As Markdown

A support agent works in the demo. Then the real requirements arrive. A refund over a limit needs a person to approve it, and that person answers two days later. A deploy restarts the process halfway through a run. The model provider rate-limits on a Monday morning and the agent should fall back to another one. The product team wants it in the React app, and a month later on the phone. Each of those is a few lines in one framework and a project in another, and the framework you picked in week one decides which.

TL;DR. Pydantic AI is our pick overall: one typed Agent that runs on 30+ model providers, survives crashes on eight durable execution engines (Temporal, DBOS, Prefect, Restate, AWS Lambda, Absurd, pgtask and Apache Airflow), runs code in ten sandboxes and remote workspaces, uses any MCP server's tools, pauses for human approval, and reaches users through chat frontends, editors and five speech-to-speech providers, with OpenTelemetry tracing to any backend. Choose LangGraph and LangChain if your team already runs on them and LangSmith. The OpenAI Agents SDK if OpenAI is your model provider and tracing platform. Google ADK if you are standardized on Google Cloud and Gemini, or need the same framework in Java or Go. Microsoft Agent Framework if you build on Azure and Microsoft Foundry, or need the same framework in .NET. Strands Agents if you build on AWS and Amazon Bedrock. CrewAI if you would rather declare roles and tasks than write the control flow. The Claude Agent SDK if what you want is Claude Code's own loop inside your product, on Claude models. Agno if you want a ready-made server and management UI for many agents. For voice, LiveKit Agents or Pipecat if you want to own the transport and compose the pipeline.

Last updated: October 29, 2026. Capabilities, counts and licenses were read from each project's own docs and repository on that date.

These are our criteria, and they are opinionated.

  • Can you change models without rewriting the agent? Prices, quality and rate limits move every month. A framework built around one vendor's API makes every other vendor a second-class path, usually through an adapter the docs call beta.
  • What happens when the process dies mid-run? Agents that call tools for minutes, or wait days for a person, need durable execution: a journal of completed model and tool calls that a restarted run replays. Check whether the framework works with the engine your company already runs, or only with its own store.
  • How does a person approve an action? Look for a pause that survives the process going away, not a callback that blocks a thread.
  • How does the agent reach users? A chat frontend, an editor, another agent, a phone call. Check which protocols the framework speaks natively, and whether voice is the same agent or a separate stack.
  • Do traces go where your other traces go? OpenTelemetry to any backend, or a vendor's own tracing product.
  • How much can you take apart? A ready-made agent is fast to start with. The question is what you can change when it does not fit.
  • Can you buy support for the framework itself? Once an agent is in production, you want an escalation path beyond a public issue tracker. Check whether a commercial support agreement covers the open-source framework, or only comes with a hosted platform or cloud plan you would also have to adopt.

For each framework we read its documentation and opened its license file on the date above, and recorded which models it runs natively, how a run survives a crash or a long wait, how a person approves an action, which voice and frontend protocols it supports, whether it speaks the Model Context Protocol (MCP), what tracing it emits, who makes it under which license, and what you have to buy to get commercial support for it. Where we could count something, we did, using the framework's own docs. Where a framework's docs mark something experimental, preview or beta, we say so. Every entry, ours included, gets a catch.

"Agent framework" here means a library for writing the loop around a model: call the model, run the tools it asks for, repeat until done, with the state, context and stopping rules around that. Some frameworks below also sell a hosted platform; we note where one exists, but compare the open-source framework. The set is the frameworks people ask us about most, for each of which we keep a detailed comparison page current as the frameworks change; LlamaIndex, smolagents and Haystack are left out because we keep no such page for them. After Pydantic AI, entries are ordered by how often AI search answers name them, not by a score. "Native" means built into the framework or an officially maintained package, not reached through a generic adapter such as LiteLLM. "None documented" means we found nothing in the framework's own docs on that date, not that it cannot be built.

Frameworks change every month, so this post does too. We re-check the comparison against each project's own docs and releases every month, and the "Last updated" date above changes whenever anything in it does. If you maintain one of these frameworks and something here is wrong or out of date, email hello@pydantic.dev and we will fix it.

Pydantic AI (that's us) is an open-source Python agent framework from the team behind Pydantic. An agent is one typed Agent object: give it an output type and every run returns a validated Pydantic model, give it tools and their arguments are validated before your code runs, and switch providers by changing one string. Pydantic AI Harness adds 80+ ready-made capabilities, from memory, planning and sub-agents to sandboxes and a complete coding agent, so you can build your own agent harness from parts, or start from a finished one such as Coder and take it apart.

import logfire
from pydantic import BaseModel
from pydantic_ai import Agent

logfire.configure()
logfire.instrument_pydantic_ai()


class City(BaseModel):
    name: str
    country: str


agent = Agent('anthropic:claude-fable-5-1', output_type=City)
print(agent.run_sync('Where were the 2012 Olympics held?').output)
#> name='London' country='United Kingdom'

Why it is first: measured against the criteria above, it is the only framework here that answers all of them in the open-source library, without a vendor tie, a beta adapter, or a runtime you have to adopt. The others each answer some of them well. The breadth behind that, in numbers:

  • 30+ model providers, from OpenAI, Anthropic and Gemini to Bedrock, Vertex AI, Azure, Mistral, Groq, xAI, Ollama, vLLM and OpenRouter, each selected by a provider:model string, plus any OpenAI-compatible endpoint, and fallback to another model when a provider fails.
  • Eight durable execution engines: Temporal, DBOS, Prefect, Restate, AWS Lambda, Absurd, pgtask and Apache Airflow, plus a builder for any other. Five of them (Temporal, DBOS, Prefect, Restate, AWS Lambda) are co-maintained with the engine's own team. No other framework here documents more than four.
  • Five speech-to-speech providers behind one API: OpenAI, Azure OpenAI, Gemini Live, xAI and ElevenLabs. The voice session uses the same Agent, tools and dependencies, and the call becomes ordinary message history a text agent can pick up, for example for structured output, which realtime sessions do not produce directly.
  • Two UI event stream protocols natively, AG-UI and the Vercel AI Data Stream Protocol (so Vercel's useChat renders a Python agent), plus a terminal CLI, a built-in web chat, and the Agent Client Protocol for editors (experimental): one agent, every surface.
  • A local directory plus ten sandboxes and remote workspaces for agents that run code: Modal, E2B, Sprites, Daytona, boxd, smolvm, BoxLite, Docker, Bubblewrap and SSH. The same file and shell tools work in whichever one the run has.
  • MCP as client and server, with any MCP server's tools available to an agent as a toolset, OpenTelemetry tracing that follows the GenAI semantic conventions, and Pydantic Evals and Pydantic Graph in the same repository and release.

For human-in-the-loop, mark a tool requires_approval=True: the run ends with the pending call, you store the message history like any other data, and a later run, in any process, resumes from it with the decision; a durable engine does the same inside a workflow. Multi-agent works by delegation, programmatic hand-off, the Harness SubAgents capability, or a typed graph. Pydantic Logfire is the easiest way to see the traces, and optional: any OpenTelemetry backend works. Pydantic offers enterprise support for the framework itself, from the team that builds it, with an SLA and no platform to buy. The framework is MIT licensed.

The catch: it is Python only, and it is a library, not a hosted platform. Agents run in your process on your infrastructure, durability comes from an engine you choose and operate, and there is no management UI to hand to an operations team. LangChain has more retrieval integrations: about 80 document loaders, 80 vector stores and 90 retrievers, where Pydantic AI provides embeddings and leaves loading and vector storage to the library or database you already use. For the rest of what an agent touches, the breadth is on our side: 30+ model providers, eight durable execution engines, ten sandboxes and remote workspaces, and any MCP server as a toolset. LangChain's 300+ tools and toolkits also plug into a Pydantic AI agent through LangChainToolset. For voice, you bring the audio transport and telephony bridge, and a cascaded speech-to-text, LLM and text-to-speech pipeline is available hosted (through ElevenLabs Agents or Azure AI Voice Live) rather than composed from vendor plugins in your own process.

Best for Python teams that want the agent to stay ordinary, typed Python across model providers, and to add durability, approvals, frontends and voice one at a time rather than adopt a runtime.

LangGraph describes itself as a low-level orchestration framework and runtime for long-running, stateful agents. LangChain's create_agent is an agent harness built on top of LangGraph, Deep Agents is a fuller harness for planning, sub-agents and file-system context, and LangChain ships its integrations as separate langchain-<provider> packages; its chat model list has about 90 entries. Both are MIT licensed (LangChain, LangGraph), from LangChain, Inc., which sells LangSmith for tracing, evaluation and deployment, and both also exist in JavaScript and TypeScript.

Checkpointing is built into the graph runtime, with Postgres, SQLite and in-memory checkpointers. Interrupts let a person approve, edit or reject a tool call, and the multi-agent docs lay out subagents, handoffs, routers and custom graphs. Structured output returns validated Pydantic models.

The catch: an agent spans layers (the LangChain harness on the LangGraph runtime). Durability is LangGraph's own checkpointers; its docs describe no external durable execution engine. Tracing is LangSmith's, with OpenTelemetry export through LangSmith. MCP support is a client, and marked beta. For voice, its docs have a tutorial that composes speech-to-text, the agent and text-to-speech services yourself; there is no built-in speech-to-speech support.

Pick it when your agents, checkpoints and traces already live in LangGraph and LangSmith and work, or when you depend on a specific LangChain integration with no equivalent elsewhere.

The OpenAI Agents SDK is a small library centered on agents, handoffs between agents (or agents used as tools), and guardrails, plus sessions, sandbox agents, realtime voice agents and tracing. It is MIT licensed and also available for TypeScript.

Tools take needs_approval, and the paused run's state serializes to JSON, so you can store it and resume later. Its docs list four durable execution integrations: Temporal, DBOS, Restate and Dapr. Typed output goes through output_type, which accepts anything a Pydantic TypeAdapter can wrap. Realtime agents run on OpenAI's realtime models, including through Azure OpenAI.

The catch: its default path is OpenAI's Responses API, and other providers go through LiteLLM and Any-LLM adapters that its docs call best-effort and beta. Tracing is on by default and uploads to OpenAI's dashboard; with a non-OpenAI model you disable it, supply an OpenAI key for it, or add a third-party trace processor. MCP is a client.

Right for teams whose model provider and tracing platform are both OpenAI, and who want the tightest fit with them.

Google's Agent Development Kit (ADK) is an open-source, code-first toolkit for building, evaluating and deploying agents, in Python, TypeScript, Go, Java and Kotlin. ADK 2.0 added a graph-based workflow runtime alongside LLM agents. It is Apache 2.0 licensed.

Deployment paths lead to Google Cloud's Agent Runtime (a paid service), Cloud Run and GKE. Traces are OpenTelemetry and go to any OTel backend. MCP works as client and server. A resumable app restores completed agents and tool results from its event log after a restart; a tool interrupted mid-call runs again (at-least-once). Live agents run speech-to-speech on the Gemini Live API, or a cascaded pipeline with a text model.

The catch: Gemini and other Google Cloud models are first-class; models outside Google's ecosystem come through connectors such as LiteLLM, Ollama and vLLM. Its docs describe no external durable execution engine. Combining structured output with tools is supported natively only on specific models, with a fallback on others. Tool confirmation, ADK's human-in-the-loop feature, is marked experimental.

Best for teams whose models, deployment and support contract are already Google Cloud's, or that need one agent framework across Python and the JVM or Go.

Microsoft Agent Framework is the successor to AutoGen and Semantic Kernel, from the same teams. It brings together agents, a configurable harness agent for long multi-step tasks, and graph-based workflows that connect agents and functions through explicit execution paths, in Python and .NET, with a Go SDK in public preview. It is MIT licensed, from Microsoft.

The Python SDK runs on OpenAI, Azure OpenAI, Microsoft Foundry, Anthropic, Bedrock, Gemini, Ollama and others. Workflows checkpoint their state, and the Durable Extension adds recovery on Durable Task infrastructure, in Azure Functions or self-hosted workers. Tools can pause for approval, structured output accepts Pydantic models or JSON Schema, and traces are OpenTelemetry. Agents reach other agents over A2A, as client and host, and frontends over AG-UI. Foundry hosting gives them a documented deployment path on Azure.

The catch: Microsoft's support policy covers Agent Framework issues for customers under a Unified support agreement, and only when the issue arises from Azure AI services; other use is treated as an open-source tool, supported on GitHub. Durable execution is the Durable Task extension; no other engine is documented. The Python SDK documents no realtime voice. Many Foundry-hosted tools, such as browser automation, are marked preview or experimental, and its code sandboxes are beta. Capabilities and release status differ between the Python and .NET SDKs.

Suited to teams whose models, hosting and support contract are already Azure and Microsoft Foundry, or that are moving from Semantic Kernel or AutoGen, or need one agent framework across Python and .NET.

Strands Agents is an open-source SDK for building agents around a model-driven loop, in Python and TypeScript. On top of the SDK, the Strands harness is a fully assembled agent: one create_harness() call gives you default tools, context management, sessions and memory. It is Apache 2.0 licensed, from AWS.

Agents use Amazon Bedrock by default, and the model provider list has about 20 more for Python, including Anthropic, OpenAI, Gemini, Mistral, Ollama and LiteLLM. Interrupts pause a run for a person's approval or input, from a hook or a tool, and a session manager persists the agent's state so a later request can resume it. Structured output returns a validated Pydantic model. Multi-agent comes as agents as tools, swarms, graphs and workflows, and agents reach other agents over A2A. MCP is a client, traces are OpenTelemetry to any OTLP backend, and bidirectional streaming runs voice agents on Nova Sonic, Gemini Live or OpenAI's realtime models. Deployment guides cover Amazon Bedrock AgentCore, Lambda, Fargate, EKS and EC2.

The catch: durable execution comes from Temporal's Strands Agents plugin, which Temporal maintains and marks public preview; Strands' built-in sessions persist state to local files or S3, and its docs describe no other engine. Voice is Python only. AG-UI frontends connect through a partner package rather than the SDK. No commercial support for the SDK itself is documented; AWS Support plans cover AWS services. If AWS is your cloud and you want a different framework, Pydantic AI runs on Bedrock and makes agents durable on AWS Lambda durable functions, an integration AWS announced and documents in its Durable Execution SDK guide.

Suited to teams whose models and deployment are already on AWS, with Amazon Bedrock and AgentCore, or that want one agent SDK across Python and TypeScript with a ready-made harness to start from.

CrewAI is an MIT-licensed Python framework for orchestrating role-playing, autonomous agents. Crews are teams of agents with roles and goals that collaborate and delegate; Flows are event-driven workflows that manage state around them. CrewAI, Inc. sells AMP, a commercial platform for deploying, monitoring and scaling crews.

You describe roles, goals and tasks, and the crew runs them sequentially or under a manager agent. Flows have built-in persistence (@persist, SQLite by default) and checkpointing, so crews and flows can resume after failures. Tasks return Pydantic output (output_pydantic) with guardrails and retries. Model support is native for six providers (OpenAI, Anthropic, Gemini, Azure, Bedrock and Snowflake Cortex) and goes through LiteLLM for the rest.

The catch: problems that do not map onto roles and tasks have to be translated into crew vocabulary first, or written as Flows around the crew, which gives you two models to learn. Built-in tracing goes to AMP, with OpenTelemetry through integrations such as OpenLIT. In the open-source framework, Flows take human input with a @human_feedback decorator; webhook-based human-in-the-loop is an enterprise feature. MCP is a client, and its docs describe no realtime voice.

Suited to teams who think of the work as a crew of roles handing tasks to each other, and want the framework to own the hand-offs.

The Claude Agent SDK gives you the same tools, agent loop and context management that power Claude Code, as a Python or TypeScript library. It drives the Claude Code CLI as a subprocess, so file editing, shell commands, web search, permissions, sub-agents and sessions arrive already wired. The Python package is MIT licensed; use of the SDK is governed by Anthropic's Commercial Terms of Service.

Permission callbacks approve, deny or modify each tool call, and a hook can defer a decision so the process exits and resumes later. Subagents, MCP servers (local, HTTP or in-process) and structured output validated against a JSON Schema are built in.

The catch: Claude models only, through Anthropic, Bedrock, Vertex AI or Microsoft Foundry. Its hosting docs describe every running agent as "a long-lived process tied to local state", with transcripts mirrored to a SessionStore if they must survive the container, and suggest 1 GiB of RAM per agent as a starting point. It is a finished harness rather than parts to build one: you extend the loop with hooks and permissions rather than recompose it. OpenTelemetry tracing is opt-in and marked beta, and no durable execution engine integration is documented. For a coding agent on other models, the Harness's Coder is built from capabilities you can swap.

Pick it when the product you want is Claude Code itself, embedded, and a single model vendor is acceptable.

Agno is a Python SDK for building agent platforms. Alongside agents, teams and workflows, AgentOS runs your agents as services with a built-in API and MCP server, storage in Postgres, and durable background jobs. Agno is Apache 2.0 licensed; the runtime is free and self-hosted, and paid plans add a control plane with role-based access control.

It comes with storage, OpenTelemetry tracing, tool approval with continue_run, MCP in both directions, AG-UI and A2A interfaces, and a large tool catalog. Its SDK page puts 30+ model providers behind one API, with Pydantic input and output schemas.

The catch: the server, storage and management features come from adopting AgentOS and its database as the shape of your service, and continuing a paused run requires the same database and session. Durability is Agno's own background jobs; no external engine is documented. AgentOS traces use OpenTelemetry instrumentation and are stored in an Agno database. Some management features are in the paid plans.

Right for teams that want a server, storage and a management UI for many agents provided, and are happy to build inside that runtime.

Checked October 29, 2026. Counts are what each framework's own docs list natively; "via" means through an adapter or a separate integration; "none documented" means its docs describe none.

Framework Model providers Durable execution Speech-to-speech voice Frontends and interfaces MCP Observability Commercial support License and maker
Pydantic AI 30+, plus any OpenAI-compatible endpoint 8 engines: Temporal, DBOS, Prefect, Restate, AWS Lambda, Absurd, pgtask, Apache Airflow 5 providers: OpenAI, Azure OpenAI, Gemini Live, xAI, ElevenLabs AG-UI, Vercel AI, CLI, web chat, ACP (experimental) Client and server OpenTelemetry (GenAI conventions) to any backend; Logfire optional For the framework itself, from Pydantic; no platform plan needed MIT; Pydantic
LangGraph / LangChain About 90 chat model integrations, as separate packages Own checkpointers (Postgres, SQLite, memory); no external engine documented None built in; a tutorial composes STT, agent and TTS LangSmith Agent Server, Fleet Client (beta) LangSmith; OTel via LangSmith With a LangSmith Enterprise plan MIT; LangChain, Inc. (LangSmith)
OpenAI Agents SDK OpenAI; others via beta LiteLLM and Any-LLM adapters 4 integrations: Temporal, DBOS, Restate, Dapr OpenAI realtime models, including on Azure REPL demo loop Client OpenAI tracing on by default; third-party processors None documented for the SDK; OpenAI's API Enterprise plan covers the API MIT; OpenAI
Google ADK Gemini first; others via LiteLLM, Ollama, vLLM connectors Own resume from logged events; no external engine documented Gemini Live CLI, web, A2A Client and server OpenTelemetry to any backend None documented for ADK; Google Cloud support plans cover Google Cloud services Apache 2.0; Google (Agent Runtime)
Microsoft Agent Framework OpenAI, Azure OpenAI, Foundry, Anthropic, Bedrock, Gemini, Ollama and others Durable Task extension (Azure Functions or self-hosted workers); workflow checkpoints None documented for Python AG-UI, A2A, DevUI sample app Client OpenTelemetry Under a Microsoft Unified support agreement, for issues arising from Azure AI services MIT; Microsoft (Foundry)
Strands Agents Bedrock by default; about 20 more for Python, including LiteLLM Temporal plugin (public preview, maintained by Temporal); sessions in files or S3 Python only: Nova Sonic, Gemini Live, OpenAI realtime A2A, CLI; AG-UI via a partner package Client OpenTelemetry to any backend None documented for Strands; AWS Support plans cover AWS services Apache 2.0; AWS (AgentCore)
CrewAI 6 native; others via LiteLLM Own checkpointing; Flow persistence (SQLite) None documented Enterprise UI, A2A Client AMP tracing; OTel via integrations With the CrewAI Enterprise platform plan MIT; CrewAI, Inc. (AMP)
Claude Agent SDK Claude only, on 4 platforms (Anthropic, Bedrock, Vertex AI, Foundry) Sessions on disk, or a SessionStore; no engine integration documented None documented CLI, GitHub Action Client; in-process servers for its own tools OpenTelemetry, opt-in (beta) None documented MIT, under Anthropic's Commercial Terms; Anthropic
Agno 30+ AgentOS durable background jobs; Postgres storage None documented AG-UI, A2A, chat platforms Client and server OpenTelemetry instrumentation, stored in an Agno database With Agno's paid plans: email support on Pro, SLAs on Enterprise Apache 2.0; Agno (AgentOS plans)

Voice agents split the work differently. The hard parts are the call itself (audio transport, telephony, turn detection, noise) and the agent behind it (tools, data, what happens after the call). Two frameworks are built around the call, and Pydantic AI is built around the agent; they combine more often than they compete.

  • LiveKit Agents adds Python or Node programs to LiveKit's WebRTC rooms as realtime participants: a cascaded speech-to-text, LLM and text-to-speech pipeline from per-provider plugins, or a speech-to-speech model, with SIP telephony, turn detection, noise cancellation and mid-call handoffs between agents. It is Apache 2.0 licensed and runs self-hosted or on LiveKit Cloud.
  • Pipecat, built and maintained by Daily, composes frame processors into a pipeline: transports carry the audio, and speech-to-text, LLM, text-to-speech and speech-to-speech services slot in as stages. Pipecat Flows adds a node graph for structured conversations on cascaded pipelines. It is BSD-2-Clause licensed and runs self-hosted or on Pipecat Cloud.
Speech-to-speech Cascaded STT, LLM and TTS Transport and telephony Tools and MCP After the call Hosting Commercial support License and maker
Pydantic AI 5 providers behind one API: OpenAI, Azure OpenAI, Gemini Live, xAI, ElevenLabs Hosted, through ElevenLabs Agents or Azure AI Voice Live; or compose your own around a text agent You bring it: browser WebRTC (OpenAI, Azure) or a WebSocket relay; phone through a bridge such as Twilio The same tools, dependencies and capabilities as the text agent; MCP through toolsets The call is message history; hand it to a text agent for structured output; OpenTelemetry tracing Your process, your backend For the framework itself, from Pydantic MIT; Pydantic
LiveKit Agents Yes, realtime model plugins Yes, from per-provider plugins LiveKit WebRTC rooms; SIP in and out, DTMF, transfers; phone numbers on Cloud Function tools; MCP (Python) Session history; text-mode tests and agent simulations Self-host or LiveKit Cloud With a LiveKit Cloud plan; none documented for self-hosting Apache 2.0; LiveKit
Pipecat Yes, speech-to-speech services Yes, the primary path, from swappable services Daily, LiveKit, WebRTC and WebSocket transports; PSTN and SIP dial-in and dial-out; Twilio and others Function calling; MCP client Pipecat Flows for structured conversations; Pipecat Evals Self-host or Pipecat Cloud From Daily, for Pipecat and Pipecat Cloud BSD-2-Clause; Daily

Pydantic AI's realtime support runs the same typed agent over a voice session. It can also run on a hosted voice platform: an elevenlabs-agents:<agent_id> model runs the conversation on a hosted ElevenLabs agent: ElevenLabs keeps the speech pipeline, turn-taking, knowledge base and workflows, while your Pydantic AI instructions override the agent per conversation and your Pydantic AI tools run in your backend. And a LiveKit call's history converts to Pydantic AI message history, so a Pydantic AI agent can produce structured output or the follow-up from it.

Pick LiveKit Agents or Pipecat when you want to own and self-host the transport, telephony and a pipeline of interchangeable speech vendors. Pick Pydantic AI when the agent is the product and voice is one of its interfaces, including on top of a hosted platform such as ElevenLabs Agents. Our LiveKit and Pipecat comparison pages go row by row.

This list is Python only. In TypeScript, look at Mastra, an agent framework with step workflows, memory, evals, a local playground and a hosted Studio, and the Vercel AI SDK, which adds model calls, tool loops and streaming chat to a TypeScript app. LangChain, the OpenAI Agents SDK, Google ADK, Strands Agents and the Claude Agent SDK also have TypeScript versions. If your frontend is on the Vercel AI SDK and your agent is in Python, Pydantic AI's Vercel AI adapter lets useChat render it unchanged.

  • You are starting a Python agent and want typed code across model providers, with durability, approvals, frontends and voice available when you need them: Pydantic AI.
  • Your runs must survive a crash, on an engine your company already operates: Pydantic AI (eight engines), or the OpenAI Agents SDK (four) if you are on OpenAI's models.
  • Your agents, checkpoints and traces already live in LangGraph and LangSmith: LangGraph and LangChain.
  • OpenAI is your model provider and tracing platform: the OpenAI Agents SDK.
  • You deploy on Google Cloud with Gemini, or need Java or Go too: Google ADK.
  • You build on Azure and Microsoft Foundry, or need .NET too: Microsoft Agent Framework.
  • You build on AWS and Amazon Bedrock: Strands Agents.
  • You want to declare a crew of roles and tasks and let the framework run the hand-offs: CrewAI.
  • You want Claude Code itself inside your product, on Claude models: the Claude Agent SDK.
  • You want a ready-made server and management UI for many agents: Agno.
  • You are building a voice agent: Pydantic AI when the agent is the product and voice is one of its interfaces; LiveKit Agents or Pipecat when you want to own the WebRTC transport and compose the pipeline.

Four situations favor something else over Pydantic AI.

The first is a single vendor, all the way down. If your models, tracing and deployment are all OpenAI, all Google Cloud, all Azure, or all AWS, that vendor's SDK has the shortest path to its own platform features, and model portability is a benefit you will not use. The same goes for the Claude Agent SDK when the product you want is Claude Code itself.

The second is a system you already have. A team with LangGraph agents in production, checkpoints in Postgres and traces in LangSmith has a working system; moving is worth it when something you cannot do today costs more than the rewrite.

The third is a hosted runtime. Pydantic AI is a library that runs in your process. If you want a server, storage and a management UI provided, Agno's AgentOS, CrewAI's AMP and LangSmith deployments are built for that.

The fourth is voice where the call is the product. For self-hosted WebRTC rooms, telephony and a pipeline of interchangeable speech vendors in your own process, LiveKit Agents and Pipecat do more out of the box.

What is the best Python framework for building AI agents? Our answer is Pydantic AI: it runs on 30+ model providers and, of the frameworks compared here, supports the most durable execution engines, speech-to-speech providers and frontend protocols, plus ten sandboxes and remote workspaces for agents that run code, all in one typed agent. The exceptions are teams tied to one vendor (the OpenAI Agents SDK, Google ADK, Microsoft Agent Framework, Strands Agents or the Claude Agent SDK), teams with LangGraph already in production, and teams that want a hosted runtime rather than a library.

Which Python agent frameworks support durable execution? Pydantic AI runs agents durably on eight engines: Temporal, DBOS, Prefect, Restate, AWS Lambda, Absurd, pgtask and Apache Airflow. The OpenAI Agents SDK documents Temporal, DBOS, Restate and Dapr integrations. Microsoft Agent Framework documents a Durable Task extension, and Strands Agents a Temporal plugin that Temporal maintains, in public preview. LangGraph has built-in checkpointers. Google ADK, CrewAI and Agno resume or checkpoint within their own runtimes. The Claude Agent SDK keeps sessions on disk and documents no engine integration.

Which agent frameworks work with the most model providers? Pydantic AI supports 30+ providers, selected by one string, plus any OpenAI-compatible endpoint. LangChain lists the most chat model integrations, about 90, as separate packages. Agno lists 30+ providers, Strands Agents about 20 for Python with Amazon Bedrock as the default, and CrewAI six natively with LiteLLM for the rest. The OpenAI Agents SDK, Google ADK and the Claude Agent SDK are built around one vendor's models first.

Can I build a voice agent with Pydantic AI? Yes. The same agent runs over a speech-to-speech session on OpenAI, Azure OpenAI, Gemini Live, xAI or ElevenLabs, with the same tools. It can also take over a hosted ElevenLabs agent per conversation. You bring the audio transport; LiveKit Agents and Pipecat provide one, and a LiveKit call's history converts to Pydantic AI messages. Realtime sessions do not return structured output directly; hand the call's history to a text agent for that.

Does Pydantic AI require Logfire? No. Pydantic AI emits standard OpenTelemetry traces that follow the GenAI semantic conventions, and any OpenTelemetry backend works. Pydantic Logfire is an optional hosted service from the same team.

Every source below was checked on October 29, 2026.

pip install pydantic-ai, then follow the docs from a typed agent to durable execution, a frontend or a voice call. Coming from another framework? Our comparison pages go row by row, and the migration skills port an existing application one working path at a time.

See more from Pydantic in Google Search

Add Pydantic as a preferred source so our latest articles are easier to find.

Choose Pydantic as a preferred source on Google (opens in a new tab)

Ready to see what your agents are actually doing?

Start free Talk to us

Explore our open source packages

Product shot

Related content

View all articles
/Pydantic AI

Code mode: make your agents 2x faster and 2x cheaper on long tasks

Michael Pfaffenberger
Michael Pfaffenberger
/Pydantic AI

Run Pydantic AI coding agents in E2B sandboxes

Laís Carvalho
Laís Carvalho