LangGraph vs CrewAI vs direct API: choosing an agent framework in 2026

The agent framework landscape in 2026 is more mature than two years ago and no clearer. LangChain/LangGraph remains dominant but increasingly questioned. CrewAI has carved out a niche. Pydantic AI is winning fans for type safety. OpenAI's Agents SDK and Anthropic's Claude SDK are growing. And a quiet movement of teams is going back to direct API calls, especially in production.

Every framework has its proponents and its critics. The debates are loud. The decision is usually personal more than objective.

This article cuts through the noise with a working architect's view. What each framework actually does, where each fits, and the honest patterns we see in production. No religious wars; just trade-offs.

What an agent framework is for

Before comparing, clarify what we're choosing among. An "agent framework" typically provides:

1. A way to define agents — what's their role, what tools they have, what's their behavior.
2. An execution loop — call LLM, parse output, decide what to do, call tools, repeat.
3. State management — what does the agent remember, how is it organized.
4. Tool integration — how tools are defined and exposed.
5. Orchestration — multiple agents working together, branching workflows, retries.
6. Observability hooks — tracing, logging, debugging.
7. Convenience utilities — prompt templates, common patterns, helpers.

Each framework prioritizes these differently. Some are heavy on orchestration; some focus on agent definition; some are minimal layers over the model APIs.

The landscape

LangChain / LangGraph

The big one. LangChain started as a Python library for chaining LLM calls; it became the de facto framework for many AI projects. LangGraph is the agent-specific framework built on top.

What it does well:

• LangGraph for state machines. The graph model (nodes for steps, edges for transitions, state passed between) is well-suited for complex agent workflows.
• Rich ecosystem. Many integrations: vector DBs, model providers, tools, observability.
• LangSmith for observability. Mature tracing and debugging UI.
• Wide adoption. Many examples, much documentation, many people who know it.

What it doesn't:

• Abstraction tax. LangChain in particular has many layers of abstraction. Debugging is harder; understanding what's actually happening takes effort.
• API churn. Frequent breaking changes. Code from 12 months ago often needs updates.
• Performance overhead. Layers of indirection cost latency and tokens.
• Learning curve. Real fluency takes weeks.

When to choose:

• Complex agent workflows with branching state.
• Teams that benefit from a standard framework (many engineers, common patterns).
• When you want LangSmith observability.

When to skip:

• Simple chatbots or single-agent loops (direct API is simpler).
• Teams that have been burned by LangChain's churn previously.
• Projects where every millisecond of latency matters.

CrewAI

A multi-agent framework focused on role-based agents. Each agent has a role, goal, backstory; they collaborate on tasks.

What it does well:

• Multi-agent orchestration. Built-in support for agents talking to each other, delegating, collaborating.
• Role-based mental model. Easy to think about ("the Researcher agent does X; the Writer agent does Y").
• Simpler than LangGraph for multi-agent. Faster to get started.
• Active community.

What it doesn't:

• Limited single-agent depth. If your task is a single complex agent, CrewAI's abstractions can feel mismatched.
• Performance. Multi-agent setups multiply LLM calls; cost and latency scale fast.
• Maturity gap. Younger than LangChain; some rough edges remain.
• Opinionated. Less flexibility than direct frameworks.

When to choose:

• Multi-agent workflows where role differentiation makes sense.
• "Crew" framings (a team of agents working together).
• Prototyping multi-agent ideas quickly.

When to skip:

• Single-agent tasks (overkill).
• Production where performance matters (multi-agent is expensive).
• Tasks where the "agent collaboration" framing is more theater than substance.

Pydantic AI

A newer framework focused on type safety and developer experience.

What it does well:

• Strong typing. Pydantic-based throughout. Inputs and outputs are typed. Errors caught at development time.
• Clean API. Less abstraction than LangChain; closer to the model APIs.
• Modern Python. Async, type hints, Pydantic v2.
• Model-agnostic. Works with most providers.

What it doesn't:

• Smaller ecosystem. Fewer integrations than LangChain.
• Less proven at scale. Newer; production patterns still emerging.
• Less orchestration tooling. Not as feature-rich as LangGraph for complex workflows.

When to choose:

• Type-safety-conscious Python teams.
• Single-agent or simple multi-agent setups.
• Teams that prefer minimal abstraction.

When to skip:

• Very complex orchestration (LangGraph might fit better).
• Non-Python projects (it's Python-only).
• When you need a huge ecosystem of pre-built integrations.

OpenAI Agents SDK

OpenAI's official agent framework, tuned for OpenAI models.

What it does well:

• Optimized for OpenAI. Specifically designed for GPT-5/o3 patterns.
• Simple API. Less abstract than LangChain.
• Built-in handoffs. Multi-agent handoffs are first-class.
• Mature tracing. Built-in observability tied to OpenAI dashboard.

What it doesn't:

• OpenAI lock-in. Designed for OpenAI's models. Using other providers is awkward.
• Less flexibility. Some patterns are easier in more general frameworks.
• Newer than LangChain. Smaller community.

When to choose:

• All-in on OpenAI models.
• Want a vendor-supported path.
• Simple-to-moderate agent complexity.

When to skip:

• Multi-provider strategy (better to use a more general framework or direct API).
• You're using Anthropic or Google primarily.

Anthropic Claude SDK

Similar — Anthropic's path for building agents with Claude.

What it does well:

• Optimized for Claude. Especially good for Claude's extended thinking, computer use, MCP integration.
• Idiomatic for Claude models.
• Strong MCP support.

What it doesn't:

• Claude lock-in. Same trade-off as OpenAI Agents SDK.

When to choose:

• All-in on Claude.
• Heavy use of Claude-specific features.

When to skip:

• Multi-provider strategy.

Direct API

Skip frameworks entirely. Call OpenAI / Anthropic / Gemini APIs directly. Write the loop yourself.

What it does well:

• Full control. Every aspect of the system is yours.
• No abstraction tax. What you see is what runs.
• Easy to debug. No layers to dig through.
• Easy to optimize. No framework overhead.
• No version churn. You upgrade when you choose to.

What it doesn't:

• More code. Patterns the framework handles, you handle.
• Reinventing. Common patterns are reimplemented per project.
• Less standardization. Different teams build similar systems differently.

When to choose:

• Mature teams shipping production systems where reliability matters more than convenience.
• Single-focused use cases that don't need a framework's flexibility.
• Performance-critical paths.
• After prototyping with a framework and learning the patterns.

When to skip:

• Greenfield, exploratory, "what should we build" phase (framework helps you discover patterns).
• Teams with limited engineering capacity.

LlamaIndex

Started as a RAG-focused library; has grown into broader agent territory.

What it does well:

• RAG-heavy systems. Best-in-class for retrieval-focused agents.
• Data connectors. Many integrations for data sources.
• Mature retrieval abstractions.

What it doesn't:

• Agent abstractions are weaker. Better for RAG than general agents.
• Some overlap with LangChain ecosystem.

When to choose:

• Heavy retrieval / RAG focus.
• Need many data source connectors.

When to skip:

• Non-RAG agent work.

Microsoft Autogen, Semantic Kernel

Microsoft's offerings. Autogen for multi-agent; Semantic Kernel for general AI applications.

What it does well:

• Microsoft ecosystem integration. Works well with Azure, .NET, Microsoft 365.
• Semantic Kernel: more enterprise-feeling than alternatives.
• Autogen: strong for multi-agent research.

What it doesn't:

• Smaller community outside Microsoft shops.
• Less momentum than LangChain/LangGraph.

When to choose:

• Microsoft-shop teams.
• Heavy Azure integration.

The dimensions to think about

Choosing isn't about picking a winner — it's about matching tradeoffs to your project.

Dimension 1: Complexity of orchestration

How complex are your agent workflows?

• Simple (chatbot, single agent, linear flow): direct API or Pydantic AI.
• Moderate (single agent, branching logic): Pydantic AI, LangGraph, direct API.
• Complex (multiple agents, state machines, retries): LangGraph, CrewAI, custom.
• Very complex (large state machines, parallel agents, complex routing): LangGraph or custom.

Dimension 2: Production maturity

How important is reliability vs experimentation?

• Experimentation / prototyping: any framework helps you move fast.
• Production, customer-facing: prefer well-understood frameworks (LangChain has the most patterns; direct API has the most control).
• Production, mission-critical: direct API often wins; you understand every line.

Dimension 3: Team size and skills

• Small team (1-3 engineers): less framework overhead is better. Direct API or simple frameworks.
• Medium team (5-15): a framework helps standardize. LangChain or Pydantic AI.
• Large team (20+): framework is essential for shared patterns. LangGraph or in-house framework.

Dimension 4: Vendor strategy

• Multi-provider: general frameworks (LangChain, Pydantic AI) or direct API.
• Single vendor: vendor SDKs (OpenAI Agents SDK, Anthropic Claude SDK).

Dimension 5: Performance sensitivity

• Latency-critical (real-time UX): direct API. Frameworks add latency.
• Cost-critical (high volume): direct API. Frameworks can add tokens.
• Standard: any framework is fine.

Dimension 6: Observability needs

• Strong out-of-box: LangChain + LangSmith.
• DIY: any framework + your own observability layer.

The shift toward direct API

A pattern we see increasingly in 2026: mature teams moving from frameworks to direct API for production.

Why:

• After 1-2 years of agent work, teams know the patterns. The framework's value (teaching patterns) is exhausted.
• Frameworks change. Direct API doesn't. Production stability favors direct.
• Performance: frameworks add overhead. Direct API doesn't.
• Debuggability: when something breaks, direct API makes "what happened" obvious.
• Customization: every production system has unique requirements. Frameworks resist customization; direct API embraces it.

This isn't an indictment of frameworks. They're great for learning, prototyping, and moderately complex production systems. But for mature production: direct API is often the better choice.

The migration pattern:

1. Start with LangChain or similar.
2. Build initial versions.
3. Learn the patterns.
4. Notice friction points (debugging, performance, customization).
5. Migrate hot paths to direct API.
6. Eventually, most production code is direct API.

This isn't a failure of frameworks; it's their natural lifecycle for some teams.

A practical decision framework

If you're choosing for a new project:

Step 1: Define the project.

• What's the agent complexity?
• How many engineers?
• Production or prototype?
• Single or multi-provider?

Step 2: Apply heuristics.

| Scenario | Recommended | |----------|-------------| | Prototype, complex orchestration | LangGraph | | Prototype, multi-agent | CrewAI | | Production, simple agent | Direct API or Pydantic AI | | Production, complex orchestration | LangGraph or custom | | Single-vendor (OpenAI / Anthropic) | Vendor SDK | | Type-safety-focused Python team | Pydantic AI | | Heavy RAG | LlamaIndex + your choice | | Microsoft shop | Semantic Kernel / Autogen |

Step 3: Prototype, then assess.

Spend a week with the chosen framework. Build a representative slice. Assess:

• Does it fit your patterns?
• Are you fighting the framework or with it?
• Is debugging tractable?
• Is performance acceptable?

If yes: continue. If no: try another or go direct.

Step 4: Don't lock in irreversibly.

Even within a framework, structure your code so that swapping is possible. Isolate the framework usage to a thin layer; build your logic in framework-agnostic code.

Patterns that travel across frameworks

Regardless of framework choice, certain patterns are universal:

Separation of concerns. Prompt management separate from agent logic separate from tool definitions separate from execution loop. Each framework helps with some; you handle the rest.

Observability. Trace every LLM call. Trace every tool call. Aggregate metrics. This is your job regardless of framework.

Step budgets and escape hatches. Every production agent has them. Frameworks don't enforce them; you must add them.

Eval suites. Frameworks don't include serious eval tooling. Build them separately (Promptfoo, Braintrust, custom).

Production hardening. Rate limits, idempotency, error handling, fallbacks. Framework gives some primitives; you build the rest.

If you focus on these universal patterns, the specific framework choice matters less. The team's discipline matters more.

Honest opinions

After working with many of these, our opinionated view:

LangChain/LangGraph: powerful but heavy. Worth learning. In production, often migrated away from for hot paths.

CrewAI: fun for multi-agent ideas. In production, the multi-agent paradigm is often wasted on tasks that didn't need it. Use selectively.

Pydantic AI: under-rated. The type safety pays dividends. Worth trying.

OpenAI Agents SDK / Anthropic Claude SDK: good if you're committed to that vendor. Otherwise, lock-in risk.

LlamaIndex: still the king for RAG-heavy work. Less compelling for general agents.

Direct API: the move for mature teams. Don't start here, but expect to end here for production-critical code.

Microsoft Autogen / Semantic Kernel: good for the Microsoft ecosystem; less compelling outside.

A migration story

To make it concrete, a real-world progression:

Month 1-3: Team builds first AI features in LangChain. Quick to ship, lots of patterns learned.

Month 4-6: Production-grade requirements emerge — observability, evals, performance. The team builds these on top of LangChain.

Month 7-9: Some LangChain abstractions become friction points. The team starts wrapping LangChain in their own interfaces.

Month 10-12: A LangChain version upgrade breaks several systems. The team rewrites hot paths in direct API. Cold paths stay in LangChain.

Year 2: Most production code is direct API. LangChain is used for occasional prototyping. The team's internal "agent framework" — built on direct API — is the standard.

This is one valid trajectory. Others are valid too — some teams stay in LangChain happily; some skip it from day one.

A different lens: what you're really choosing

Beyond the framework, you're choosing:

• A community to learn from.
• A pace of API churn to live with.
• A set of patterns to standardize on.
• A debugging experience.
• An observability story.
• A future migration cost.

The framework is one expression of these. But these are the things that affect your team day-to-day.

A framework that fits your community, your churn tolerance, your patterns, your debugging style, your observability needs — that's the right choice. Without those fits, even the most popular framework is wrong for you.

The takeaway

There is no universal best agent framework in 2026. The right choice depends on project complexity, team size, production maturity, vendor strategy, and team preferences.

A working approach:

• Match framework to project requirements using the heuristics above.
• Prototype before committing.
• Structure code so swapping is possible.
• Focus on universal patterns regardless of framework.
• Expect to evolve — what fits now may not fit in 12 months.

Many mature teams converge on direct API for production-critical code. Frameworks remain useful for prototyping, learning, and moderately complex orchestration. The choice isn't religious; it's contextual.

Pick the one that fits today. Adjust when it stops fitting. The system you build matters more than the framework you build it with.