[release] 5 min · Apr 13, 2026

Microsoft Agent Framework 1.0 — The Protocol Bet Matters More

Microsoft merged Semantic Kernel and AutoGen into one production SDK. The real commitment is MCP plus A2A as the enterprise agent coordination layer.

#ai-agents#mcp#a2a#microsoft#agentic-infrastructure

Microsoft shipped Agent Framework 1.0 on April 3, 2026 — a production-ready, open-source SDK that collapses Semantic Kernel and AutoGen into a single programming model for .NET and Python. The release locks in MCP as the tool layer, declares A2A as the agent networking layer (with full A2A 1.0 support listed as “coming soon”), and ships stable LTS APIs backed by a long-term support commitment. Enterprise teams that spent Q1 paralyzed choosing between Semantic Kernel’s governance story and AutoGen’s orchestration power no longer have a decision to make. Microsoft made it for them.

TL;DR

  • What: Microsoft merged Semantic Kernel and AutoGen into Agent Framework 1.0 — one production SDK, stable APIs, .NET and Python
  • Protocol bet: MCP for tool discovery, A2A for cross-runtime agent coordination — this is the enterprise agent architecture stack now
  • Why it matters: The SDK is the easy part. The protocol commitment underneath is the real lock-in decision enterprises should scrutinize
  • Action: If you are on Semantic Kernel or AutoGen today, start the migration assistants. If you are evaluating agent frameworks, this is the new enterprise default — with one caveat on A2A maturity

Microsoft Agent Framework 1.0 — What Happened

After hitting Release Candidate in February and locking the feature surface, Microsoft hardened Agent Framework 1.0 through months of real-world validation with customers and partners before declaring it production-ready. The unified SDK delivers enterprise-grade multi-agent orchestration with patterns including sequential, concurrent, handoff, and group chat — pulling AutoGen’s orchestration innovations into Semantic Kernel’s enterprise foundation.

The connector story is unusually complete for a 1.0 release. First-party service connectors ship for Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini, and Ollama. No custom provider adapters required. For teams running multi-provider strategies (and every enterprise should be), this eliminates weeks of integration plumbing.

Two features stand out for production teams. First, a middleware pipeline lets you inject content safety filters, compliance policies, logging, and custom logic at every execution stage without touching agent prompts. This is the enterprise governance requirement that most open-source frameworks punt on entirely. Second, DevUI — a browser-based local debugger — visualizes agent execution, message flows, tool calls, and orchestration decisions in real time. DevUI ships as preview (its API may evolve based on community feedback), but it is functional today and immediately useful for debugging multi-agent workflows where print statements stopped being adequate about three agents ago.

If you are running Semantic Kernel in production today, the migration assistants are the first thing to try. They analyze your existing code and generate concrete upgrade plans — far more useful than reading migration docs and guessing at impact.

For teams migrating from either predecessor framework, Microsoft ships migration assistants that analyze existing code and generate step-by-step upgrade plans. This is not a “rewrite from scratch” situation — it is a guided path, which matters when you have thousands of lines of Semantic Kernel plugin code in production.

Why This Matters

The SDK merge is the obvious headline, but it is not the interesting decision. Unifying two frameworks into one was an inevitability the moment Microsoft started maintaining both — the maintenance cost alone demanded it. What matters is what Microsoft chose to build on top of.

Agent Framework 1.0 bets hard on two protocols. MCP (Model Context Protocol) handles tool discovery and invocation: agents can dynamically find and call tools from any MCP-compliant server at runtime, without hardcoded integrations. A2A (Agent-to-Agent protocol) handles cross-runtime coordination — agents built on different frameworks, different languages, different vendors can discover and collaborate with each other. MCP is already mainstream, with 97 million monthly SDK downloads across Python and TypeScript and first-class client support in Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code. A2A is the newer, less proven bet.

This protocol stack is the real commitment, and it is the one enterprises should be scrutinizing carefully. An SDK you can swap. A protocol your agents speak to discover tools and coordinate with other agents? That is infrastructure-level lock-in. If MCP + A2A holds as the industry standard, Agent Framework 1.0 becomes the sensible enterprise default by a wide margin — it is open-source, multi-provider, governance-aware, and built by the company that owns the Azure deployment target most enterprises already use.

But “if” is doing heavy lifting in that sentence. A2A 1.0 support is explicitly listed as “coming soon” in the Agent Framework 1.0 release. That means the cross-runtime coordination story — the part that makes A2A different from just calling another API — is not fully baked yet. And A2A’s adoption curve is nowhere near MCP’s. MCP had the advantage of being useful immediately to any tool that wanted to expose capabilities to LLMs. A2A requires bilateral adoption: both the calling agent and the target agent need to speak the protocol. Network effects are harder to bootstrap when you need both sides.

I have watched enough protocol wars to know the pattern. SOAP started with massive enterprise backing and a clean spec. It fragmented when implementations diverged and the spec committee could not keep up with real-world requirements. A2A has the same risk profile: a clean spec backed by major vendors, with the hard part — interoperability across implementations from competing companies — still ahead. If A2A fragments, enterprises that built their multi-agent architectures around cross-runtime A2A coordination will be migrating again in 18 months.

A2A 1.0 full support is “coming soon” — not shipped. Do not architect critical cross-runtime agent workflows around A2A today unless you have a fallback coordination mechanism. MCP for tool discovery is safe to commit to. A2A for agent networking is a bet, not a guarantee.

The comparison that matters here is not against other agent frameworks — LangGraph, CrewAI, or the growing list of options. Those comparisons are about developer experience and orchestration patterns. The comparison that matters is against the protocol layer: are you committing to MCP + A2A as your agent interoperability stack, or are you building custom coordination layers you control? Agent Framework 1.0 makes the first option dramatically easier. It does not make the second option unnecessary.

For teams building multi-agent, long-running session architectures, the middleware pipeline alone may justify adoption. Injecting compliance, safety, and audit logic without prompt surgery is the kind of capability that enterprise security teams will demand — and that most framework-agnostic approaches force you to build yourself.

The Take

I spent Q1 watching enterprise teams burn weeks evaluating Semantic Kernel versus AutoGen, building proof-of-concepts in both, writing comparison documents that nobody reads. That practical end to evaluation paralysis is a meaningful win for teams that need to ship.

But I want to be precise about what Microsoft actually shipped versus what they promised. The SDK is production-ready. The MCP integration is real and immediately useful — 97 million monthly downloads means the ecosystem is there. The A2A story is a roadmap item with “coming soon” next to it. Three different maturity levels in one announcement.

My recommendation: adopt Agent Framework 1.0 for new enterprise agent projects today. Use MCP for tool integration without hesitation. Architect your agent coordination layer so that A2A is a transport option, not a hard dependency. If A2A delivers on the cross-runtime promise, you will be perfectly positioned. If it does not, you will not be stuck.

The SDK is the easy decision. The protocol bet is the one that will age well or badly. Hedge accordingly.