Choosing an AI agent framework is a decision about where you want the complexity of your system to live. Every agent needs the same handful of things: a loop that calls the model, runs tools and feeds results back, some notion of state, a way to check the output, and a way to see what happened when it goes wrong. A framework hands you those pieces prebuilt. In exchange, it asks you to accept its abstractions, its release cycle and its opinion of how an agent should be structured.
Which framework is worth that trade depends on the shape of the problem and on the team that will maintain the result. A strict extraction service, a workflow that waits for human approval and an assistant over company documents put very different pressure on a framework.
This guide assumes you have already decided that the problem calls for an agent. If that question is still open, start with how AI agents work and when the problem calls for one. Here we compare LangChain, LangGraph and PydanticAI, place Agno, CrewAI and LlamaIndex next to them, and cover when to use none.
What an AI agent framework actually does for you
- The tool loop. The model asks for a tool, your code runs it, the result goes back into the conversation, and the cycle repeats until the model produces a final answer. Writing it with timeouts, parallel calls and a cap on iterations is where the hours go.
- State and memory. Conversation history, intermediate results and anything the agent needs to remember between steps or between sessions.
- Output handling. Turning a stream of tokens into something downstream code can trust, usually a typed object, and deciding what happens when the model returns something malformed.
- Resilience. Retrying failed model calls, resuming a long task after a crash, pausing for a human decision and continuing later.
- Visibility. Traces of every model call and tool call, with inputs, outputs, latency and cost, so a bad answer can be explained after the fact.
The cost side is just as concrete. Each framework adds a layer between your code and the model provider, and that layer has its own vocabulary, its own bugs and its own breaking changes. When something fails deep inside an abstraction, debugging means reading the framework's source. Once a codebase is written around one framework's graph or agent primitives, switching is closer to a rewrite than a refactor.
A useful way to frame the decision: adopt a framework when the problems above are ones you would otherwise solve yourself, badly, under deadline. Skip it when your application only needs one or two of them.
How to choose an AI agent framework: the criteria that matter
Every popular framework now supports tool calling, structured output and multiple model providers. The differences that matter sit in what each framework assumes about your application.
| Criterion | What to ask | Why it matters |
|---|---|---|
| Control flow | Is the sequence of steps decided by the model, by your code, or by a mix you define explicitly? | Explicit control makes behavior testable. Model-driven loops are faster to build and harder to bound. |
| State and resumption | Can a run pause, persist its state and resume after a crash or a human approval? | Long-running and approval-gated agents fail without it. |
| Output validation | Are outputs typed and validated, with a defined retry path when validation fails? | Anything that writes to a database or triggers an action needs a contract. |
| Multi-agent support | Does the framework model several cooperating agents, or only one agent with tools? | Most problems need one agent. The ones that need several need clear handoffs. |
| Observability | Are traces built in, and can they go to the tool your team already uses? | You will debug in production. The question is how blind you will be. |
| API maturity | Is there a stable major version with a stated compatibility policy? | Agent frameworks moved fast in 2024 and 2025. Churn is a real maintenance cost. |
| Ecosystem | Are connectors for your vector store, data warehouse and model providers already written? | Integrations you do not write are integrations you do not maintain. |
| Team profile | Does the framework's style match how your engineers already write Python or TypeScript? | A framework that fights the team's habits gets worked around, then abandoned. |
Two of these criteria usually decide the outcome. Control flow decides whether the framework can express your process at all. Team profile decides whether it will still be maintained a year from now.
If you want a broader view of the tooling around the framework (vector stores, evaluation, serving), the best tools to build LLM applications in production covers how the pieces combine into a stack.
LangChain and LangGraph: one stack, two levels
LangChain and LangGraph are often presented as competitors. Since October 2025, when both reached version 1.0, they work as two levels of the same stack.
LangGraph is the low-level runtime. You describe an agent as a graph: nodes are steps (a model call, a tool call, a function you wrote), edges decide what runs next, and a shared state object moves between them. Because the graph is explicit, you can add checkpoints, interrupt a run for human approval, branch on conditions you control and resume a run days later from the exact point it stopped.
LangChain 1.0 is the high-level API built on top of that runtime. Its create_agent function replaces the older create_react_agent, which is now deprecated, and gives you a working tool-calling agent in a few lines. Because it runs on LangGraph underneath, that agent inherits persistence, checkpointing, human-in-the-loop and streaming without extra work. The official LangChain documentation describes the v1 changes and the migration path.
The practical rule follows from that layering. Start at the LangChain level when the agent is a single loop of model plus tools and the default behavior is close to what you need. Drop down to LangGraph when you need to dictate the flow yourself: a supervisor routing work between specialized agents, a review step that must happen before any write, parallel branches that merge, or a process that has to survive restarts. The two coexist in one codebase, so the choice can be made per agent.
The strengths of this stack are breadth and maturity. LangChain has the largest catalog of integrations in the space (document loaders, retrievers, vector stores, model providers), and LangSmith gives it a native tracing and evaluation layer, which we cover in LangSmith simplified. The weakness is surface area. There are many concepts to learn, and teams that only needed a small loop can end up carrying a large dependency.
For hands-on depth, LangGraph for AI agents walks through orchestration and agent-to-agent communication, and LangGraph in practice covers multi-agent systems at scale. On the LangChain side, LangChain for enterprise data focuses on security and access control.
PydanticAI: type-safe agents for structured data
PydanticAI comes from the team behind Pydantic, the validation library most Python data and API code already depends on, and it carries that library's priorities into agent design. You declare what the agent must return as a typed model, the framework validates every response against it, and a response that fails validation goes back to the model with the error so it can correct itself. Tools are ordinary typed Python functions, and dependencies such as a database connection are injected explicitly, which makes agents straightforward to unit test.
The project reached version 1 on September 4, 2025, with a commitment not to introduce breaking API changes for at least six months. After years of framework churn, that policy matters as much as any feature.
Two capabilities stand out for production work. The first is durable execution: PydanticAI integrates with Temporal, DBOS and Prefect, among others, so a long-running agent can survive process restarts and resume where it stopped. The second is observability through Logfire and OpenTelemetry, which lets traces flow into whatever backend the team already runs. Both are described in the PydanticAI documentation.
PydanticAI fits best when the output is the product. Extraction, classification, routing and any agent whose result is written to a system of record benefit from treating the model like a function with a contract. It is a thinner layer than LangChain, so retrieval and connectors usually come from separate libraries.
To go further, PydanticAI in practice covers validation and quality control end to end, and privacy and compliance with LangChain and PydanticAI shows the two used side by side under regulatory constraints. The combination is common: reliable agent systems with LangGraph and PydanticAI uses LangGraph for the flow and PydanticAI for typed outputs inside each step.
Agno, CrewAI and the rest of the field
Three other frameworks come up often enough to deserve a place in the comparison. Each makes a different bet about what is hard.
CrewAI organizes work in two ways. Crews are teams of agents with defined roles that collaborate with a degree of autonomy. Flows are deterministic, event-driven orchestrations where you define the sequence and agents run inside it. The CrewAI documentation recommends starting from a Flow for production applications, which tells you where predictability lives. For a direct comparison, see LangGraph vs CrewAI.
Agno focuses on speed of development and runtime performance, with a compact API for agents, teams and workflows. Its AgentOS is an open source, self-hosted runtime under the Apache 2.0 license, aimed at teams that want to run agents inside their own infrastructure. Agno explained introduces the model, is Agno worth it reviews it in practice, and LangChain vs Agno compares the two head to head.
LlamaIndex started as a retrieval framework and still shines when the center of the application is getting the right context out of a large body of documents. Our guide to RAG in production covers the retrieval side of that decision.
Visual builders form a separate category. Langflow puts a drag-and-drop interface over LangChain components, which speeds up prototypes and lets less technical stakeholders follow the logic. LangChain vs Langflow explains when the visual layer helps, and Langflow and CrewAI for visual orchestration shows how the two fit together.
When to use no framework at all
Every major model provider now ships an SDK with native function calling and structured output. For a large class of applications, that SDK is enough.
The case for going without a framework is strongest when the agent has a small, stable set of tools, a single model provider, and a loop that fits on one screen. A support triage service that classifies a ticket, looks up the customer and returns a typed decision does not need a graph runtime. Writing the loop yourself costs a few dozen lines and gives you full control over prompts, retries and errors, with no dependency whose next major release you have to plan around.
The same applies when the surrounding infrastructure already covers what a framework would add. If your workflows already run in an orchestrator with retries and state, and your observability stack already ingests OpenTelemetry traces, a framework duplicates layers you have.
The signals that you have outgrown the hand-written approach are recognizable. You start writing your own checkpointing. You add a second model provider and wrap both behind an interface. You need a human to approve a step and resume the run later. You build a small tracing system to understand why an answer was wrong. At that point you are writing a framework, and adopting a maintained one is usually cheaper.
Tool access deserves a separate note. The Model Context Protocol standardizes how agents discover and call external tools, and most frameworks now support it. If tool integration is your main pain, our guide to the Model Context Protocol may solve more of it than a framework change would.
Matching the framework to the scenario
The table below summarizes the patterns we see most often. Treat it as a starting point for discussion. Team skills and existing infrastructure can legitimately change the answer.
| Scenario | Suggested starting point | Why |
|---|---|---|
| Structured extraction with strict validation (invoices, contracts, forms) | PydanticAI | Typed outputs with automatic retry on validation errors, and a thin layer that is easy to test |
| Internal assistant with RAG and tools over company documents | LangChain, or LlamaIndex when retrieval is the hard part | Mature loaders, retrievers and vector store integrations |
| Multi-agent workflow with human approval before actions | LangGraph | Explicit graph, checkpoints, interrupts and resumption are core features |
| Back-office automation that needs many ready-made connectors | LangChain | The broadest integration catalog reduces the code you write and maintain |
| Role-based collaboration for research or content tasks | CrewAI, starting from a Flow | Roles map naturally to the task, and Flows keep production behavior predictable |
| Prototype by a team without strong Python skills | Langflow or another visual builder | Lower entry barrier, with an export path to code when the prototype proves itself |
| Single agent, few tools, one model provider | No framework, model SDK only | Less code to debug and no dependency to track |
Mixing is normal. A LangGraph flow with PydanticAI agents inside its nodes is a pattern we use often, and an SDK-only service can sit next to a LangChain assistant in the same platform. At BIX we work with all of these frameworks, and the choice is made per use case.
Whatever you choose, plan observability from the first day. LangSmith for agent governance covers the LangChain side, Langfuse vs Galileo vs Logfire compares framework-neutral options, and what is observability explains the underlying signals.
Where to go deeper on agent frameworks
For applied LangChain work with company data, LangChain agents for automation and data analysis shows agents running analysis tasks end to end.
For LangGraph in a concrete use case, building internal technical assistants with LangGraph covers a secure multi-agent assistant from design to deployment.
If your team is choosing between LangChain, LangGraph, PydanticAI or a plain SDK for an agent that has to run in production, our specialists can compare the options against your data, your infrastructure and the people who will maintain it. Talk to our team and move your AI maturity forward. ⬇️
What is an AI agent framework?
An AI agent framework is a library that provides the recurring parts of an agent prebuilt: the loop that calls the model and runs tools, state and memory, output validation, retries, resumption and tracing. It saves you from writing that plumbing yourself, in exchange for adopting the framework's abstractions, vocabulary and release cycle.
What is the difference between LangChain and LangGraph?
Since version 1.0, released in October 2025, LangChain is the high-level API and LangGraph is the runtime underneath it. LangChain's create_agent gives you a working agent quickly. LangGraph lets you define the flow as an explicit graph with checkpoints, human approval steps and resumption. Many projects use both.
Is PydanticAI better than LangChain?
Neither is better in general. PydanticAI fits agents whose typed, validated output is the product, such as extraction and classification, and it keeps a small API surface. LangChain fits applications that need many integrations, retrieval pipelines and the LangGraph runtime underneath. Teams often combine LangGraph for flow control with PydanticAI for validated outputs.
When should you build an AI agent without a framework?
When the agent has a few stable tools, one model provider and a simple loop, the model provider's SDK with native function calling is usually enough. You keep full control and avoid an extra dependency. Adopt a framework once you start writing your own checkpointing, approval steps, multi-provider abstractions or tracing.
Can you use more than one agent framework in the same system?
Yes, and it is common. A LangGraph workflow can run PydanticAI agents inside its nodes, and a simple SDK-based service can coexist with a LangChain assistant on the same platform. Standards such as the Model Context Protocol and OpenTelemetry make tools and traces portable across frameworks, which keeps mixing manageable.
