AI Agent Orchestration Frameworks Compared:LangGraph, CrewAI, Claude Agent SDK, and the Rest of the 2026 Field

Through most of 2024, building an AI agent meant picking a model and writing your own loop around it: call the model, parse a tool call, execute it, feed the result back, repeat. By late 2025 that question had been answered well enough that a new one replaced it — not which model, but which framework should own that loop, manage the state around it, and coordinate it with other agents when one isn't enough.

The answer fractured into seven genuinely different approaches within about a year. LangChain and LangGraph both reached their first stable 1.0 release on October 22, 2025. CrewAI reported powering roughly two billion agentic workflow executions in the twelve months before its January 2026 retrospective. Microsoft spent that same window merging two previously separate frameworks — AutoGen and Semantic Kernel — into one, reaching general availability in April 2026. OpenAI, Anthropic, Google, and Amazon each shipped or matured their own opinionated SDK in parallel. None of these projects converged on a shared standard; they occupy genuinely different points on a control-versus-convenience spectrum, built by organizations with different incentives.

This guide is written for the operator or engineering lead deciding which framework to build on, not for someone already deep in one framework's specific API. It covers what each one actually is, how to choose between them for a specific workflow, and — because it's the part vendor comparison pages consistently skip — the lock-in risk and the benchmark claims worth refusing outright.

Seven names come up in nearly every serious framework evaluation as of September 2026, and each shipped a meaningful maturity milestone within roughly the same twelve-month window.

LangGraph models an agent workflow as an explicit directed graph — nodes for agents, tools, and checkpoints, edges for the (often conditional) transitions between them — which is why it pairs naturally with durable, resumable, auditable workflows. CrewAItakes the opposite bet: you describe a crew of agents by role, goal, and backstory, assign them tasks, and the framework infers the coordination, trading explicit control for a genuinely fast path to a working prototype — the company reported it had been used by more than 60% of the Fortune 500 and roughly two billion agentic executions in the year before its January 2026 report, figures we cite as CrewAI's own self-reported numbers rather than independently audited ones.

The three model-vendor SDKs each encode their vendor's own philosophy. Anthropic's Claude Agent SDK — renamed from the Claude Code SDK on September 29, 2025 — packages the same agent loop, context management, subagents, hooks, and permission system that power Claude Code itself into a library for Python and TypeScript, built around the idea of giving one agent broad, real access to an environment. OpenAI's Agents SDK, first released March 11, 2025 and updated substantially through 2026 with a new harness and native sandbox execution, is built instead around lightweight handoffs between several narrowly scoped agents, plus guardrails and tracing. Google's Agent Development Kit (ADK), open-sourced under Apache 2.0 in April 2025, is deliberately model-agnostic despite its native Gemini integration, and ships across five languages — Python, Java, Go, Kotlin, and TypeScript — with a growing third-party integrations ecosystem Google expanded in February 2026.

Amazon's entry splits into two distinct pieces worth keeping separate: Strands Agents is a genuine orchestration framework — a model-driven agent loop, open-sourced with its own Harness SDK — while Bedrock AgentCore, which reached general availability on October 13, 2025, is explicitly framework-agnostic managed infrastructure for running agents securely at scale, regardless of which of the other six frameworks actually wrote their logic.

Underneath the seven names sit five genuinely different ideas about how an agent's work should be structured, and conflating them is the fastest way to pick the wrong tool for a workflow.

• Explicit graph / state machine: LangGraph's model: you define nodes and conditional edges yourself, and get durable state, checkpointing, and time-travel debugging in return. Best fit for workflows where auditability and resumability matter more than speed of a first prototype.
• Role-based crew: CrewAI's model: describe each agent's role, goal, and backstory, assign tasks, and let the framework infer coordination. Best fit for getting a multi-agent idea working quickly, with less up-front architecture.
• Single agent, broad environment access: The Claude Agent SDK's model: one model-driven agent loop with real file, shell, and web access, coordinated through subagents and hooks rather than a graph of peer agents. Best fit for an agent that needs to do sustained, real work in an actual environment.
• Lightweight handoffs: OpenAI's Agents SDK model: several narrowly scoped agents pass a conversation between each other through explicit handoff primitives, with guardrails at each step. Best fit for a small number of specialized agents routing a user through a defined task, especially in voice or chat products.
• Managed runtime, framework-agnostic: Bedrock AgentCore's model: it doesn't prescribe an orchestration philosophy at all — it provides the sandboxed execution, memory, and gateway infrastructure underneath whichever of the other four philosophies your actual agent logic uses.

The Microsoft Agent Framework and Google ADK both sit closer to the graph/workflow end of this spectrum but add conversational, GroupChat-style coordination as a first-class option — a deliberate hedge, since Microsoft's own framework is explicitly the product of merging a graph-oriented enterprise SDK (Semantic Kernel) with a conversational multi-agent one (AutoGen).

If one event in this space should change how you think about framework selection, it's this one. Microsoft shipped a public preview of the unified Microsoft Agent Framework on October 1, 2025, a release candidate in March 2026, and reached 1.0 general availability in early April 2026 — combining Semantic Kernel's enterprise plumbing (session-based state management, type safety, filters, telemetry, and its connector ecosystem) with AutoGen's multi-agent orchestration patterns into one supported SDK for Python and .NET.

Both predecessor frameworks were placed into maintenance mode as part of the same move: AutoGen and Semantic Kernel continue to receive bug fixes and security patches, but no new features, and the community is directed toward Agent Framework for anything new. The Agent Framework Harness and Foundry Hosted Agents reached their own general availability in August 2026, completing the transition roughly ten months after the initial preview.

A second, smaller example makes the same point on a shorter timeline: OpenAI launched Agent Builder, a visual drag-and-drop canvas for multi-agent workflows, at its October 2025 DevDay alongside AgentKit — and posted a deprecation notice for it on June 3, 2026, with a scheduled shutdown of November 30, 2026. Roughly fourteen months separated the product's launch from its announced end.

Before comparing orchestration frameworks against each other, it helps to place them against the two protocols most of them now sit on top of. The Model Context Protocol (MCP) governs how a single agent discovers and calls tools — a database lookup, a search API, a file system — and every framework in this guide either speaks it natively or ships a maintained adapter. We cover MCP's foundational role in full in a dedicated guide, and this article assumes that layer exists or is being built alongside orchestration, rather than re-explaining it here.

The Agent2Agent protocol (A2A), which Google announced and later donated to the Linux Foundation, solves a different problem: how independently built agents — potentially on entirely different frameworks, written by different teams or vendors — discover each other and coordinate a task as peers, rather than as a single agent calling a tool. A2A reached its 1.0 release in April 2026, with more than 150 supporting organizations at its first anniversary, spanning cloud providers, framework vendors, and enterprises.

The practical implication for framework choice: MCP and A2A adoption is now broad enough across all seven frameworks in this guide that neither protocol should be a deciding factor between them. What differs is how natively each framework treats the two protocols — LangGraph, ADK, and Agent Framework all ship first-class support; the model-vendor SDKs treat MCP as core and A2A as an increasingly standard add-on rather than an afterthought.

With seven frameworks occupying different philosophies, the question that actually resolves a decision is "what shape is my agent" — not "which framework is best."

Two caveats worth carrying into that table. First, these are starting points, not permanent commitments — a team building a durable, checkpointed LangGraph workflow that later needs a fast-moving experimental sub-agent commonly runs both LangGraph and CrewAI in the same system rather than treating the choice as exclusive. Second, if you're still deciding whether you need more than one agent at all — as opposed to which framework should coordinate several — that's a distinct, prior question we cover directly in our multi-agent systems architecture guide, which this article assumes you've already answered.

Every framework's quickstart shows you the fastest path to a working agent. None of them show you what it costs to leave later, and that omission is the single biggest blind spot in most framework-selection decisions we see.

The lock-in mechanism is architectural rather than contractual — nothing here involves a binding contract or a proprietary data format you can't export. It happens because CrewAI's role/task decorators, LangGraph's graph-node API, OpenAI's handoff types, and the Claude Agent SDK's hooks and permission model are all different enough that agent logic written directly against one doesn't port to another without real rework. The more of your actual business logic — prompts, tool schemas, retry strategies, evaluation criteria — gets expressed directly in a framework's specific primitives, the more expensive a later switch becomes.

The mitigation is architectural too: keep a thin adapter layer between your actual agent logic and whichever framework's specific API currently orchestrates it. Concretely, that means your prompts, tool schemas, and evaluation suite should be expressible independently of the framework, with a translation layer that maps them into that framework's specific decorators or node types — not scattered directly through framework-specific classes across your codebase. Teams that do this pay a bounded, mostly mechanical cost to switch frameworks later. Teams that don't pay a much larger one, in proportion to how deeply the framework's abstractions leaked into the rest of the system — which is also the same discipline that limits blast radius if a framework, or a tool it calls, is compromised, a topic we cover in depth in our AI agent sandboxing and credential scoping guide.

Every comparison article in this space eventually produces a ranked list or a crowned winner. This one won't, and the reason is specific rather than a hedge: no independently audited, apples-to-apples benchmark runs the same set of agentic tasks across all seven frameworks under identical conditions and reports a score.

What exists instead are task-specific benchmarks — tau-bench, SWE-bench, and similar suites — that evaluate a specific model-and-scaffold combination on a narrow task type, not a framework in the abstract. Academic critiques of the broader agent-evaluation field are directly relevant here: Kapoor and Narayanan's "AI Agents That Matter" argues that accuracy-only leaderboards routinely ignore cost, reproducibility, and overfitting to the benchmark itself, and follow-up work from Princeton's HAL group on cost-controlled agent evaluation makes the same point with more recent data: a higher-accuracy agent configuration is frequently just a more expensive one, not a better-engineered one.

Applied to framework selection specifically: a vendor's own benchmark page citing a favorable number for their SDK is measuring that vendor's model paired with their own scaffold on tasks they chose, not a framework-neutral measure of orchestration quality. A comparison blog ranking frameworks by GitHub star count is measuring age, marketing reach, and how much tutorial content exists — not how reliably an agent built on that framework behaves on your specific workflow. We treat both as directional signal at best, never as a ranking to cite as fact.

Because this guide compares seven products against each other, it owes readers an explicit statement of what "compared" means here. We evaluated each framework on five axes we could verify from primary sources as of September 12, 2026: current governance and maintenance status (active development versus maintenance mode), its stated orchestration model in its own documentation, language support, its most recent GA or version milestone, and its stated relationship to MCP and A2A. Every specific date and status claim in this guide is sourced to the vendor's own blog, changelog, GitHub repository, or documentation, listed in full below.

We explicitly did not score, and refused to score: raw task-completion accuracy or speed (no credible cross-framework benchmark exists, per the section above), total cost of ownership (this depends entirely on your specific workflow's call volume and model choice, not the framework), or a composite "best overall" ranking (the frameworks solve different problems well enough that a composite score would obscure the actual decision rather than clarify it). Where a vendor's own adoption or scale figure appears in this guide — CrewAI's reported execution count and Fortune 500 usage, A2A's supporting-organization count — it is attributed explicitly as that organization's own reported number, not independently audited by us.

To re-check any of this yourself: every framework's GitHub repository publishes its own release history and current maintenance status directly, which is the fastest way to confirm whether anything in this guide has changed since publication — a real risk, given how quickly this category has moved over the twelve months this guide covers.

Frenchy Digital's own Beyond Points AI build is a concrete, published example of choosing a framework to match an agent's actual shape rather than its hype cycle. The product needed an agent with genuine, sustained access to a real environment — searching award and cash inventory across providers, transferring loyalty points, and driving a browser to complete a booking — which is precisely the "give the agent a computer" paradigm the Claude Agent SDK is built around, not a small set of narrow handoffs or a role-based crew.

The build's architecture is a Claude-based multi-agent system speaking MCP: an orchestrator delegates to specialized loyalty, transfer, browser, flight-booking, and hotel-booking sub-agents, plus a code-reviewer agent and a set of fifteen executable skills. Its cost model pairs a Sonnet-class orchestrator with Haiku-class sub-agents specifically so that long-running, multi-step work stays affordable — a pattern that generalizes past this one framework choice. In its pre-beta live run of thirty real searches, the platform averaged 4.7 orchestrator calls and roughly nine HTTP calls per search, returned ranked journeys for 29 of 30 queries (a 3.3% empty-result rate) with a 0% error rate, and a 20-second median wall time — the measured numbers the build's own case study publishes because they're the ones it can reproduce, not marketing figures.

Generalizing from that build into a build order for any team choosing and committing to an orchestration framework:

The order matters for the same reason it did in Beyond Points AI's own build: naming the agent's actual shape before naming a framework is what kept the team from adopting a role-based crew abstraction for a product that needed sustained, real-environment access instead. That same measurement discipline — a reproducible eval set, a documented pass rate, and cost tracked per call — is the topic of our AI agent evaluation and observability guide, applied here specifically to validating a framework choice rather than treated as a separate concern.

Framework-selection and agent-architecture work scopes the same way the rest of our agent-engineering work does: a discovery phase that maps your actual orchestration needs before any code changes, a single-workflow build for a first, well-scoped agent, a platform build for operators coordinating several agent types, and an enterprise band for organizations with real regulatory exposure.

Senior-led delivery runs $150 to $225 per hour, retainers run $2,500 to $9,500 per month, and every engagement carries a 30-day post-launch warranty. Book a discovery call at calendly.com/frenchydigital/discovery-call or call +1 (424) 272-5601, and you receive a written, fixed-price phased proposal within five business days.

A short, consolidated list worth checking against any framework pitch, comparison article, or vendor claim in this space, gathered from the specific claims this guide had to verify or refuse above.

This guide is explicit about where its own verification stopped. We did not independently audit any vendor's self-reported adoption or scale figures — CrewAI's reported execution count and Fortune 500 usage, or A2A's supporting-organization count — and report them here as the organizations' own published claims, attributed as such, not as numbers we verified against underlying usage data.

We also could not source a credible, methodologically transparent figure for typical framework-migration cost, and rather than repeat an unsourced vendor number, we named that gap directly in the lock-in section above. We did not run our own head-to-head benchmark across all seven frameworks — no such benchmark exists that we could find, and building one was outside the scope of this guide — so every performance-adjacent claim here is a qualitative description of each framework's stated orchestration model, not a measured comparison.

Finally, this is a genuinely fast-moving area — this guide itself documents one full framework consolidation and one full product deprecation inside a single twelve-month window. A reader making a real framework decision should treat every date, version, and maintenance-status claim here as current as of September 12, 2026, and verify anything version-specific directly against the vendor's own GitHub repository or changelog before it factors into a build decision.