If you have been building agents on Semantic Kernel or AutoGen, you have probably already heard about Microsoft Agent Framework. Microsoft announced it as the successor to both frameworks, and if you have shipped production code on Semantic Kernel, that announcement raises a fair number of practical questions. How long will Semantic Kernel actually be supported? Should you start new work on the old framework or the new one? Is C# treated as a second class citizen compared to Python? This article works through the official guidance from the Microsoft Agent Framework team and adds the practical considerations you need when making this call for a real project.
What exactly is Microsoft Agent Framework
Microsoft Agent Framework is positioned as a unified, enterprise grade platform for building, deploying, and managing AI agents. It is built by the same team that built Semantic Kernel and AutoGen, and it folds in the lessons learned from running both of those frameworks in production across a large number of customers. Instead of maintaining two separate agent stacks, Microsoft is consolidating around one framework with deep ties into Azure and the wider Microsoft ecosystem, while still supporting models and tools from outside that ecosystem.
In practice, think of Microsoft Agent Framework as Semantic Kernel version 2.0. The mental model is the same one you would apply to any library moving from a 1.x line to a 2.x line: the new major version consolidates APIs, drops some accumulated cruft, and becomes the primary destination for new investment, while the old version keeps running for people who already depend on it.
How long will Semantic Kernel 1.x actually be supported
This is the question that matters most if you have Semantic Kernel in production today. Microsoft has committed to supporting Semantic Kernel 1.x for the foreseeable future, which in concrete terms means critical bug fixes and security patches will continue, and a handful of existing Semantic Kernel features already on the roadmap will still be taken to general availability. What will not continue at the same pace is net new feature work. The bulk of new capability, from new agent patterns to new orchestration primitives, is going into Microsoft Agent Framework.
Microsoft has also attached a concrete floor to this commitment: Semantic Kernel support continues for at least one year after Microsoft Agent Framework exits preview and reaches general availability. Since Microsoft Agent Framework is still in preview as of this writing, that one year clock has not even started. If you are running Semantic Kernel in production, you have a realistic multi year runway before you are forced to move, not just a few months of grace period.
Is support at parity between Python and C#
Microsoft’s stated intent is to support Python and C#/.NET at parity once a feature reaches general availability. The catch is in the preview period. While a feature is still being built out, it may land in one language before the other, depending on which team happens to be driving that particular piece of work. If you are a .NET shop evaluating Microsoft Agent Framework today, check the current state of the specific capability you need rather than assuming both SDKs are on the same page. Preview software moves unevenly across language bindings almost everywhere, and this is not unique to Microsoft’s tooling; it is a normal cost of adopting anything before it hits general availability.
Should you start a new project on Semantic Kernel or Microsoft Agent Framework
The official guidance breaks into three cases, and they map cleanly onto how most architects already think about adopting preview technology. If you already have a Semantic Kernel project running, or you need to ship something on a tight deadline, staying on Semantic Kernel is a perfectly reasonable choice. It is stable, it is documented, and your team already knows its quirks.
If you are starting fresh and your timeline allows you to wait for Microsoft Agent Framework to reach general availability before you ship, starting there is the recommended path, since you avoid a migration later. And if you are starting fresh but need a capability that only exists in Microsoft Agent Framework today, it is fine to build on the preview version now, with the understanding that you are accepting some preview level risk: breaking changes between preview builds, less mature tooling, and documentation that may lag the code.
One thing this FAQ does not spell out, and that is worth calling out from experience with earlier Semantic Kernel preview cycles, is that breaking changes between preview releases were frequent and sometimes not well flagged in release notes. If you commit to Microsoft Agent Framework while it is still in preview, pin your package versions explicitly and budget time in every sprint to review changelogs before you upgrade, rather than assuming a minor version bump is safe.
What migrating from Semantic Kernel actually involves
Microsoft has published dedicated migration guides for both .NET and Python, and the existence of separate guides per language is itself a signal that the migration is not a drop in namespace rename. Expect to revisit how you construct kernels, how plugins and functions are registered, and how planners and orchestration are wired up, since Microsoft Agent Framework reworks these concepts rather than just renaming them. Teams that used heavily customized planners or wrote extensive plugin metadata in Semantic Kernel should expect the migration to take real design time, not just a mechanical find and replace across the codebase.
A sensible way to plan this is to treat the migration as its own project with its own testing pass, rather than folding it into an unrelated feature release. Agent behavior is notoriously hard to unit test with the same confidence you would apply to deterministic code, so any migration should be paired with your existing evaluation harness or a lightweight one, so you can compare agent output before and after the move and catch regressions in tool selection or response quality.
Why the name changed from Semantic Kernel and AutoGen
Microsoft’s own answer to this is refreshingly candid: the team considered calling the merged framework Semantogen, and the branding team vetoed it. Naming aside, the practical reason for consolidation is straightforward. Maintaining two separate agent frameworks, Semantic Kernel for orchestration heavy scenarios and AutoGen for multi agent conversation patterns, meant customers had to pick a side and then live with the limitations of whichever framework they picked. Microsoft Agent Framework exists to remove that fork in the road.
Practical takeaway for teams deciding today
If your Semantic Kernel deployment is stable and doing its job, there is no urgency to move. The one year post-GA support floor gives you a wide window, and jumping onto a preview framework mid production cycle usually costs more in stability than it saves in future proofing. If you are starting a greenfield agent project and can afford to wait a few months, Microsoft Agent Framework is the framework Microsoft is actively investing in, and starting there avoids a rewrite down the line. Either way, keep an eye on the migration guides and the GitHub discussions board, since preview era guidance changes quickly and the framework’s shape is still settling.
Leave a Reply