Search across all documentation pages
Most agent frameworks claim the same surface features: tools, multi-step runs, memory, and some form of multi-agent support. The useful differences live underneath the marketing: how control flow is modeled, how state is stored and resumed, which languages and platforms the stack assumes, and what you still have to build yourself.
This page is a comparison vocabulary for LangGraph, CrewAI, Microsoft Agent Framework, LlamaIndex, Pydantic AI, native provider SDKs, Vercel AI SDK, and no-code builders. Use it before you rank products in the framework comparison matrix.
An agent framework is software that owns (or strongly shapes) the loop: when the model is called, how tools are registered and executed, what context is kept between turns, and how a run ends.
It is not the model, the vector database, or your business APIs. Those are dependencies the framework wires for you - or forces you to wire in its preferred way.
What actually differs:
A useful analogy: frameworks are traffic control systems, not engines. The LLM is the engine; the framework decides lanes, signals, and who gets to drive next.
User goal / event
|
v
[Framework control plane]
- route / plan / role pick
- call model
- execute tools
- update state
- stop / handoff / pause
|
v
Result + traces + (optional) checkpoint| Style | Mental model | Typical homes | Strength | Weakness |
|---|---|---|---|---|
| Graph / state machine | Nodes + edges over shared state | LangGraph; Microsoft Agent Framework workflows | Explicit control, branching, resume | Steeper design upfront |
| Roles / crew | Named agents + tasks | CrewAI | Fast multi-role prototypes | Convergence and debugging can be fuzzy |
| RAG-first agent | Index + query + tool agents | LlamaIndex | Strong data/query pipelines | Not always the best pure orchestration core |
| Schema-first agent | Typed I/O + tools | Pydantic AI (+ Instructor patterns) | Validation and type safety | Less "crew theater" out of the box |
| Provider-native | Agents, handoffs, guardrails from one vendor SDK | OpenAI Agents SDK; similar ADK-style kits | Fast path with that provider | Portability and multi-cloud friction |
| UI + streaming agent | Front-end streams + tool UI | Vercel AI SDK | Excellent product UX in TS/React | Backend orchestration often still elsewhere |
| No-code / low-code | Visual nodes and triggers | n8n, Zapier AI actions | Speed for process automation | Complex control flow and versioning hurt |
Orchestration choice is architecture with an install command. If your real need is a bounded ReAct loop, a heavy multi-agent crew is overhead. If your real need is approval gates and resumable long runs, a chat-agent helper class will feel incomplete.
State is where prototypes and production diverge.
LangGraph-class systems lean into shared state and checkpoints. Crew-class systems lean into role context and task outputs. Pydantic AI leans into validated structured results. No-code tools often hide state in node outputs that are awkward to unit test.
Every serious framework eventually becomes a tool host. Differences that matter:
Native SDKs and MCP support change quickly (verify at build). Portable design still means: your tools are pure-ish functions with schemas you own, not only framework-specific classes.
"Multi-agent" is not one feature.
| Topology | What it means | Common fit |
|---|---|---|
| Sequential pipeline | A then B then C | Document pipelines, ETL-ish research |
| Hierarchical | Manager delegates to workers | Broad goals with review |
| Peer handoff | Agent A transfers to B with a packet | Support escalations, specialty skills |
| Graph of specialists | Explicit edges and join points | Production workflows with audits |
| Single agent, many tools | Not multi-agent | Most early products |
Frameworks bias you toward one topology. CrewAI makes roles easy; graphs make edges explicit; native handoff APIs make transfer easy; no-code makes linear happy-paths easy. Pick the bias that matches your default topology, not the one with the flashiest multi-agent demo.
Honest non-hype factors:
Ecosystem is not "best community wins." It is "can your team operate this under load when the model is wrong."
Production systems often stack layers:
| Layer | Example choices | Job |
|---|---|---|
| Product UI streaming | Vercel AI SDK | Tokens to the browser, tool UI |
| Validated backend agent | Pydantic AI / custom FastAPI loop | Types, tools, policies |
| Long-running workflow | LangGraph / Microsoft workflows | Branch, checkpoint, HITL |
| Knowledge access | LlamaIndex / your RAG service | Retrieval quality |
| Automation glue | n8n | SaaS triggers and ops scripts |
The failure mode is forcing one library to own every layer. The success mode is clear boundaries: UI SDK does not become your durable workflow engine by accident.
Framework choice changes cost shape more than model price cards suggest.
Reliability features (timeouts, circuit breakers, eval gates) may be built-in, plug-in, or your job. Assume "your job" until proven otherwise in docs for your pinned versions.
Frameworks expand attack surface when they:
Prefer frameworks that make least privilege natural (per-node tools, approval nodes) over those that only make maximum autonomy easy.
| Approach | Choose when | Avoid when |
|---|---|---|
| Graph orchestration | Branching, resume, auditability matter | You only need a 3-turn tool chat |
| Role/crew orchestration | Multi-role demos and content pipelines | You need strict state machines and SLOs day one |
| Schema-first thin agent | Typed backends, tool-heavy APIs | You need rich multi-agent choreography first |
| Provider-native SDK | Single-provider bet, speed to value | Multi-model portability is a hard requirement |
| No-code builder | Internal ops automation, non-dev owners | Complex branching, strict testing, deep security review |
| Custom runtime | Extreme control, thin dependencies | Team cannot maintain loop, tools, and ops plumbing |
Orchestration model (how the next step is chosen). Everything else is secondary until control flow matches the task.
LangGraph emphasizes explicit graphs and shared state for agent control flow. Classic chain helpers are linear composition tools; many teams use both, but the agent control plane is the graph.
When your problem is naturally "roles with tasks" and you value speed of multi-agent prototyping over explicit edge control. Move toward graphs when you need deterministic branching, resume, and strict audits.
It has strong enterprise and Microsoft-ecosystem gravity (Semantic Kernel lineage, connectors, governance stories). Non-Azure teams can use it, but evaluate whether that gravity helps or taxes your stack.
As a strong retrieval and knowledge layer. Many systems use LlamaIndex for indexes/query engines and another framework (or custom code) for the long-running control loop.
Pydantic AI focuses on type-safe agents and structured outputs. Teams often keep it for backend correctness while using a graph or UI SDK for workflow and streaming.
Yes in the practical sense: they own loop primitives, tools, handoffs, and guardrails. They are thinner and more provider-aligned than full multi-vendor orchestration platforms.
It is primarily a TypeScript AI application SDK with strong streaming and tool/UI patterns. It can host agent loops, but deep durable orchestration often lives in a backend framework or service.
When the workflow is integration-heavy, ownership sits with ops/business teams, and failure modes are acceptable for visual builders. Graduate to code when branching, testing, and security reviews dominate.
No. They implement patterns. You still choose ReAct, plan-and-execute, multi-agent handoff, or hybrids. See the agent architectures section for pattern-first design.
Orchestration model, state/resume needs, language, provider portability, observability plan, team skills, and exit criteria for revisiting the choice. Link a spike result, not a vendor blog.
APIs and version numbers change quickly; the axes (control, state, tools, ops) stay stable. Re-verify version-sensitive claims at build time against current docs.
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.
Reviewed by Chris St. John·Last updated Jul 16, 2026