Skip to main content

Migrate Semantic Kernel Agents → Microsoft Agent Framework (.NET)

Verified Apr 2026 Advanced Original .NET 10 Microsoft.Agents.Core 1.x Microsoft.SemanticKernel 1.71.0
By Rajesh Mishra · Mar 8, 2026 · 14 min read
In 30 Seconds

Migration from Semantic Kernel Agents to Microsoft Agent Framework preserves plugins, DI patterns, and kernel configuration. The primary changes are in agent lifecycle management (explicit threads), orchestration patterns (sequential, concurrent, handoff, group chat), and production features (checkpointing, human-in-the-loop). Recommendation: start new agentic projects on Agent Framework, and migrate existing production SK agents in staged increments with parallel validation.

Why This Migration Matters

Microsoft Agent Framework is the successor to Semantic Kernel Agents and AutoGen. The RC landed February 19, 2026, with GA targeted for Q1 2026. AutoGen is entering maintenance mode. The Semantic Kernel agent abstractions will continue to work, but new agentic capabilities — multi-agent orchestration, MCP integration, checkpointing, human-in-the-loop — are landing exclusively in Agent Framework.

If you’re building or maintaining .NET agents, you need to understand the migration path.

This guide covers exactly what changes, what stays the same, and the specific code transformations you’ll make. No speculation, no handwaving — side-by-side code comparisons with real patterns from production systems.

What Transfers Directly

The good news first. Agent Framework is built on top of Semantic Kernel, so a significant portion of your code doesn’t change at all:

Plugins — Zero Changes

Every plugin you’ve written with [KernelFunction] works in Agent Framework without any modification:

// This code works in both SK and Agent Framework — unchanged
public class WeatherPlugin
{
    [KernelFunction("get_forecast")]
    [Description("Get weather forecast for a city")]
    public async Task<string> GetForecastAsync(string city)
    {
        var forecast = await _weatherService.GetForecastAsync(city);
        return $"Forecast for {city}: {forecast.Summary}, {forecast.Temperature}°F";
    }
}

Your plugins are the unit of reusability in the Microsoft AI stack. They work in SK, they work in Agent Framework, and they’ll work in whatever comes next. This was an intentional design decision.

Kernel Configuration — Zero Changes

Your Kernel setup, service registration, and DI patterns are identical:

// Same in both SK and Agent Framework
var builder = Kernel.CreateBuilder();
builder.AddAzureOpenAIChatCompletion(
    deploymentName: "chat-deployment",
    endpoint: config["AzureOpenAI:Endpoint"]!,
    credentials: new DefaultAzureCredential());
builder.Plugins.AddFromType<WeatherPlugin>();
builder.Plugins.AddFromType<SearchPlugin>();

var kernel = builder.Build();

DI Registration — Zero Changes

If you’re using ASP.NET Core DI to register your kernel and plugins, that code stays exactly the same.

What Changes

The migration surface is concentrated in three areas: agent creation, conversation management, and multi-agent orchestration.

Agent Creation

Semantic Kernel:

var agent = new ChatCompletionAgent
{
    Name = "ResearchAssistant",
    Instructions = "You are a research assistant...",
    Kernel = kernel
};

Agent Framework:

var agent = AgentBuilder.CreateChatCompletionAgent()
    .WithName("ResearchAssistant")
    .WithInstructions("You are a research assistant...")
    .WithKernel(kernel)
    .Build();

The builder pattern gives Agent Framework more flexibility for future configuration options without breaking the API. The concepts are identical — the syntax is more explicit.

Conversation Management

This is the biggest conceptual change. SK agents use AgentGroupChat for conversation state. Agent Framework introduces explicit threads that you create, manage, and can persist:

Semantic Kernel:

var chat = new AgentGroupChat(agent);

// Add a message
chat.AddChatMessage(new ChatMessageContent(AuthorRole.User, "Research quantum computing"));

// Get responses
await foreach (var response in chat.InvokeAsync())
{
    Console.WriteLine(response.Content);
}

Agent Framework:

// Create an explicit thread
var thread = await agent.CreateThreadAsync();

// Add a message
await thread.AddMessageAsync("Research quantum computing");

// Get responses
await foreach (var response in thread.InvokeAsync())
{
    Console.WriteLine(response.Content);
}

// Thread persists — can be resumed later
var threadId = thread.Id;

The key difference: threads have identity and lifecycle. You can persist them, resume them after a server restart, and share them between agents. This is what enables checkpointing for long-running tasks.

Multi-Agent Orchestration

If you’ve built custom multi-agent coordination with SK’s AgentGroupChat, Agent Framework provides four built-in patterns that replace your custom logic.

Semantic Kernel — Custom Orchestration:

var groupChat = new AgentGroupChat(researchAgent, analysisAgent, writerAgent)
{
    ExecutionSettings = new()
    {
        TerminationStrategy = new ApprovalTerminationStrategy
        {
            Agents = [writerAgent],
            MaximumIterations = 10
        },
        SelectionStrategy = new SequentialSelectionStrategy()
    }
};

Agent Framework — Sequential Pipeline:

var pipeline = new SequentialOrchestrator(
    new[] { researchAgent, analysisAgent, writerAgent });

var result = await pipeline.InvokeAsync("Research quantum computing trends");

Agent Framework — Handoff Pattern:

var handoff = new HandoffOrchestrator(
    triageAgent: triageAgent,
    specialists: new Dictionary<string, Agent>
    {
        ["research"] = researchAgent,
        ["analysis"] = analysisAgent,
        ["writing"] = writerAgent
    });

The built-in orchestrators handle termination conditions, agent selection, and result aggregation. You configure behavior instead of implementing it.

Migration Steps

Here’s the systematic approach for migrating an existing SK agent application:

Step 1: Audit Your Codebase

Identify all agent-related code. Look for:

  • ChatCompletionAgent instantiation
  • OpenAIAssistantAgent instantiation
  • AgentGroupChat usage
  • Custom SelectionStrategy or TerminationStrategy implementations
  • Any direct manipulation of agent chat history

Plugins, kernel configuration, and DI registration don’t need to change.

Step 2: Install Agent Framework

Add the Agent Framework package alongside your existing SK packages:

<PackageReference Include="Microsoft.Agents.Core" Version="1.0.0-rc.*" />
<!-- Your existing SK packages stay -->
<PackageReference Include="Microsoft.SemanticKernel" Version="1.71.0" />

Both packages coexist — they share the same Kernel instance.

Step 3: Migrate Agent Creation

Replace new ChatCompletionAgent { ... } with the builder pattern:

// Before
var agent = new ChatCompletionAgent
{
    Name = "Assistant",
    Instructions = instructions,
    Kernel = kernel
};

// After
var agent = AgentBuilder.CreateChatCompletionAgent()
    .WithName("Assistant")
    .WithInstructions(instructions)
    .WithKernel(kernel)
    .Build();

Step 4: Migrate Conversation Management

Replace AgentGroupChat with explicit threads:

// Before
var chat = new AgentGroupChat(agent);
chat.AddChatMessage(new ChatMessageContent(AuthorRole.User, input));
await foreach (var msg in chat.InvokeAsync()) { ... }

// After
var thread = await agent.CreateThreadAsync();
await thread.AddMessageAsync(input);
await foreach (var msg in thread.InvokeAsync()) { ... }

Step 5: Replace Custom Orchestration

Map your existing multi-agent coordination to Agent Framework patterns:

SK PatternAgent Framework Equivalent
Sequential SelectionStrategySequentialOrchestrator
Custom round-robinConcurrentOrchestrator
Agent-based routingHandoffOrchestrator
AgentGroupChat with multiple agentsGroupChatOrchestrator

Step 6: Add Production Features

Once migration is complete, enable the features that motivated the move:

// Checkpointing for long-running tasks
var thread = await agent.CreateThreadAsync(new ThreadOptions
{
    EnableCheckpointing = true,
    CheckpointStore = new CosmosCheckpointStore(cosmosClient)
});

// Human-in-the-loop approval
agent.OnToolCallRequested += async (sender, args) =>
{
    if (args.ToolName == "send_email")
    {
        args.RequiresApproval = true;
        // Pauses execution until approved
    }
};

When to Migrate

ScenarioRecommendation
New project with agentsStart on Agent Framework RC
Existing SK agents, productionPlan for post-GA migration
SK for RAG/chat/embeddings onlyStay on SK — no migration needed
AutoGen agentsBegin planning migration now
Evaluating bothPrototype with Agent Framework RC

Next Steps

⚠ Production Considerations

  • The thread model in Agent Framework requires explicit state management. If you relied on AgentGroupChat managing conversation state implicitly, your migration needs to handle thread persistence.
  • Agent Framework's checkpointing uses serialization — ensure all agent state and tool results are serializable before enabling it.

Enjoying this article?

Get weekly .NET + AI insights delivered to your inbox. No spam.

Subscribe Free →

🧠 Architect’s Note

Migration is not all-or-nothing. You can run SK-based features and Agent Framework agents in the same application. Migrate agentic code first, leave non-agentic SK usage (RAG, function calling, embeddings) untouched.

AI-Friendly Summary

Summary

Migration from Semantic Kernel Agents to Microsoft Agent Framework preserves plugins, DI patterns, and kernel configuration. The primary changes are in agent lifecycle management (explicit threads), orchestration patterns (sequential, concurrent, handoff, group chat), and production features (checkpointing, human-in-the-loop). Recommendation: start new agentic projects on Agent Framework, and migrate existing production SK agents in staged increments with parallel validation.

Key Takeaways

  • Plugins with [KernelFunction] transfer directly — no code changes needed
  • Agent lifecycle moves from implicit to explicit thread management
  • Four built-in orchestration patterns replace custom multi-agent coordination
  • Checkpointing and human-in-the-loop are native to Agent Framework
  • SK and Agent Framework coexist in the same project via shared Kernel

Implementation Checklist

  • Audit existing SK agent code for ChatCompletionAgent and AgentGroupChat usage
  • Verify all plugins use [KernelFunction] attribute (compatible with both)
  • Map current orchestration logic to Agent Framework patterns
  • Prototype migration in a branch using Agent Framework RC
  • Plan production cutover for post-GA timeline

Frequently Asked Questions

Do Semantic Kernel plugins work in Agent Framework?

Yes. Agent Framework is built on top of Semantic Kernel. Your existing KernelFunction-annotated plugins transfer directly without code changes. The DI registration, kernel configuration, and plugin loading patterns are identical.

Is Semantic Kernel deprecated?

No. Semantic Kernel remains the recommended SDK for AI orchestration in .NET — plugins, memory, function calling, and chat completions. Agent Framework extends SK for agentic scenarios. If you're not building autonomous agents, stay on SK.

What is the timeline for migrating production SK agents?

Agent Framework is now the default target for new .NET agent systems. Migrate existing production SK agents in planned increments: first move shared plugins and DI configuration, then port orchestration loops, then validate checkpointing and human-in-the-loop flows under load before switching production traffic.

Can I use Agent Framework and Semantic Kernel in the same project?

Yes. Agent Framework depends on Semantic Kernel. You can use SK features (plugins, memory, embeddings) alongside Agent Framework orchestration in the same application. They share the same Kernel instance.

Track your progress through this learning path.

You Might Also Enjoy

Was this article useful?

Feedback is anonymous and helps us improve content quality.

Discussion

Engineering discussion powered by GitHub Discussions.

#Microsoft Agent Framework #Semantic Kernel #Migration #AI Agents #.NET AI