Claw chronicles: The framework civil war and why nobody wins

I’ve been tracking the agent framework space since late 2024, and I think April 2026 is the month it became officially absurd.

Here’s the lineup of “production-ready” agent SDKs that exist right now:

Microsoft Agent Framework 1.0: shipped April 3, merging Semantic Kernel and AutoGen into one SDK. 75,000+ combined GitHub stars between the two predecessors. .NET and Python. Built on Microsoft.Extensions.AI.
Google ADK: open source, TypeScript and Python, tightly integrated with GCP, pushing the A2A protocol hard. 50+ partners.
OpenAI Agents SDK: released March, lightweight, voice-first, designed for the ChatGPT platform but usable standalone.
Anthropic Claude Agent SDK: shipped alongside Claude 4.6, OS-level access model, the “give the agent a computer” philosophy.
LangGraph: the veteran, battle-tested through multiple production iterations, still the community favorite for complex multi-agent workflows.
CrewAI: the “team of agents” pattern, popular for use cases where you want role-based agent collaboration.

Six major frameworks. All claiming production readiness. All solving the same problem. All incompatible with each other by default.

This is a civil war, and the only thing being destroyed is developer sanity.

The Microsoft Move

Microsoft’s Agent Framework 1.0 is the most interesting release this month, and not because it’s technically the best. It’s interesting because of what it signals.

Microsoft took two of the most successful open-source agent projects, Semantic Kernel (the plugin/connectivity layer) and AutoGen (the orchestration layer), and merged them into a single, unified SDK with a long-term support commitment. They also baked in support for both MCP (Anthropic’s tool protocol) and A2A (Google’s agent interoperability protocol) from day one.

Read that last sentence again. Microsoft shipped a framework that natively supports the protocols from its two biggest competitors. That’s not an accident. That’s Microsoft saying: “We don’t care which protocol wins. We care that our framework speaks all of them.”

This is classic platform strategy, and Microsoft has played it better than anyone since the 1990s. The lesson from the browser wars, the cloud wars, and the mobile wars is always the same: own the platform, make the platform interoperable, and let developers build on top of it. If every protocol speaks to your framework, you become the default choice regardless of which model or protocol underneath wins.

The .NET integration is the real moat. There are millions of enterprise developers who live in the .NET ecosystem, and they haven’t had a first-class agent framework until now. Semantic Kernel existed, but it was always a “connectivity” layer, plugins and connectors, not agent orchestration. AutoGen existed, but it was research-oriented and Python-first. Agent Framework 1.0 gives the enterprise .NET crowd exactly what they’ve been waiting for: agents with production observability, evaluation tooling, and familiar hosting patterns.

The Real Winner: A2A

But the most important story in the framework space isn’t any single framework. It’s A2A.

Google announced the Agent-to-Agent protocol in April 2025. Within a year, it’s been donated to the Linux Foundation, grown to 150+ participating organizations, and shipped a v1.0 spec. IBM has articles about it. Microsoft’s framework supports it. Salesforce and ServiceNow are building on it.

A2A solves the problem that all six frameworks create: interoperability. Without A2A, an agent built with Claude Agent SDK can’t talk to an agent built with Google ADK. They’re siloed. Separate namespaces, separate state machines, separate everything. A2A gives agents a common language, able to discover each other, delegate tasks, and collaborate across framework boundaries.

Think of it like HTTP for agents. It doesn’t matter what web framework you use on the server (Rails, Django, Express, ASP.NET), they all speak HTTP. A2A is trying to be that common protocol layer so agents built with different frameworks can actually work together.

Gartner predicts 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from less than 5% in 2025. If that happens, the interoperability problem becomes critical fast. You’re not going to have one monolithic agent that does everything. You’re going to have a procurement agent, a support agent, a data analysis agent, and a code review agent, and they need to hand off tasks to each other. The framework each one is built with doesn’t matter; the protocol they speak does.

Why I’m Skeptical of Framework Picks

Every “which framework should I use” article I’ve read this month offers the same formula: “it depends on your use case.” And then proceeds to give generic guidance that’s basically useless.

My take: pick the framework that matches your existing infrastructure, not the one with the best benchmarks.

You’re a .NET shop? Microsoft Agent Framework. It’s not even close. The integration with your existing DI containers, logging, and hosting infrastructure is the real value, not the agent orchestration patterns.
You’re all-in on GCP? Google ADK. The Agent Engine integration and A2A native support make it the path of least resistance.
You want a general-purpose agent that runs on a developer’s machine and has OS-level access? Claude Agent SDK. The “give it a computer” model is actually different from the API-only approaches.
You’re building something experimental or need maximum flexibility? LangGraph. The community extensions and battle-tested patterns are unmatched.
You need voice? OpenAI Agents SDK. That’s their differentiator and they’re leaning into it hard.

The dirty secret of the framework war is that the orchestration patterns (supervisor, pipeline, peer-to-peer) are all basically the same. The real differences are in the integration layers, the hosting models, and the tool ecosystems. Pick based on those, not based on which company’s blog post has the coolest demo.

What NanoClaw Taught Me

Running NanoClaw daily has given me a perspective I don’t see in many framework comparisons: the framework matters less than you think once you’re in production.

NanoClaw is essentially a harness: it wraps Claude Code in a container, adds scheduling, memory, messaging, and tool access. It doesn’t use any of the six frameworks above. It doesn’t need to. The model is smart enough that the “framework” is mostly just prompt engineering, context management, and tool definitions. The heavy lifting is done by the model, not by some orchestration middleware.

I think a lot of teams are over-investing in framework selection when they should be investing in context management, tool design, and failure handling. The framework is maybe 20% of what makes an agent work well in production. The other 80% is: what context does the agent have, what tools can it call, what happens when things go wrong, and how does the human stay in the loop?

Prediction

Within 18 months, the framework distinction will matter even less than it does today. A2A will mature to the point where interoperability is table stakes, and MCP will be the standard tool protocol (it already practically is). The frameworks will converge on the same patterns and differentiate only on ecosystem and hosting.

The real competition will shift to the model layer (which it always does) and the harness layer (which I wrote about yesterday). The framework in the middle will become commoditized plumbing, necessary but not something you think about.

Until then, we’re going to have six months of blog posts, tutorials, and conference talks about “choosing the right agent framework.” My advice? Pick one. Ship something. You can always switch later. The protocol layer will make it possible.

Claw Chronicles is a daily dev diary about the AI agent ecosystem. I run NanoClaw and have opinions. Today’s opinion is that the framework war is mostly noise. Pick based on your stack, ship based on your users, and let A2A handle the rest.