Semantic Kernel moves to maintenance mode as .NET teams migrate to Microsoft Agent Framework

What happened

Microsoft has made Microsoft Agent Framework (MAF) the primary way to build AI agents on .NET, and Semantic Kernel, the toolkit that held that role for years, is now in maintenance mode. That is the picture laid out in a migration walkthrough published on dev.to, which reports that MAF 1.0 shipped in April 2026, combining Semantic Kernel's enterprise features with orchestration patterns drawn from AutoGen. As of October 2026 the Microsoft.Agents.AI package stands at version 1.26, while Semantic Kernel receives only critical fixes.

According to the article, every new capability Microsoft adds — graph workflows, native MCP and A2A support, durable execution, improved middleware — now lands exclusively in Agent Framework. Teams with working Semantic Kernel agents are not being forced to rewrite immediately, the author stresses, but the longer migration is deferred, the wider the capability gap grows.

The architectural shift

The biggest difference is structural. Semantic Kernel revolved around a single Kernel object that owned the chat service, plugins, filters and memory. MAF dissolves that centerpiece and spreads the responsibilities across smaller abstractions:

• Model access moves to an IChatClient from the Microsoft.Extensions.AI packages.
• Agent behaviour lives on AIAgent, most often the ChatClientAgent implementation.
• Callable capabilities become plain AIFunctions built with AIFunctionFactory.Create.
• Conversation continuity is handled by an AgentSession that the agent itself creates.
• Cross-cutting concerns shift to middleware.

There is no mandatory Kernel. After constructing a chat client for your provider, you convert it into an agent with the AsAIAgent extension method.

The code before and after

The dev.to walkthrough contrasts a typical Semantic Kernel weather agent with its MAF equivalent. On the old side, you build a Kernel with AddAzureOpenAIChatCompletion, register a plugin class decorated with KernelFunction attributes, attach it to a ChatCompletionAgent, and iterate over an IAsyncEnumerable returned by InvokeAsync, supplying a caller-created thread.

On the MAF side, several of those steps disappear. You construct an AzureOpenAIClient with an Azure credential, wrap the deployment's chat client via AsIChatClient, and pass name, instructions and tools to AsAIAgent in a single call. Tools no longer need a dedicated plugin class or attribute — a static or instance method wrapped in AIFunctionFactory.Create is enough. The agent owns session creation through CreateSessionAsync, the non-streaming RunAsync call returns a single AgentResponse, and streaming uses RunStreamingAsync to yield AgentResponseUpdate objects. Token limits and other inference settings move into ChatClientAgentRunOptions.

Provider swaps stay local, the author notes: switching to an OllamaSharp client for a local model such as llama3.2 changes only client construction, while the rest of the agent API remains identical.

Wiring it into ASP.NET Core

For hosted applications the article recommends registering the IChatClient as a singleton and the agent as a keyed singleton when its configuration is static. Controllers then receive the agent through keyed-service injection and call CreateSessionAsync and RunAsync per request. When tools depend on scoped services, such as a DbContext, or when you need per-request state, the agent should be registered as scoped instead. Sessions should be created once per conversation and reused across turns; cleanup for hosted-provider conversations, where supported, still goes through the underlying client.

Why it matters

For .NET teams, Semantic Kernel is now effectively a legacy path: security and stability fixes only, and none of the features Microsoft is actively shipping for agents. The practical consequence is that anyone building or maintaining agent workloads on .NET needs a migration plan, and the incremental approach the article describes — adding the Microsoft.Agents.AI and Microsoft.Extensions.AI packages alongside existing Semantic Kernel code — is designed to make that transition gradual rather than a rewrite. The move to IChatClient-based abstractions also reduces provider lock-in, since Azure OpenAI and local runtimes sit behind the same interface. One caveat: the version numbers and timelines here come from a single community article on dev.to, so teams should confirm current package versions against Microsoft's official documentation before committing to a migration schedule.