Search for a command to run...
You bet a year of roadmap on Semantic Kernel. Then Microsoft renamed the bet. Here is what actually changed, what did not, and why the architects who shrugged are the ones who read the contract instead of the brand.
No comments yet. Be the first to comment.
The architectural patterns of Series 1-3, rebuilt on the .NET runtime. Semantic Kernel, Microsoft.Extensions.AI, hosted agents, streaming.
Your senior dev has spent three days hand rolling wrapper classes for logging, caching, and provider switching around the OpenAI SDK. Microsoft already shipped that, called it boring, and put it in the box with the rest of .NET. Surprise.
🗓️ Last updated: August 2026 The architect inherits a brownfield .NET 10 service that classifies incoming customer-support emails into six ticket categories, extracts the order number if there is on
Your senior dev has spent three days hand rolling wrapper classes for logging, caching, and provider switching around the OpenAI SDK. Microsoft already shipped that, called it boring, and put it in the box with the rest of .NET. Surprise.
A recursive agent spent the weekend asking itself the same question, failing the same check, and billing you for both. No error fired, because no metric you watched had the word stop in it. This article is about putting it there.
The dashboards are healthy, the error rate is zero, nothing shipped this week, and the model just told a customer something expensive and wrong. There is no commit to revert. Welcome to the incident that classical on call was never designed for.
🗓️ Last updated: July 2026
Picture the .NET architect who, sometime in 2025, did everything right. They read the docs, they avoided the hype, they picked Semantic Kernel because it was the Microsoft blessed option with a real team behind it, and they shipped an agent on top of it. Kernel, plugins, connectors, a planner doing the orchestration. Clean. Defensible in a design review.
Then April 2026 arrived, and Microsoft announced that the thing they standardized on was now, effectively, the previous generation. Semantic Kernel and AutoGen had been folded into a single unified SDK called the Microsoft Agent Framework, which reached 1.0 general availability in April 2026. The product lead's own framing was that you should think of the Agent Framework as Semantic Kernel v2.0, built by the same team. Comforting, in the way that "we're not breaking up, we're just seeing other abstractions" is comforting.
This is the first article in AI for the .NET Architect. Before we touch a single line of Microsoft.Extensions.AI or write one IHostedService, we have to deal with the fact that the foundational framework most .NET LLM code was written against just got consolidated out from under it. The good news, and it is genuinely good news, is that the consolidation is a much smaller earthquake than the renaming makes it look. Most of what you built was never really the framework's anyway.
If you started a .NET agent project any time in the last two years, you inherited a confusing inheritance. There was Semantic Kernel, the enterprise leaning SDK with the Kernel object, plugins, and planners. There was AutoGen, the research leaning multi agent framework that came out of Microsoft Research and was very good at agents talking to each other. And underneath both, quietly, there was Microsoft.Extensions.AI, a small set of abstractions that neither replaced nor competed with the other two but somehow sat below them.
Three things, overlapping, from the same company, with the same logo, pointed at roughly the same problem. Every architecture review that touched AI spent its first twenty minutes just establishing which of the three the team was actually using and why. That was not a great use of twenty minutes.
The April 2026 consolidation is, more than anything, Microsoft admitting that the three framework situation was untenable and collapsing it into one. Semantic Kernel and AutoGen become the Microsoft Agent Framework. Microsoft.Extensions.AI stays exactly where it was, as the substrate. If you only remember one sentence from this article, make it that one: the consolidation happened one layer up from the part you should have been building on.
It is worth being honest about what Semantic Kernel did and did not do, because the honest version is what tells you how much of your code is at risk.
Semantic Kernel gave you four things that mattered:
KernelFunction, you had built a tool the model could call.Here is the uncomfortable part. The planners, the most distinctive Semantic Kernel feature, the thing that made it feel like more than an SDK wrapper, were already deprecated well before the consolidation. The Sequential Planner and the Stepwise Planner were superseded by function calling planning, which is a fancy way of saying the model itself decides which tools to call, in which order, using the native tool calling the model providers built into their APIs. The framework stopped needing to plan because the models learned to plan.
So if you built your architecture on the Sequential Planner, you were already standing on a deprecated abstraction before April 2026 said a word. The consolidation did not break your planner. Your planner was scheduled for demolition the day the models got good at tool calling.
Strip away the launch blog enthusiasm and the Agent Framework is a focused thing: a unified SDK for building agents, distributed under the Microsoft.Agents.AI package family, that takes the agent and multi agent ideas from Semantic Kernel and AutoGen and rebuilds them on a common foundation.
The core abstraction is AIAgent. Where Semantic Kernel made you assemble a Kernel and hang services and plugins off it, the Agent Framework gives you an agent as a first class concept, with ChatClientAgent as the canonical concrete implementation you will actually instantiate. An agent has instructions, tools, and the ability to carry state across turns, and it is built directly on top of the IChatClient abstraction from Microsoft.Extensions.AI.
That last detail is the whole game, and it is why this consolidation is survivable. The Agent Framework is not a parallel universe with its own model client and its own plumbing. It sits on the exact same IChatClient substrate that a plain Microsoft.Extensions.AI application uses, the same one Article 2 of this series is entirely about. The agent is a layer of orchestration on top of a model client you already understand, not a replacement for it.
Multi agent coordination, the AutoGen contribution, comes along too: the framework supports agents that hand work to other agents, which is the pattern AutoGen pioneered and Semantic Kernel never did cleanly. If you were running AutoGen for the agent to agent conversation and Semantic Kernel for the enterprise plumbing, the consolidation is unambiguously good for you. You get one SDK instead of two that pretended not to know each other.
This is the section to bring to your own migration review, because it sorts your codebase into three honest piles.
What you keep. The Microsoft.Extensions.AI substrate survives untouched. The function calling pattern survives, because it was always the model providers' API, not a Semantic Kernel invention. Your OpenTelemetry instrumentation survives, because tracing a model call is a cross cutting concern that never belonged to the framework in the first place. Your prompts survive. Your evaluation suite survives. Your cost controls survive. Notice how much of that list is the stuff Series 3 spent six articles on.
What you replace. The Kernel object as your composition root. The planner based orchestration, which was deprecated already and is now formally superseded by agents and function calling planning. The Semantic Kernel specific agent types, which give way to AIAgent and ChatClientAgent. The session or thread state handling for multi turn conversations, which the Agent Framework models with its own abstraction rather than Semantic Kernel's.
What was never the framework's job. Your retrieval pipeline. Your evaluation harness. Your prompt versioning discipline. Your observability spans. Your per tenant cost budgets. Your incident runbooks. None of these were ever Semantic Kernel features, which means none of them are Microsoft Agent Framework migrations. They are your architecture, and architecture is the thing that survives every consolidation, including the next one, which Microsoft will absolutely ship eventually, because they always do.
If your migration spreadsheet has a hundred rows, the honest version probably has fifteen rows in the "replace" column and eighty five rows in the "this was never the framework" column. The panic is proportional to how much architecture you accidentally let leak into framework specific types.
Two situations, two answers.
You are starting a greenfield .NET agent today. Start on the Microsoft Agent Framework. It is GA, it is the supported path, the new features land here, and there is no reason to begin a new project on the framework Microsoft just put into maintenance. This is the easy case, and it is the one most articles stop at.
You are maintaining a Semantic Kernel codebase that works. Do not rip it out this sprint. Semantic Kernel is not deleted. It moves to what amounts to maintenance mode: critical bug fixes and security patches keep coming, and Microsoft committed to supporting Semantic Kernel for at least a year after the Agent Framework reached GA. New features go to the Agent Framework now, but your running code does not stop running because a blog post was published. Microsoft even shipped a migration guide for the day you decide to make the move.
The mistake is treating "Semantic Kernel is in maintenance mode" as "Semantic Kernel is on fire, evacuate." It is not on fire. It is a supported v1.x with a v2.0 available, which is the most normal situation in the history of software libraries. You migrate when the cost of staying, the missing new features, exceeds the cost of moving. Not before, and not in a panic because a brand changed.
These are the ways a .NET team gets the consolidation wrong, ordered roughly by how often I have watched it happen.
IChatClient be the widest thing that leaks inward.Microsoft.Extensions.AI is the layer doing the actual model communication. Teams that miss this rebuild logging, caching, and telemetry inside their agent code instead of composing it in the substrate pipeline, which is the subject of the next article.Microsoft.Agents.AI is just Semantic Kernel with a new logo. The composition root, the orchestration model, and the agent abstractions did genuinely change. It is a reset of the load bearing types, not a find and replace on the namespace.The first and last failure modes are mirror images. One team panics and rewrites everything; the other team shrugs and rewrites nothing. Both are wrong for the same reason: neither one sorted their code into the three piles first.
Bring this to the migration review.
Microsoft.Extensions.AI and its IChatClient sit in your stack, independent of the agent framework on top?If you can answer most of these cleanly, the consolidation is a Tuesday. If you cannot, the consolidation is not your problem. Your problem is that you let a framework become your architecture, and this was always going to hurt eventually.
Frameworks are rented, not owned. Semantic Kernel was a good rental. The Microsoft Agent Framework is a better one. There will be a third, and a fourth, because this field is eighteen months old wearing a suit, and the vendors are still figuring out the abstractions in public.
The teams that sailed through April 2026 are the teams that always treated the framework as one replaceable component sitting on a substrate they understood, surrounded by an architecture they owned. The teams that did not sleep that month are the teams that let Kernel become a load bearing type in their domain model and then acted surprised when the load bearing type got consolidated.
Everything in this series, the unified client layer, the structured outputs, the hosting model, the streaming transport, the reference architecture, is built to be the part you own, on top of whatever framework Microsoft is shipping this quarter. Get the layering right once, and the next consolidation is a press release you read with your coffee, not an incident you staff at midnight.
The framework is the binding on the book. The architecture is the text. Bindings wear out and get replaced. You keep the text.