Microsoft Agent Framework vs Semantic Kernel: Which to Use in C#

Choosing between microsoft agent framework vs semantic kernel in C# is one of the most pressing decisions for .NET developers building AI-powered agents. Both tools come from Microsoft, both target AI agent development, and both integrate with the broader .NET ecosystem -- but they serve different use cases, carry different trade-offs, and sit at very different points in their maturity lifecycle.

If you already have a Semantic Kernel codebase, you might wonder whether the Microsoft Agent Framework (MAF) changes anything for you. If you are starting fresh, you might wonder which one to reach for first. This article is built to answer that question directly, with concrete side-by-side code examples, a feature comparison table, and a clear decision guide so you can stop second-guessing and start building.

One important note before diving in: Microsoft Agent Framework is in public preview at version 1.0.0-rc1. The API surface is not yet stable and may shift before general availability. Factor that into any production planning.

What Is the Microsoft Agent Framework?

The Microsoft Agent Framework is a relatively new, lightweight library designed to make building AI agents in .NET as simple as possible. It is built natively on top of Microsoft.Extensions.AI and works directly with the IChatClient abstraction. That means it plugs into the broader Microsoft.Extensions ecosystem with very little glue code -- no new DI patterns to learn, no alien configuration model to understand.

MAF is deliberate about staying lightweight. The library avoids heavy abstractions, keeps the public API surface small, and lets you get a functional agent running in a handful of lines. Function and tool registration is done through AIFunctionFactory.Create(), which uses delegates and reflection to generate callable tool descriptions from ordinary C# methods. The approach feels familiar if you have worked with minimal API handlers in ASP.NET Core.

Because MAF is built on IChatClient, it is also provider-agnostic in the same way the rest of Microsoft.Extensions.AI is. You can swap the underlying LLM provider without touching your agent logic. Any IChatClient middleware you already have -- rate limiting, observability, retry -- carries over directly with no abstraction mismatch to bridge.

What Is Semantic Kernel?

Semantic Kernel (SK) is a mature, feature-rich AI orchestration framework from Microsoft. It has been in active development for years and has accumulated a deep plugin ecosystem, built-in memory and embedding support, multi-agent orchestration primitives, and a wide range of LLM connectors.

If you need to build complex agents with structured plugin hierarchies, retrieval-augmented generation, vector store integration, or orchestrated multi-agent workflows, Semantic Kernel has dedicated infrastructure for all of those scenarios. The framework uses its own Kernel type as the central orchestration object. Functions are registered as plugins, and the planner or agent loop calls them based on the conversation context. This design gives you a lot of power -- at the cost of more concepts to internalize and more ceremony to set up.

For a thorough look at SK's full agent model and capabilities, Semantic Kernel Agents in C# covers the complete picture.

Feature Comparison at a Glance

This table captures the core trade-off. MAF wins on simplicity, ecosystem fit, and developer experience. Semantic Kernel wins on depth, maturity, and breadth of features.

MAF Strengths

The biggest appeal of the Microsoft Agent Framework for new projects is how little ceremony it requires. If you have already used IChatClient from Microsoft.Extensions.AI, MAF feels like a natural extension -- not a new framework to learn but a thin layer on top of primitives you already know.

Tool registration in MAF uses AIFunctionFactory.Create() with delegates. There are no special base classes to inherit from, no attribute-decorated plugin class hierarchies to maintain, and no kernel builder pattern to configure before you can call a function. For small, focused agents, this directly translates to faster development cycles and a codebase that stays readable as it grows.

MAF also shines for teams that have invested in Microsoft.Extensions.AI middleware. Any IChatClient pipeline you have built -- with logging, rate limiting, content filtering, or retry policies -- applies to MAF agents automatically. There is no second abstraction layer to carry it through.

One more practical advantage: the lack of a Kernel dependency means MAF integrates cleanly into microservice-style architectures where you want agent logic to be a focused, replaceable component rather than a heavyweight orchestrator.

Semantic Kernel Strengths

Semantic Kernel brings a maturity advantage that becomes undeniable the moment your requirements grow beyond a simple chat loop. If you need structured plugin hierarchies with auto-invocation, function chaining, and per-plugin configuration, SK has well-established patterns for all of it. The Semantic Kernel Plugin Best Practices guide covers the design patterns that keep large plugin codebases maintainable. For a thorough overview of SK's plugin model, Semantic Kernel Plugins Complete Guide is required reading.

The built-in memory and embedding support is another significant differentiator. SK includes first-class abstractions for text embedding generation, semantic memory, and vector store integration. You can build RAG pipelines and long-term memory features without pulling in unrelated libraries -- nothing equivalent exists out of the box in MAF. For a concrete look at what SK's memory layer can do, Semantic Kernel Vector Store covers Azure AI Search, Qdrant, and other backends.

SK also has much richer multi-agent support. If you need to compose multiple agents with selection strategies and termination conditions, Multi-Agent Orchestration with Semantic Kernel shows how AgentGroupChat and related primitives make that possible at scale. MAF does not yet have equivalent orchestration scaffolding.

Finally, SK has a larger community, more documentation, more third-party integrations, and a longer track record in production environments. If you are building something that needs to be maintained over years or by a team that will grow, that ecosystem depth matters in ways that are easy to underestimate early on.

Code Examples

The following four examples show the same task done in both frameworks. The MAF examples reflect the 1.0.0-rc1 preview API and may change before general availability -- treat them as representative of the current API shape rather than a guaranteed stable contract.

Creating a Basic Agent

Semantic Kernel approach:

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Agents;
using Microsoft.SemanticKernel.ChatCompletion;

// Build the kernel and register an LLM provider
var kernel = Kernel.CreateBuilder()
    .AddAzureOpenAIChatCompletion(
        deploymentName: "gpt-4o",
        endpoint: "https://your-endpoint.openai.azure.com/",
        apiKey: "your-api-key")
    .Build();

// Create a chat completion agent with instructions
var agent = new ChatCompletionAgent
{
    Name = "CodingAssistant",
    Instructions = "You are a helpful C# coding assistant.",
    Kernel = kernel
};

// Invoke the agent and stream responses
await foreach (var message in agent.InvokeAsync(
    new ChatMessageContent(AuthorRole.User, "What is a record type in C#?")))
{
    Console.WriteLine(message.Content);
}

Microsoft Agent Framework approach (1.0.0-rc1 preview):

using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;

// IChatClient is the provider-agnostic abstraction from Microsoft.Extensions.AI
IChatClient chatClient = new AzureOpenAIClient(
    new Uri("https://your-endpoint.openai.azure.com/"),
    new AzureKeyCredential("your-api-key"))
    .GetChatClient("gpt-4o")
    .AsIChatClient();

// Create an agent -- minimal setup, no Kernel required
IAIAgent agent = chatClient.AsAIAgent(
    instructions: "You are a helpful C# coding assistant.");

// Single-turn invocation
AgentResponse response = await agent.RunAsync("What is a record type in C#?");
Console.WriteLine(response.Text);

The SK version gives you more configuration hooks and plugs into the full SK ecosystem. The MAF version is concise and leans entirely on IChatClient -- no new abstractions are introduced.

Function and Tool Registration

Semantic Kernel using [KernelFunction]:

using Microsoft.SemanticKernel;
using System.ComponentModel;

// Plugin class with decorated methods -- SK discovers and registers them automatically
public class WeatherPlugin
{
    [KernelFunction("get_weather")]
    [Description("Gets the current weather for a city")]
    public string GetWeather(
        [Description("The name of the city")] string city)
    {
        // Real implementation would call a weather API
        return $"It is 22°C and sunny in {city}.";
    }
}

// Register the plugin with the kernel before agent creation
kernel.Plugins.AddFromType<WeatherPlugin>();

Microsoft Agent Framework using AIFunctionFactory:

using Microsoft.Extensions.AI;

// Register tools as delegates -- no plugin class or attributes required
var getWeather = AIFunctionFactory.Create(
    ([Description("The name of the city")] string city) =>
        $"It is 22°C and sunny in {city}.",
    name: "get_weather",
    description: "Gets the current weather for a city");

// Pass tools directly to the agent at construction time
IAIAgent agent = chatClient.AsAIAgent(
    instructions: "You are a weather assistant.",
    tools: [getWeather]);

[KernelFunction] is more structured and works well in large codebases where discoverability and IDE navigation matter. AIFunctionFactory is faster to wire up and suits single-purpose agents where a formal plugin class would be overkill. For an in-depth look at SK's function calling model, Semantic Kernel Function Calling covers the native vs prompt function distinction in detail.

Multi-Turn Conversation Handling

Semantic Kernel using ChatHistory:

using Microsoft.SemanticKernel.ChatCompletion;

// ChatHistory is SK's container for the conversation so far
var history = new ChatHistory();
history.AddSystemMessage("You are a concise technical assistant.");

var chatService = kernel.GetRequiredService<IChatCompletionService>();

// First turn
history.AddUserMessage("What is dependency injection?");
var reply1 = await chatService.GetChatMessageContentAsync(history);
history.AddAssistantMessage(reply1.Content ?? string.Empty);

// Second turn -- history carries full context automatically
history.AddUserMessage("Can you show a C# constructor injection example?");
var reply2 = await chatService.GetChatMessageContentAsync(history);
Console.WriteLine(reply2.Content);

Microsoft Agent Framework using a conversation thread:

using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;

IAIAgent agent = chatClient.AsAIAgent(
    instructions: "You are a concise technical assistant.");

// A session tracks conversation state -- pass the same session for continuity
AgentSession session = await agent.CreateSessionAsync();

// First turn
AgentResponse reply1 = await agent.RunAsync("What is dependency injection?", session);

// Second turn -- context is maintained through the session
AgentResponse reply2 = await agent.RunAsync("Can you show a C# constructor injection example?", session);
Console.WriteLine(reply2.Text);

Both approaches give you multi-turn memory. SK's ChatHistory is more explicit and lets you inspect and mutate the message list at any point. MAF's session model is more encapsulated -- the agent manages state internally and you pass the AgentSession as a handle.

Dependency Injection Setup

Semantic Kernel in ASP.NET Core:

// Program.cs -- SK has its own registration extension methods
var builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddKernel()
    .AddAzureOpenAIChatCompletion(
        deploymentName: "gpt-4o",
        endpoint: builder.Configuration["AzureOpenAI:Endpoint"]!,
        apiKey: builder.Configuration["AzureOpenAI:ApiKey"]!);

// Plugins and agents are typically registered as transient services
builder.Services.AddTransient<WeatherPlugin>();
builder.Services.AddTransient<IAgentService, SkAgentService>();

Microsoft Agent Framework in ASP.NET Core:

// Program.cs -- MAF uses standard Microsoft.Extensions registration
var builder = WebApplication.CreateBuilder(args);

// Register IChatClient using standard DI
builder.Services.AddSingleton<IChatClient>(sp => new AzureOpenAIClient(
    new Uri(builder.Configuration["AzureOpenAI:Endpoint"]!),
    new AzureKeyCredential(builder.Configuration["AzureOpenAI:ApiKey"]!))
    .GetChatClient("gpt-4o")
    .AsIChatClient());

// Register IAIAgent -- resolved from the registered IChatClient
builder.Services.AddSingleton<IAIAgent>(sp =>
    sp.GetRequiredService<IChatClient>().AsAIAgent(instructions: "You are a helpful assistant."));
builder.Services.AddTransient<IAgentService, MafAgentService>();

The MAF DI setup is leaner because it inherits the standard Microsoft.Extensions registration patterns with no additional abstractions to configure. SK's setup requires understanding the AddKernel() builder and SK-specific extension methods before you can get a working service graph.

When to Choose Microsoft Agent Framework

MAF is the better choice when:

• You are starting a greenfield project with no existing SK codebase to consider
• Your agent's responsibilities are focused and well-scoped -- a single-purpose agent that calls a handful of tools does not need SK's full orchestration machinery
• You are already invested in the Microsoft.Extensions.AI ecosystem and want IChatClient middleware to apply uniformly across all AI calls in your application
• Your team values speed and simplicity over feature breadth -- MAF gets you from idea to working prototype faster
• You are comfortable depending on a public preview API (1.0.0-rc1) that may change before GA

If IChatClient is already central to your architecture and you want the simplest possible agent loop on top of it, MAF fits without friction.

When to Choose Semantic Kernel

The richer feature set, production stability, and established community make it the default for most non-trivial agent systems.

Semantic Kernel is the stronger choice when:

• You need RAG pipelines or vector store integration -- MAF has no equivalent built-in today and SK's memory layer is production-tested
• Your agents require complex plugin orchestration with auto-invocation, function chaining, and per-function configuration -- the [KernelFunction] model and plugin registry handle large function libraries much more cleanly than individual delegates
• You are building multi-agent systems with selection strategies, group chat, and termination conditions -- SK's AgentGroupChat is far more capable for this than anything MAF offers today. Understanding the difference between ChatCompletionAgent vs AssistantAgent in Semantic Kernel helps you use those primitives correctly.
• You have an existing SK codebase -- there is no compelling reason to introduce a second framework for the same role when SK is already working
• You need production stability -- SK is GA and has been running in production systems for years; MAF is still a release candidate

When to Use Both Frameworks Together

This is a legitimate architecture pattern, not just a diplomatic hedge. If you have a large SK-orchestrated system that includes several lightweight inner agents -- for example, a focused agent that handles simple lookups or a narrow task -- you can implement those inner agents using MAF while keeping the orchestration layer in SK.

MAF agents built on IChatClient can be composed as LLM providers inside SK workflows. The two frameworks are not mutually exclusive at the runtime level. Think of it as SK owning the high-level orchestration and plugin management while MAF handles the leaf-level agent nodes where the overhead of a full Kernel instance is not justified.

For comparison with other framework options in the .NET AI space, GitHub Copilot SDK vs Semantic Kernel is worth reading to understand the broader landscape of choices available to C# developers.

Decision Guide

If you find yourself in the middle -- not quite needing SK's full feature set but also not sure MAF's preview status is acceptable -- the pragmatic answer is to start with SK and revisit MAF when it reaches GA. The gap between the frameworks will likely narrow as MAF matures.

Frequently Asked Questions

Is the Microsoft Agent Framework production-ready?

Not yet. MAF is in public preview at version 1.0.0-rc1. It is functional and actively developed, but the API surface may change before the general availability release. For production systems where stability is non-negotiable, Semantic Kernel is the safer choice. MAF is an excellent option for prototyping and greenfield projects where you can absorb the occasional breaking change.

Can I use MAF and Semantic Kernel in the same project?

Yes. The two frameworks are not mutually exclusive. A common pattern is to use Semantic Kernel for high-level orchestration and plugin management while using MAF for lightweight inner agents that communicate through IChatClient. They can coexist in the same dependency injection container without conflict.

Does MAF support the same LLM providers as Semantic Kernel?

MAF is provider-agnostic through the IChatClient abstraction from Microsoft.Extensions.AI. Any LLM provider that exposes an IChatClient implementation works with MAF. Semantic Kernel has direct connectors for OpenAI, Azure OpenAI, Hugging Face, and others. The practical coverage is comparable for major providers, but the mechanism is different -- MAF relies on the Microsoft.Extensions.AI adapter layer while SK has first-class connector packages.

Does Semantic Kernel support Microsoft.Extensions.AI?

SK has been adding Microsoft.Extensions.AI compatibility over time, but it was not originally built on IChatClient. You can use adapters to bridge the two, but there is some impedance mismatch. If tight integration with the Microsoft.Extensions.AI middleware pipeline is a hard requirement, MAF has the cleaner and more natural story.

Which framework handles function calling better?

Both support function and tool calling, but in different styles. SK uses [KernelFunction] attributes on plugin methods, which works well in large codebases where discoverability, documentation, and structured registration matter. MAF uses AIFunctionFactory.Create() with delegates, which is lighter weight and easier to set up for small agents. For complex scenarios with many tools, SK's plugin registry scales better. For simple scenarios, MAF's delegate approach removes boilerplate that would otherwise add noise.

Should I migrate an existing Semantic Kernel codebase to MAF?

Almost certainly not in the current release. MAF is in preview and does not yet match SK's feature set -- specifically in memory, embeddings, and multi-agent orchestration. If you have a working SK codebase, the migration cost is not justified unless you have a specific reason such as wanting simpler agent definitions for a focused subset of your agents. Wait for MAF to reach GA and close more of the feature gap before making migration decisions.

What should I do to protect my code if MAF's API changes before GA?

Keep your MAF integration behind service interfaces in your own code. If the concrete ChatAgent API changes between the RC and GA, the blast radius of the update should be confined to the adapter or implementation layer -- not your domain logic. This is good practice for any preview dependency and requires no MAF-specific workaround.

Wrapping Up

The microsoft agent framework vs semantic kernel decision comes down to scope, maturity, and feature requirements. MAF wins for simplicity, IChatClient-native design, and low boilerplate in greenfield projects where the agent's responsibilities are well-defined. Semantic Kernel wins for depth, maturity, and feature breadth -- especially when you need complex plugin orchestration, RAG pipelines, memory, or multi-agent coordination.

If you are starting from scratch with a focused use case and can accept a preview API, MAF is worth trying. If you need production stability or richer features out of the box, Semantic Kernel remains the clear choice. And for systems that benefit from both -- a heavy SK orchestration layer with lightweight MAF leaf agents -- you do not have to choose at all.