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:
ChatCompletionAgentinstantiationOpenAIAssistantAgentinstantiationAgentGroupChatusage- Custom
SelectionStrategyorTerminationStrategyimplementations - 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 Pattern | Agent Framework Equivalent |
|---|---|
Sequential SelectionStrategy | SequentialOrchestrator |
| Custom round-robin | ConcurrentOrchestrator |
| Agent-based routing | HandoffOrchestrator |
AgentGroupChat with multiple agents | GroupChatOrchestrator |
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
| Scenario | Recommendation |
|---|---|
| New project with agents | Start on Agent Framework RC |
| Existing SK agents, production | Plan for post-GA migration |
| SK for RAG/chat/embeddings only | Stay on SK — no migration needed |
| AutoGen agents | Begin planning migration now |
| Evaluating both | Prototype with Agent Framework RC |
Next Steps
- Microsoft Agent Framework: Complete Guide for .NET Developers — Architecture, patterns, and production deployment
- Semantic Kernel Plugins: Build Reusable AI Tools in C# — Your plugins transfer directly — master them
- Microsoft Agent Framework RC: What .NET Developers Need to Know — Release details and timeline