Microsoft Agent Framework vs Semantic Kernel: What Changed and Why It Matters

Half your team has a working Semantic Kernel plugin. The other half just watched a Microsoft session on Agent Framework and is asking whether to rewrite. The honest answer is "no, but also kind of yes," and the nuance is worth knowing before you commit a sprint.

I've migrated a couple of services across this exact gap. Here's what I learned.

What Microsoft actually changed

Semantic Kernel was a generalist SDK. Plan, prompt, plugin, memory, kitchen sink for "AI orchestration." Agent Framework narrows the focus. It is opinionated about agents specifically. A thing with an identity, tools, state, and a deterministic-ish lifecycle. Less primitive surface area, more workflow shaped opinions.

The fairest analogy I've found is ASP.NET versus raw HTTP listeners. SK gave you the building blocks. Agent Framework gives you the convention. Both have their place, but most of the time you want the convention.

Defining an agent in each

// Semantic Kernel — plugin-centric
var kernel = Kernel.CreateBuilder()
    .AddOpenAIChatCompletion("gpt-4o-mini", apiKey)
    .Build();
kernel.Plugins.AddFromType<EmailPlugin>();
var result = await kernel.InvokePromptAsync(
    "Draft a reply to: {{$thread}}",
    new() { ["thread"] = thread });

// Agent Framework — agent-centric
var agent = new ChatAgent(
    name: "EmailDrafter",
    instructions: "You are a polite assistant who drafts customer replies.",
    model: "gpt-4o-mini",
    tools: new[] { Tools.FromType<EmailPlugin>() });

var run = await agent.RunAsync(thread);
Console.WriteLine(run.FinalOutput);

Why this matters

The Agent Framework code is shorter not because it has less power. It's shorter because the framework has opinions. An agent owns its model, instructions, and tools as first-class properties. In SK you reassembled those each call. The new model also maps cleanly onto multi-agent workflows. One agent calling another. That was the missing piece in SK that everyone hand-rolled and got slightly wrong.

When to migrate

Greenfield projects, anything multi-agent, or anywhere your SK code has grown into a tangled orchestration layer you keep patching. The framework's opinions save you from re-inventing patterns you already invented poorly. (Speaking from experience.)

When to stay on SK

If your current usage is "single prompt plus a couple of plugins" and it works, leave it alone. No payoff for migration. Same answer if you have deep custom kernel hooks. Custom planners, custom memory, anything you wrote at the kernel level. Porting those is more work than the new conveniences are worth.

Conceptual diff

flowchart LR
    subgraph SK ["Semantic Kernel"]
        K[Kernel] --> P1[Plugins]
        K --> M1[Memory]
        K --> Pl[Planner]
        K --> Prompt[Prompt template]
    end
    subgraph AF ["Agent Framework"]
        A[Agent] --> I[Instructions]
        A --> T[Tools]
        A --> St["State / Thread"]
        A --> Mod[Model config]
        A --> W[Workflows<br/>multi-agent]
    end
    SK -- migrate --> AF

Conclusion

Pick one existing SK plugin and wrap it in an Agent Framework ChatAgent. Ship it to a non-critical surface. You'll learn more about the migration tax in two days of real code than a week of reading the docs. That's how I made up my mind.