Microsoft Agent Framework ends Microsoft's agent split

Microsoft has finally done the thing large platform companies avoid until the overlap becomes embarrassing: it picked a lane.

For a while, anyone building in Microsoft’s agent orbit had to answer a tedious question before writing a line of serious code. Was the future AutoGen, the research-heavy multi-agent framework out of Microsoft Research? Or was it Semantic Kernel, the enterprise-friendly orchestration layer moving toward the same territory from the other side? Both mattered. Neither felt like the house standard.

Now the company’s answer is clearer. Microsoft Agent Framework is being described across Microsoft Learn, the new GitHub repository, Azure launch material, and two migration guides as the shared successor to both. That is the real story. Not another SDK name. A consolidation.

I have read enough Microsoft platform copy to recognize a carefully worded maybe. This is closer to a yes. The Learn overview calls Agent Framework the “direct successor” to AutoGen and Semantic Kernel, while the Azure launch blog says it converges the two into one open-source SDK and runtime.

That matters because framework launches are cheap. Migration paths are expensive.

Why Microsoft Agent Framework looks like the real successor

The best evidence is not the slogan. It is the paperwork.

Microsoft Learn calls Agent Framework the “direct successor” and “the next generation” of both AutoGen and Semantic Kernel.

The overview lays out the inheritance plainly: AutoGen’s simpler agent abstractions, Semantic Kernel’s state, middleware, telemetry, and type-safety, plus graph-based workflows. The GitHub repo already looks like a real home, not a launch-week tent. It has Python packages, .NET source, workflow samples, observability docs, Labs packages, and a DevUI.

Microsoft is not merely adding one more agent project to a crowded shelf. It is collapsing internal strategy debt into one development surface. That fits the broader trend we have been tracking around agent platforms turning into fuller stacks and multi-agent work moving closer to the repo and runtime itself.

For engineering leads, consolidation matters more than a pretty demo because demos do not answer operational questions. One framework means one place to standardize patterns, one set of abstractions to teach, one backlog of issues to watch, and one repo for complaints, which is sometimes the most honest sign of commitment.

AutoGen to Microsoft Agent Framework migration is unusually explicit

The AutoGen migration guide is not ceremonial. It is a real map.

Microsoft walks through model clients, agent creation, tools, sessions, streaming, multi-agent orchestration, human-in-the-loop patterns, checkpointing, resume flows, and observability. It also does the useful thing many migration guides avoid: it says where the new model is genuinely different.

AutoGen’s higher-level team model and event-driven core give way to a typed, graph-based Workflow system. AutoGen’s FunctionTool wrapper becomes Agent Framework’s @tool approach. AssistantAgent and Agent look familiar at a glance, but they do not behave identically. Agent Framework agents are multi-turn by default, while conversation history lives in AgentSession rather than being carried implicitly in the agent object. The guide also notes that distributed execution is planned rather than fully present today.

That mix of familiarity and difference is why the guide matters. If Microsoft merely wanted to reassure AutoGen users, it could have published a vague transition note. Instead it shipped more than 6,000 words of feature mapping, code comparisons, and workflow translation. The message is simple: here is how to leave without losing the plot.

Semantic Kernel to Microsoft Agent Framework is the bigger consolidation signal

The Semantic Kernel guide may be the more politically important one.

AutoGen was already the research-side playground. Semantic Kernel was the enterprise track, the one more comfortable in a .NET codebase or an architecture deck. So when Microsoft says both should flow into Agent Framework, it is not just merging APIs. It is merging constituencies.

The Semantic Kernel guide leans hard on simplification. It says Agent Framework reduces boilerplate, improves performance, and gives developers a more unified interface across providers. The examples are concrete. Instead of leaning on a Kernel object as the center of everything, Agent Framework pushes more direct agent creation, simpler tool registration, consolidated agent types, and agent-managed sessions. On Python, the move is similar: semantic-kernel gives way to agent-framework, with a core package plus optional provider packages under a single import family.

This is not minor cleanup. It is Microsoft telling existing Semantic Kernel users that the future agent abstraction is no longer “Kernel first, agents attached later.” Agent Framework becomes the umbrella.

That shift matters for enterprise teams because platform decisions are social as much as technical. One framework is easier to explain in architecture reviews. One framework is easier for Microsoft to document, support, and sell into Azure AI Foundry. One framework is easier to justify to cautious teams already reading stories like our piece on the orchestration bottleneck, where the real problem is not lack of agent demos but too many moving parts pretending to be strategy.

Microsoft Agent Framework release candidate status is real, but still transitional

The maturity story is real, but it is not perfectly tidy.

Microsoft’s February Foundry blog says Agent Framework is now in release-candidate status for both .NET and Python, and defines that milestone pretty clearly: the API surface is stable, and all features intended for version 1.0 are complete. That is a meaningful statement. It is much stronger than “early access” theater.

At the same time, the Azure launch blog and the Learn overview still frame the broader offering as public preview. Those claims can coexist, but only if you accept that Microsoft’s product surfaces do not always share one synchronized emotional timeline. Corporate platforms often reach adulthood like teenagers, one limb at a time.

So how mature is Microsoft Agent Framework right now? My read is: real successor, yes. Serious migration target, yes. Fully settled stack, not yet.

The “yes” case is strong: open-source repo, public docs, samples for both languages, migration guides from both predecessors, workflow support, checkpointing, telemetry, standards hooks like MCP and A2A, and prerelease packages already live on PyPI and NuGet. The “not yet” case is also plain. Some provider support remains planned. The AutoGen guide still flags distributed execution as planned. Preview language is still on the public overview.

That is not disqualifying. It just means teams should read “release candidate” as permission to evaluate seriously, not as a magic spell.

Should teams move to Microsoft Agent Framework now?

If you are starting fresh inside Microsoft’s ecosystem, I think the default answer is yes. I would not begin a new AutoGen or Semantic Kernel agent project today unless there is a very specific capability gap, an immovable dependency, or a migration freeze already in place.

If you already have an AutoGen codebase, treat the guide as a working map, not a promise of zero pain. The conceptual bridge is there, but workflow design, session handling, tool semantics, and runtime assumptions shift enough that this is a migration, not a search-and-replace.

If you already run Semantic Kernel, the sharper question is not whether it still works. It probably does. The sharper question is how long you want to build on the superseded abstraction when Microsoft is spending this much energy making Agent Framework the center of the story. That also aligns neatly with Foundry, which is the same buyer-facing logic we saw in Microsoft’s wider effort to package AI stacks for serious institutions.

So I would phase the decision. Put new prototypes on Agent Framework. Put existing production systems on a watch-and-migrate plan. Test the RC packages in staging before posting grand theories about strategic simplification on LinkedIn. The benchmark charts can wait. Your incident review cannot.

The bigger change here is not technical elegance. It is strategic clarity. Microsoft spent years with AutoGen and Semantic Kernel acting like two adjacent answers to the same question. Now it has one answer, and the docs finally say so in plain English. The real test comes next: whether Agent Framework can carry both Microsoft’s research ambitions and its enterprise promises without sliding back into two frameworks wearing one trench coat.

If it can, this will look obvious in hindsight. Those are usually the most consequential platform shifts.