If you’re starting an AI project on .NET in 2026, you’ve probably hit the question: Semantic Kernel or the Microsoft Agent Framework? For a while the honest answer was “it’s complicated.” Since the Agent Framework’s 1.0 GA in April 2026, it’s much simpler than it used to be. This article gives you the straight version — what to use for new work, and what to do if you already have a Semantic Kernel codebase.
For background on the framework itself, see our Microsoft Agent Framework guide.
The short answer
For new projects: use the Microsoft Agent Framework. It’s the designated successor to both Semantic Kernel and AutoGen, it’s 1.0 GA and production-ready, and it’s where Microsoft’s investment now goes. Starting new work on Semantic Kernel in 2026 means building on a foundation you’ll eventually migrate off.
For existing Semantic Kernel apps: you don’t need to panic-migrate. Semantic Kernel still works and is supported — Microsoft has committed to critical bug fixes for the Semantic Kernel agent abstractions for at least a year past the Agent Framework’s GA. Plan a migration deliberately, on your timeline, not as an emergency.
That’s the whole decision for most people. The rest of this article is the “why”, the “how”, and the case nobody mentions: the one where you should use neither.
How they relate
It helps to understand the lineage, because it explains why the recommendation is what it is:
- Semantic Kernel was Microsoft’s enterprise-grade SDK for LLM apps — plugins, planners, memory, strong .NET integration, broad model support.
- AutoGen was Microsoft Research’s project for multi-agent systems, with clean agent abstractions.
- Microsoft Agent Framework is the convergence of both: AutoGen’s ergonomic agent model plus Semantic Kernel’s enterprise plumbing (state, type safety, middleware, telemetry), with new graph-based workflows on top.
So the Agent Framework isn’t a competitor to Semantic Kernel — it’s its next generation. That’s why “use the successor for new work” is the clean answer.
The convergence had a structural consequence worth understanding, because it’s the thing that actually makes migration tractable. Both frameworks sit on Microsoft.Extensions.AI. That library owns the model-facing layer: IChatClient, ChatMessage, AIContent, ChatOptions, AIFunction. It is not going anywhere, it’s shared, and it’s where most of your provider configuration lives. What differs between Semantic Kernel and the Agent Framework is only the agent layer stacked on top — and that layer got substantially smaller in the rewrite.
The option most people skip: no agent framework at all
Before choosing between two agent frameworks, check whether you need an agent.
A large share of production “AI features” are single-turn transformations: classify this ticket, extract these fields from this document, rewrite this description, summarise this thread. There is no plan, no loop, no tool selection, no conversation state. For those, Microsoft.Extensions.AI on its own is the right answer. You get IChatClient, provider portability, structured output with a typed result, function calling if you need it, and OpenTelemetry — with no agent abstraction, no session management, and one fewer prerelease dependency in your build.
This matters because the cost of an agent framework isn’t the API surface, it’s the conceptual overhead it puts on the next engineer. If your feature is “call the model once and deserialise the answer”, wrapping it in an agent buys you nothing and costs everyone who reads the code afterwards.
Reach for the Agent Framework when you actually have agentic behaviour: the model chooses which tools to call and in what order, the loop runs until some condition is met, conversation state persists across turns, or several specialists have to coordinate. That’s a real threshold, and plenty of successful .NET AI features never cross it.
Feature comparison
| Semantic Kernel | Microsoft Agent Framework | |
|---|---|---|
| Status | Mature, supported | 1.0 GA (Apr 2026), actively invested |
| Best for | Existing apps already on it | All new agent work |
| Agent model | Plugins + planners | First-class agents + tools |
| Multi-agent | Limited | Graph-based workflows |
| Standards | Added over time | MCP + A2A built in |
| Trajectory | Stable, superseded | The path forward |
The row that decides it for most teams is multi-agent. Semantic Kernel’s coordination story was built around planners — you described a goal and the model produced a plan, which is elegant in a demo and difficult to operate, because the plan is generated inside a black box and you cannot unit-test a plan that doesn’t exist until runtime. The Agent Framework replaces that with an explicit graph: you declare the nodes and edges, and validation happens when you build the workflow rather than when a customer hits it. If you have ever debugged a planner that decided to skip a step, that difference is worth the migration on its own.
Where the Agent Framework will still frustrate you
An honest recommendation includes the sharp edges, and there are two.
Prerelease packages. Several of the Microsoft.Agents.AI.* packages — workflows and the hosted-provider integrations among them — are still installed with --prerelease. “1.0 GA” describes the core agent abstractions, not every satellite package. In practice this means pinning exact versions, reading release notes before you upgrade, and expecting the occasional signature change in the areas that are moving fastest. If your organisation has a policy against prerelease NuGet packages in production, find that out before you commit to the workflows layer, not after.
Documentation and answers lag. Because the framework is new and the naming changed, a large fraction of what you’ll find in search results and in model training data describes Semantic Kernel, earlier Agent Framework previews, or AutoGen. Code that looks plausible and doesn’t compile is a normal Tuesday. Budget for reading the official docs and the samples repository rather than trusting the first snippet you find — including snippets from an assistant, which will confidently produce Kernel-based code long after Kernel stopped existing.
Neither of these is a reason to choose Semantic Kernel instead. They are reasons to plan the adoption rather than discover it.
When Semantic Kernel is still fine
Be pragmatic. Stay on Semantic Kernel a while longer if:
- You have a working production app on it — “it works and is supported” is a valid reason not to rewrite this quarter.
- You use a narrow slice (say, just prompt templates and a plugin or two) that isn’t costing you anything.
- You have no immediate need for the Agent Framework’s new capabilities (graph workflows, native MCP/A2A).
- You are shipping something imminently. Changing framework in the run-up to a deadline converts a schedule risk into a quality risk, and the quality of an agent is the harder of the two to recover.
The trigger to migrate isn’t the calendar — it’s needing something the new framework does better, or reaching a natural refactor point.
There is a real cost to waiting indefinitely, though, and it isn’t technical. It’s that every new hire, every sample, every doc page and every conference talk will be about the Agent Framework, and your codebase will be the one where none of that applies. That cost compounds quietly. It’s a reason to have a plan, not a reason to start on Monday.
How to migrate (when you’re ready)
Microsoft ships migration guidance precisely because a rewrite is the wrong approach. The sane path:
- Start with new features. Build the next agent feature on the Agent Framework rather than porting old ones first. You learn the framework on green-field code, not under migration pressure.
- Migrate incrementally. Both build on
Microsoft.Extensions.AI’sIChatClient, so your model configuration, message types and content types carry over unchanged. Move one component at a time behind stable interfaces. - Follow the official migration guide, not folk wisdom — concept mappings (plugins → tools, threads → sessions, planners → workflows) are documented and save you guesswork.
- Lean on your tests. If you have an eval set, it’s your safety net: capture a baseline before you touch anything, migrate a component, re-run the evals, confirm quality held. The compiler will not tell you that your agent got worse.
The mistake to avoid is porting your architecture along with your code. A planner translated one-to-one into a graph workflow gives you the worst of both: the rigidity of an explicit graph with none of the testability, because the graph still has one enormous node that decides everything. When you migrate a planner, that’s the moment to ask which decisions genuinely need a model and which were always just an if. Usually more of them than you expect.
The other mistake is treating the migration as the risky part. It isn’t. The parts of an agent that break in production are the prompt design, the tool descriptions, the permission model and the handling of untrusted content — and none of those are framework concerns. Migrating changes which types you hold. It does not change whether your agent is safe or correct, and it will not fix a system that was already fragile.
A decision in one paragraph
New project with agentic behaviour: Agent Framework. New project that just calls a model once per request: Microsoft.Extensions.AI alone, and skip the agent layer entirely. Existing Semantic Kernel app that works and isn’t growing: leave it, and revisit when something forces the issue. Existing Semantic Kernel app you’re actively building on: start the next feature on the Agent Framework and migrate the rest a leaf at a time, with evals between steps. Deadline in three weeks: whatever you already know.
Takeaway
In 2026 the decision is refreshingly clear: build new .NET agent work on the Microsoft Agent Framework — it’s the GA’d successor to both Semantic Kernel and AutoGen and where the ecosystem is going. If you’re already on Semantic Kernel, it still works; migrate deliberately, starting with new features and moving incrementally, rather than treating it as an emergency.
And keep the third option in view. A framework is worth its overhead when the model is genuinely deciding what to do next. When it isn’t, Microsoft.Extensions.AI and a typed response will serve you better than either. The framework fragmentation that made this question hard is over — which is good news for everyone building on .NET.
Next: the line-by-line C# migration walkthrough when you are ready to start moving code.
Have a correction or a topic you want covered? Email mani.bc72@gmail.com.