What Actually Differs Between Agent Frameworks
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.
Summary
- Frameworks differ on a small set of engineering axes - orchestration model, state and persistence, tool contracts, multi-agent topology, observability hooks, language ecosystem, and operational maturity - not on "smarter agents."
- Insight: Picking on demo speed alone often locks you into a control model that fights production requirements (HITL, resume, least privilege, cost caps).
- Key Concepts: orchestration model, shared state, checkpointing, role vs graph, structured outputs, provider-native vs portable, lock-in surface.
- When to Use: First framework evaluation, ADR write-ups, or when a POC works but production needs force a second look.
- Limitations/Trade-offs: Axes blur: a graph library can host roles, a role framework can embed graphs, and "native SDKs" keep expanding. Treat labels as defaults, not cages.
- Related Topics: framework-free runtimes, team skill match, migration paths, architecture patterns independent of SDKs.
Foundations
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:
- Orchestration model - graph, role/crew, linear agent, workflow UI, or thin SDK primitives.
- State handling - ephemeral message lists vs typed shared state vs checkpoints and resume.
- Tool and schema story - free-form functions, typed tools, MCP, enterprise connectors.
- Multi-agent defaults - sequential crews, hierarchical managers, handoffs, or "bring your own topology."
- Ecosystem and ops - language, cloud affinity, tracing products, hosting assumptions, community depth.
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) checkpointMechanics & Interactions
Orchestration model
| 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 handling
State is where prototypes and production diverge.
- Message-list state is easy: append chat turns and tool results. It bloats fast and is hard to resume cleanly.
- Typed shared state (dicts / Pydantic / reducers) lets nodes read and write structured fields without replaying the whole transcript.
- Checkpoints persist state so a run can pause for a human, recover from process death, or continue tomorrow.
- External memory (vector stores, SQL, caches) is not the same as run state; frameworks that blur them make debugging harder.
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.
Tool contracts and side effects
Every serious framework eventually becomes a tool host. Differences that matter:
- How tools are declared (decorators, schemas, OpenAPI, MCP servers).
- Whether tool errors are first-class and retryable.
- Whether tool allowlists can differ per role or node.
- Whether irreversible tools can require approval mid-run.
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 topology
"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.
Ecosystem and operational maturity
Honest non-hype factors:
- Language fit: Python-heavy data/backend vs TypeScript product surfaces.
- Cloud gravity: Microsoft stack affinity vs multi-cloud neutrality vs Vercel-centric deploy.
- Observability: first-party tracers vs OpenTelemetry-friendly vs DIY logs.
- Release maturity: 1.0 APIs and deprecation discipline vs fast-moving research APIs.
- Hiring and docs: can a new mid-level engineer debug a failed run next quarter?
Ecosystem is not "best community wins." It is "can your team operate this under load when the model is wrong."
Advanced Considerations & Applications
Compose frameworks instead of worshipping one
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.
Cost and reliability coupling
Framework choice changes cost shape more than model price cards suggest.
- Graph with tight edges can reduce wasted tool calls.
- Role crews can multiply tokens via chatter between agents.
- No-code retries can hide spend in platform logs.
- Thin SDKs make it easy to forget host-level max turns and timeouts.
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.
Security surface
Frameworks expand attack surface when they:
- Autoload many tools into one agent.
- Treat tool output as trusted instructions.
- Store secrets in shared agent config objects.
- Make sandboxing "optional for demos" that ship unchanged.
Prefer frameworks that make least privilege natural (per-node tools, approval nodes) over those that only make maximum autonomy easy.
Decision trade-offs (two or more approaches)
| 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 |
Common Misconceptions
- "The framework makes the agent intelligent." Intelligence is mostly model + tools + data; the framework sequences work.
- "More multi-agent features means more production-ready." Often the opposite if coordination is unneeded complexity.
- "If it supports tools, state is solved." Message logs are not durable, queryable business state.
- "Native SDK means zero lock-in." You avoid one open-source graph only to couple to provider agent primitives.
- "No-code is only for non-engineers." Engineers use it for glue; the risk is unreviewed side effects, not the audience.
- "You must standardize on one framework company-wide." Standardize interfaces and ADRs; allow two stacks if product surfaces differ (for example TS UI vs Python workflows).
FAQs
What is the single most important axis when comparing frameworks?
Orchestration model (how the next step is chosen). Everything else is secondary until control flow matches the task.
How is LangGraph different from "just using LangChain"?
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 does CrewAI make more sense than a graph library?
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.
Is Microsoft Agent Framework only for Azure shops?
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.
Where does LlamaIndex fit if I already have orchestration?
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.
Why do people pair Pydantic AI with other frameworks?
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.
Are OpenAI Agents SDK (or similar native kits) "frameworks"?
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.
Is Vercel AI SDK an agent framework?
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 is no-code the honest best choice?
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.
Do frameworks replace architecture patterns like ReAct?
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.
What should I write in an ADR about framework choice?
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.
How often do these differences change?
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.
Related
- Choosing a Framework Basics - same task, two frameworks side by side
- Framework Comparison Matrix: LangGraph, CrewAI, Microsoft Agent Framework & More - ranked reference table
- Framework-Free vs Framework-Based: When to Roll Your Own - custom runtime trade-offs
- Matching Team Skill Set to Framework Choice - language and team-size fit
- The LangGraph Mental Model: Agents as State Graphs - graph control model
- The Three Core Agent Architecture Patterns, Compared - pattern vocabulary independent of SDKs
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.