Microsoft Agent Framework 1.0 Ends the Semantic Kernel Era

Microsoft did something in April that platform vendors almost never do voluntarily: it killed two of its own frameworks while they were still popular. Microsoft Agent Framework hit 1.0 general availability for .NET and Python in early April 2026, and with it, Semantic Kernel and AutoGen went into maintenance mode — security patches and bug fixes, no new features. As of June, AutoGen's repo carries an official notice that it's community-managed going forward. The three-way standoff that's paralyzed Microsoft-shop AI teams since 2023 is over, by executive decision.

That's worth taking seriously, because the fragmentation was real and it was Microsoft's own fault.

Three SDKs, one company

Semantic Kernel shipped in early 2023 as the "enterprise" answer to LangChain: dependency injection, plugins, telemetry, first-class .NET. AutoGen came out of Microsoft Research the same year with the opposite temperament — a Python-native playground for multi-agent conversation patterns that became the default academic citation for agent orchestration. Then Azure AI Foundry (now Microsoft Foundry) layered a managed agent service on top, with its own SDK surface.

Anyone who sat in an architecture review in 2024 or 2025 knows what happened next: teams burned weeks debating which horse to back, knowing full well that at least one of them would lose. Microsoft's own engineers were fielding the "SK or AutoGen?" question at every conference. The honest answer — "they'll converge eventually" — was public from early 2025, but "eventually" is not a deployment plan.

Agent Framework is that convergence, built by the same teams. The design split is clean: AutoGen contributed the simple agent abstractions, Semantic Kernel contributed the enterprise plumbing — session-based state, type safety, middleware, observability — and the genuinely new piece is graph-based workflows with type-safe routing, checkpointing, and human-in-the-loop pauses for multi-agent orchestration. Tool integration runs through the Model Context Protocol, and cross-runtime interop through A2A, which means Microsoft bet on the two protocols the rest of the industry had already settled on rather than inventing its own. Provider connectors ship for Foundry, Azure OpenAI, OpenAI, Anthropic, Bedrock, Gemini, and Ollama. Getting started is one line per ecosystem:

pip install agent-framework          # Python
dotnet add package Microsoft.Agents.AI   # .NET

A Go SDK exists but is still in public preview with feature gaps — if you're a Go shop, this consolidation hasn't fully reached you yet.

The migration math

The practical question isn't whether Agent Framework is good. It's whether you move, and when. The calculus differs sharply by where you're standing.

New projects are easy: start on Agent Framework. Betting a greenfield build on a maintenance-mode library in mid-2026 is malpractice, and the 1.0 release carries stable-API and long-term-support commitments.

AutoGen users should move soonest. "Community managed" is a softer phrase than "abandoned," but for a research-lineage project whose core team has moved to the successor, the trajectory is the same. The migration is also conceptually cleaner than it sounds — AutoGen's group-chat patterns map onto Agent Framework's workflow graphs, and you gain checkpointing and durable state that AutoGen never really had. Microsoft publishes a migration guide for the mechanical parts.

Semantic Kernel in production is the interesting case, and the one where I'd counsel patience. Maintenance mode with security patches is a perfectly stable place to run an existing workload for a year or more. The real cost of staying is opportunity cost: every new capability — the workflow engine, the opinionated "Harness" agent for long multi-step tasks, new provider features — lands only in Agent Framework. The sensible pattern is the one experienced teams already use for framework transitions: new agents on the new framework, existing agents migrated opportunistically when you're touching them anyway. Teams that kept their business logic decoupled from SK's plugin abstractions will find the move mostly mechanical; teams that let kernel objects leak through every layer are about to pay for that.

The Foundry gravity well

Here's the caveat that should temper the enthusiasm. Agent Framework is genuinely open source and genuinely multi-provider — the Anthropic, Bedrock, Gemini, and Ollama connectors are first-party, not community afterthoughts. But read the docs and the pull is unmistakable: the quickstarts default to Foundry endpoints, the flagship .NET package is Microsoft.Agents.AI.Foundry, and the managed-deployment story runs through Azure. This is the standard Microsoft platform play — open framework, gravitational platform — and enterprises should adopt it with eyes open.

The mitigating factor, and it's a real one, is the protocol layer. Because tools speak MCP and agent-to-agent interop speaks A2A, the switching cost out of Agent Framework is structurally lower than it was for past Microsoft consolidations. Your MCP servers work with LangGraph, the OpenAI Agents SDK, or Claude-based stacks unchanged. That's a meaningful difference from the WCF era, when the abstractions were the lock-in.

The framework was never the hard part

My verdict: this consolidation is genuine, overdue, and executed better than Microsoft's history suggested it would be — public preview in October 2025 to stable 1.0 in six months, with real migration guides. Among big-vendor agent stacks, Microsoft now has the most coherent story for enterprises that were already on Azure, and a credible one even for those that aren't, precisely because of the MCP/A2A bets.

But don't mistake a settled SDK question for a settled architecture. The decisions that actually sink agent projects — does this task need an agent at all or a deterministic pipeline, what context reaches the model, what happens on partial failure, and whose credentials does the agent act under — are untouched by any framework, and Agent Framework's own docs admit as much ("if you can write a function to handle the task, do that instead"). Teams that spent 2025 agonizing over SK-versus-AutoGen just had that excuse removed. What's left is the hard part, and it always was.