Agent Frameworks Compared: A Provider-Neutral 2026 Guide

Most framework comparisons rank features. That is the wrong axis. By October 2026 the tool interface (MCP), agent-to-agent messaging (A2A) and trace context each have a shared layer, though a young one: MCP and A2A have versioned specifications ^[1][2], W3C Trace Context is a stable Recommendation ^[3], and the OpenTelemetry agent conventions are still in Development status ^[53]. The thing that decides whether an agent survives production, where its state lives and how a run resumes, is, in the documentation we reviewed, still defined separately by each framework, with no shared checkpoint specification that we could find. Our thesis: choose a framework by how much failure it survives and how cheaply you can leave, not by how many agent patterns it ships.

The field has also stopped being a free-for-all. Microsoft's AutoGen README now reads "AutoGen is now in maintenance mode." ^[4], Microsoft describes Agent Framework as "the next generation of both Semantic Kernel and AutoGen" ^[5], and LangGraph reached 1.0 in October 2025 ^[6]. The empirical record is thin and dated: a 2025 preprint of 11,910 developer discussions found AutoGen and LangChain the hardest to maintain among ten frameworks ^[7]; its limits are listed in the evidence section.

This guide compares actively maintained options on six criteria: state, tools and MCP, observability, deployment, lock-in and maturity. It uses official documentation, specification text, registry pages, the Thoughtworks Technology Radar and a few preprints, all opened on 13 October 2026. NKK has no benchmark data and publishes no ranking; the models below are NKK's opinion, built on the cited prior art.

What changed in the last twelve months

Consolidation. Microsoft's documentation calls Agent Framework "the direct successor, created by the same teams" ^[5]. Semantic Kernel still shipped version 1.45.0 on 6 October 2026 ^[9], and the sources we opened give no end-of-support date. The 2025 promise ran to one year after general availability ^[8]; the 1.0 post does not use that term ^[10], so any date counted from 1.0 is NKK inference.

A stable core with a preview periphery. The 1.0 post lists single agents, middleware, memory, graph workflows with checkpointing, multi-agent orchestration, declarative YAML, and A2A and MCP among its 1.0 features. It separately lists DevUI, Foundry hosted-agent integration, Skills and Agent Harness as early-adoption features whose APIs may change, and said A2A 1.0 support was "coming soon" ^[10]. The overview page marks Go as public preview ^[5]. "1.0" describes the core, not everything around it.

Governance of the open protocols. MCP, goose and AGENTS.md were contributed to the new Agentic AI Foundation in December 2025 ^[11]. A2A v1.0.0 was released on 12 March 2026 and v1.0.1, a bug-fix release, followed in late May ^[12]. In April the Linux Foundation called 1.0 the project's first stable specification and reported more than 150 supporting organisations ^[13]. NIST launched an AI Agent Standards Initiative in February 2026; its page lists a request for information and a draft concept paper but no final guidance ^[14].

Four families, not one category

LangGraph and the OpenAI Agents SDK are different kinds of product, and a feature-by-feature comparison hides that. We group the field into four families by what each project says it is for. The grouping is NKK's, and the boundaries blur.

Model-provider SDKs. The OpenAI Agents SDK centres on agents, handoffs, guardrails, sessions, built-in MCP integration and tracing, and uses the Responses API by default for OpenAI models ^[17]. Anthropic's Claude Agent SDK is described in its own docs as "A library that runs the Claude Code binary" ^[18]. It spawns a claude subprocess per session that owns a shell and working directory, so hosting is stateful rather than a stateless API wrapper ^[19]. In our view both are the most direct path to a vendor's newest model features and pay for it in portability.

Cloud-platform frameworks. Microsoft Agent Framework reached 1.0 for .NET and Python, with Go in public preview ^[10][5], and ships first-party connectors for Foundry, Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini and Ollama ^[10]. Google's ADK is open source, available in Python, TypeScript, Go and Java, and deploys to Agent Runtime, Cloud Run or GKE ^[20]. Strands Agents is an open-source toolkit for Python and TypeScript with documented deployment targets from AWS Lambda to Amazon EKS and Bedrock AgentCore, and its documentation names no maintainer, so we do not attribute one; we place it here only because of those AWS deployment targets ^[21]. Thoughtworks put ADK at Trial, "pre-GA in parts", suiting teams invested in Google's platform ^[22].

Orchestration runtimes. LangGraph describes itself as "a low-level orchestration framework and runtime for building, managing, and deploying long-running, stateful agents" and can be used without LangChain ^[23]. LlamaIndex Workflows is an event-driven, step-based execution model that ships with llama-index-core and can be installed standalone ^[24]. CrewAI nests teams of agents (Crews) inside event-driven Flows, which its documentation calls the backbone of an application ^[25].

Lean or language-specific libraries. Pydantic AI presents a typed, extensible agent loop in which every model is a string swap away, a vendor claim we could not test ^[26]. Mastra is a TypeScript framework Thoughtworks places at Assess for teams committed to TypeScript ^[27]. Thoughtworks had Pydantic AI at Trial in November 2025 (Assess in April 2025), but the entry is no longer on the current edition ^[28]. Haystack has an agent component with MCP tool support and a state_schema ^[29]. smolagents has agents write actions as code, with sandbox options ^[30]. We found too little to characterise the Vercel AI SDK beyond its self-description as a TypeScript toolkit ^[31].

The six criteria, and what the docs actually say

The two tables below keep to claims we could trace to an opened page; where a page was silent, the cell says "Not stated". LlamaIndex Workflows and Strands are omitted for space; the first keeps per-run state in ctx.store and holds clients and models in Resource objects kept out of serialised state ^[24], and the second lists Bedrock, OpenAI, Anthropic, Google, LiteLLM and Ollama among its model providers ^[21].

Three patterns stand out. First, state is the widest gap between documentation and production. LangGraph says its in-memory saver loses all checkpoints after a restart and recommends a persistent checkpointer for production ^[32]. ADK says its in-memory services are for local testing and lose data on restart ^[33]. The Claude Agent SDK's transcripts, memory files and working-directory artifacts live on local disk and do not survive a container restart, a scale-down or a move to another node ^[19]. OpenAI's default session backend is SQLite, and its in-memory form is not durable ^[34]. CrewAI's @persist also defaults to SQLite ^[35]. In the five defaults we checked, state sits in memory or in local files, so in our reading production durability is your job.

Second, every framework in the grid documents MCP support, but unevenly. ADK consumes MCP servers through McpToolset over stdio, Streamable HTTP and SSE ^[36]. CrewAI's adapter primarily supports MCP tools, and its docs say prompts and resources are not directly integrated at this time ^[37]. LangChain's adapter is in beta and may change ^[38]. No source we opened documents support for the 2026-07-28 revision.

Third, version numbers and registry recency say little about maturity, so the grid shows classifiers and Radar placements, not versions. The chart below is registry activity, not quality: days since each Python package's latest PyPI release on 13 October 2026, in alphabetical order. Pydantic AI, Haystack, Mastra and ADK TypeScript are not charted. AutoGen is the outlier, consistent with its maintenance-mode notice ^[4]. LlamaIndex is the llama-index meta-package, not the separate Workflows package this guide discusses, which releases separately.

Durability is the criterion teams under-test

Thoughtworks places "Ignoring durability in agent workflows" in Caution in Radar Vol. 34 and advises teams to start with native durable execution support in their framework, reaching for standalone platforms as workflows become more critical ^[49].

The documentation we reviewed shows a spectrum, not a switch. We call it the NKK Durability Ladder. It grades a setup by what survives when you kill the process mid-run.

Here is how the documented options map to the ladder; the mapping is NKK's reading. L4 and L5 are alternative routes rather than strict successors. A framework-native checkpointer with a human pause can be stronger than a poorly wrapped external engine, and L5 is "higher" mainly for retries and side-effect control.

• LangGraph: L2 with the in-memory saver; L3 with a Postgres-backed checkpointer; L4 with its human-in-the-loop pause ^[32][6].
• Microsoft Agent Framework: L2 with in-memory or file storage; L3 with the Cosmos DB provider, which the docs recommend for production but which is a separate package installed with --pre ^[50]. We did not test an approval pause.
• OpenAI Agents SDK: L2 with its SQLite default ^[34]; L5 only through an external engine. Temporal's integration runs the loop in a Workflow and model calls as retried Activities, with sandbox support pre-release and streaming experimental ^[51].
• Claude Agent SDK: L2 by default; a SessionStore adapter mirrors transcripts to shared storage, which reaches L3 for transcripts only ^[19].
• Google ADK and CrewAI: L2 by default (in-memory services; @persist to SQLite) ^[33][35]. We did not map their persistent options.
• Pydantic AI: delegates durability to external engines (L5) and lists nine engines, the first five co-maintained with the vendor teams ^[26].

To apply the ladder, set the level each workflow needs before you pick a framework: a drafting assistant a user can rerun needs L2; a support agent whose conversations must survive a redeploy and be picked up by any worker needs L3; an approval chain that waits days for a manager needs L4; a workflow that calls payment or ticketing systems, where retries must not repeat side effects, needs L5. Then run a kill test: stop the process mid-run, redeploy a changed graph, and see what is lost.

Protocols and telemetry: the portable layer, still moving

The shared specifications are the reason a framework switch is survivable. They are also young. MCP's current revision, 2026-07-28, made requests stateless, removed protocol-level sessions and the Mcp-Session-Id header, moved experimental tasks into an extension, and deprecated Roots, Sampling and Logging ^[16]. Deprecated features normally stay at least twelve months before removal (ninety days under an expedited-removal exception) ^[1]. A2A 1.0.0 defines JSON-RPC, gRPC and HTTP+JSON bindings and an Agent Card that describes an agent's identity, skills and authentication needs ^[2]; v1.0.1 followed with bug fixes ^[12]. A May 2025 survey frames MCP as tool access and A2A as peer task delegation ^[52]; its protocol details predate both current versions.

Telemetry is less settled. The OpenTelemetry agent-span conventions, which define operation names such as create_agent, invoke_agent and invoke_workflow, carry Development status, not Stable ^[53]. Microsoft Agent Framework follows them and, when OTEL_SEMCONV_STABILITY_OPT_IN is unset, uses the latest experimental attribute names ^[54]. In its Python implementation, MCP trace propagation into params._meta applies only to MCP sessions the agent process opens itself, not to provider-hosted MCP tools ^[54]; it builds on the traceparent and tracestate headers defined by W3C Trace Context ^[3]. The OpenAI Agents SDK's tracing page lists processors for Langfuse, MLflow, Datadog and others but does not describe native OpenTelemetry export ^[55].

Portable does not mean trustworthy. The spec itself says tools "represent arbitrary code execution and must be treated with appropriate caution" and admits MCP cannot enforce its security principles at the protocol level ^[56]. A study accepted to DSN 2026 analysed 67,057 servers across six public registries and flagged 833 as vulnerable ^[57], and a preprint benchmark built on 45 live servers recorded a highest attack success rate of 72.8% among 20 models ^[58]. Thoughtworks cautions against making MCP the default integration layer, arguing a well-designed CLI can often give an agent what it needs with less protocol overhead. The entry says it is not a rejection of MCP, which adds value for structured tool contracts, OAuth boundaries and governed multi-tenant access ^[59].

OWASP's Top 10 for Agentic Applications names Tool Misuse, Identity and Privilege Abuse and Agentic Supply Chain Vulnerabilities among its ten entries ^[60]. The practical rule: pin the MCP revision, A2A version and semantic-convention version you build against, and treat a spec revision as a migration.

Lock-in has layers: the NKK Exit-Cost Map

"Provider-neutral" is a claim about layers, not products. A framework can be open source and still tie your traces to one backend, your state to one database schema and your tools to one revision of a protocol. We split lock-in into six layers and ask, for each, what a standard interface would let you keep and what you would have to rewrite.

The evidence for each trap is specific. On non-Responses backends the OpenAI Agents SDK silently drops Responses-only fields unless strict validation is on, rejects features such as hosted tool search, and describes its Any-LLM and LiteLLM adapters as best-effort beta layers ^[61]. Its default tracing uploads to OpenAI's servers, so a second provider without an OpenAI key means another processor or disabling it ^[61]. LangGraph's library is usable without LangChain, but its managed cloud requires a Plus plan and its self-hosted control plane an Enterprise plan ^[62]. Microsoft warns that third-party systems and non-Azure Direct models fall under their own terms and that data-boundary responsibility is yours ^[5]. AWS says AgentCore will "Build with any open-source framework and any model", a vendor claim, and several AgentCore items are labelled preview ^[63]. Authoring is the biggest rewrite, but it is unavoidable. State is the biggest avoidable cost: we found no shared checkpoint specification, formats differ by framework, and the framework default is easy to leave in place.

Where it breaks: the standards are unstable, so "portable" means portable to a versioned spec, and the map does not price commercial terms.

A selection flow you can run in an hour

The best-supported advice in our sources is restraint. Anthropic separates workflows, orchestrated "through predefined code paths", from agents that direct their own process, suggests starting with direct API calls, and notes that frameworks can obscure prompts and responses ^[64]. Microsoft's guide says "If you can write a function to handle the task, do that instead of using an AI agent." ^[5] Thoughtworks moved LangGraph out of Adopt, arguing a global shared-state graph is "not always the best approach" and that it is no longer "the default choice for building every agentic system" ^[65]. These point the same way: use the least machinery that meets your durability needs.

The NKK Framework Selection Flow turns that into seven gates. It ends in a family and a spike, not a product.

In our view, gates 1 to 3 narrow the shortlist more than gates 4 to 6, and gate 3 changes it most, because it is where framework defaults stop being enough. The flow ignores commercial terms and team skills, and orders questions rather than scoring products.

What the evidence does not show

• No neutral benchmark. We found no reproducible cross-framework benchmark for latency, cost or accuracy, and we publish none. The 2025 preprint ^[7] calls performance optimisation a common shortcoming of all ten frameworks it studied but compares none. Its abstract also asserts that more than 80% of developers struggle to pick a framework; we found no method behind that figure, so we do not use it.
• Developer-pain evidence is thin. A second preprint finds that retrieval and orchestration problems are less visible and more complex than installation and prompting, and tend to persist as maintenance burdens on GitHub ^[66]. It reflects problems people choose to post on Stack Overflow and GitHub, not a census of production failures. The first preprint ^[7] studied 11,910 discussions (its Section 3) that developers chose to post, blames AutoGen's maintenance burden on its 0.2-to-0.4 migration and LangChain's on breaking API changes, and picked ten frameworks by GitHub topic-tag frequency with data to July 2025, so it excludes the OpenAI Agents SDK, Google ADK and Microsoft Agent Framework ^[7][8].
• Maturity signals conflict. Claude Agent SDK is tagged Alpha on the registry while Anthropic's docs present it for building production agents ^[43][18]. Version numbers and classifiers are a snapshot, not a quality rating.
• Gaps in the documentation. We could not read LangGraph's durability modes (the section was empty), or CrewAI's observability and deployment story. Whether any framework supports MCP 2026-07-28 is unverified.
• Vendor-authored sources. Anthropic, OpenAI, Google, Microsoft and LangChain describe their own products; we used them for what each says it does, not for comparisons.
• A moving target. Radar Vol. 34 was the latest published volume when we checked; re-check for a newer one before relying on its placements.

What to do next

1. Write a one-page requirements sheet: language, cloud, providers, telemetry backend, data residency and the Durability Ladder level for each workflow.
2. Run the Selection Flow's first three gates before shortlisting any product.
3. Pick two candidates from different families and build one thin vertical slice with durable state, tracing and one vetted MCP server.
4. Run the kill tests: restart the process mid-run, redeploy a changed workflow, swap the model provider, swap the trace backend. Record what breaks and how long the fix takes.
5. Score the Exit-Cost Map and write down the most expensive layer. Own the state database and export traces through OpenTelemetry where you can.
6. Pin the framework, MCP revision, A2A version and semantic-convention version, and subscribe to release notes. Plan migrations as projects.
7. Re-assess every six months. Consolidation in this field has been fast enough that last year's default can be this year's maintenance-mode project.

Conclusion

No framework wins every criterion, and the sources do not support a ranking. What they support is a discipline: use the least machinery that meets your durability needs, keep tools on MCP and traces on OpenTelemetry, and treat state as an asset you own rather than a feature you rent. Choose the one whose failure behaviour and exit cost you have tested yourself.