Microsoft Agent Framework: What It Is, and Semantic Kernel

Microsoft Agent Framework is Microsoft’s open-source SDK for building AI agents and multi-agent workflows in .NET and Python, with Go in public preview. Microsoft calls it the direct successor to Semantic Kernel and AutoGen, built by the same teams: AutoGen’s simple agent abstractions combined with Semantic Kernel’s enterprise features such as sessions, type safety, middleware and telemetry, plus graph-based workflows. Version 1.0 shipped in April 2026 with stable APIs and a commitment to long-term support. Semantic Kernel is still supported but gets few new features, and AutoGen is in maintenance mode, so a new .NET or Python agent project should start here.

What it is made of

The Agent Framework overview↗ (opens in a new tab) on Microsoft Learn divides it into four areas:

• Agents: a model plus instructions, tools and MCP servers. Providers include Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic and Ollama.
• The Harness agent: an opinionated agent for long, multi-step tasks, with planning and todo tracking, context compaction, file memory, standing tool approvals and observability built in.
• Workflows: functional and graph-based flows that connect agents and ordinary functions along explicit paths, with state for long-running and human-in-the-loop runs.
• Integrations: model providers, agent services, tools, memory and context providers, middleware, evaluation and UI frameworks.

Underneath sit the building blocks: model clients for chat completions and responses, an agent session for state, context providers for memory, middleware that intercepts agent actions, and MCP clients. In .NET the shared message and tool types come from Microsoft.Extensions.AI, so an AIFunction written for one provider works with any other.

Release status, and the packages

Microsoft’s 1.0 announcement↗ (opens in a new tab) called both .NET and Python production-ready, with Microsoft.Agents.AI on NuGet and agent-framework on PyPI, and listed features that stayed in preview at the time, among them DevUI, skills and the harness. At Build in June the team introduced the agent harness, listed Foundry hosted agents and the GitHub Copilot SDK integration as reaching 1.0, and shipped CodeAct as an alpha package. Go is in public preview. Not every package has followed: on NuGet today Microsoft.Agents.AI, Microsoft.Agents.AI.OpenAI, Microsoft.Agents.AI.Workflows and Microsoft.Agents.AI.Harness are stable releases, while the Foundry and Anthropic provider packages are still published as previews. Check the version of each package you add.

Semantic Kernel and AutoGen, as Microsoft describes them

• Semantic Kernel: in the team’s post on Semantic Kernel’s future↗ (opens in a new tab), version 1.x keeps getting fixes for critical bugs and security issues, and stays supported for at least one year after Agent Framework became generally available. Most new features go to Agent Framework, which the product lead describes as Semantic Kernel v2.0.
• AutoGen: its repository README↗ (opens in a new tab) says it is in maintenance mode, will not receive new features or enhancements, is community managed, and that new users should start with Microsoft Agent Framework.
• Both: Microsoft Learn has a migration guide for each, summarised below.

Agents or workflows

The overview gives a short rule. Use an agent when the task is open-ended or conversational and the model should plan and pick tools. Use a workflow when the process has well-defined steps, you need explicit control over execution order, or several agents and functions must coordinate. It adds one line worth keeping: if you can write a function to handle the task, do that instead of using an AI agent.

A minimal agent in C#, with a local tool and MCP tools

This agent has one tool written in C# and every tool from a remote MCP server, here a fenbs board, reached over Streamable HTTP with a token in a header. It uses the OpenAI provider and the official MCP C# SDK.

dotnet new console -n TriageAgent -f net10.0
cd TriageAgent
dotnet add package Microsoft.Agents.AI.OpenAI
dotnet add package ModelContextProtocol

using System.ComponentModel;
using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;
using ModelContextProtocol.Client;
using OpenAI;
using OpenAI.Chat;

// A local function tool: the descriptions are what the model reads.
[Description("Returns the build status of a branch.")]
static string GetBuildStatus([Description("Branch name, for example main.")] string branch)
    => branch == "main" ? "green" : "unknown";

// Tools from a remote MCP server, over Streamable HTTP with a bearer token.
await using McpClient board = await McpClient.CreateAsync(new HttpClientTransport(new()
{
    Endpoint = new Uri("https://fenbs.ai/api/mcp"),
    AdditionalHeaders = new Dictionary<string, string>
    {
        ["Authorization"] = $"Bearer {Environment.GetEnvironmentVariable("FENBS_TOKEN")}"
    },
}));
IList<McpClientTool> boardTools = await board.ListToolsAsync();

AIAgent agent = new OpenAIClient(Environment.GetEnvironmentVariable("OPENAI_API_KEY"))
    .GetChatClient("gpt-4o-mini")
    .AsAIAgent(
        name: "Triage",
        instructions: "Check the build, then comment what you found on the task you are given.",
        tools: [AIFunctionFactory.Create(GetBuildStatus), .. boardTools]);

AgentSession session = await agent.CreateSessionAsync();
Console.WriteLine(await agent.RunAsync("Task BUG-031: is main green?", session));

This builds without warnings on .NET 10 against Microsoft.Agents.AI.OpenAI 1.22.0 and ModelContextProtocol 2.2.0; it was compiled, not run against a live model. Three details matter. AsAIAgent on an OpenAI ChatClient lives in the OpenAI.Chat namespace, so without that using the call does not resolve. MCP tools are already AITool objects, so they spread straight into the same list as your own. And the Chat Completions client is used here because the OpenAI .NET library still marks GetResponsesClient() as for evaluation only, a diagnostic you must suppress to build; Microsoft recommends the Responses client when you need hosted tools such as code interpreter or hosted MCP.

A workflow: two agents in a fixed order

When the order is known, let code decide it. The sequential orchestration↗ (opens in a new tab) passes each agent the previous one’s conversation. This one, from the separate Microsoft.Agents.AI.Workflows package, also compiles against 1.22.0:

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;
using Microsoft.Extensions.AI;
using OpenAI;

IChatClient chat = new OpenAIClient(Environment.GetEnvironmentVariable("OPENAI_API_KEY"))
    .GetChatClient("gpt-4o-mini")
    .AsIChatClient();

ChatClientAgent writer = new(chat,
    "Write one release-note line per merged change, in plain words.", "Writer");
ChatClientAgent reviewer = new(chat,
    "Check each line is accurate and under 100 characters. Return the corrected list.", "Reviewer");

Workflow workflow = AgentWorkflowBuilder.BuildSequential(writer, reviewer);

List<ChatMessage> input = [new(ChatRole.User, "Merged: retry key is now the order id; new CSV export.")];
await using StreamingRun run = await InProcessExecution.RunStreamingAsync(workflow, input);
await run.TrySendMessageAsync(new TurnToken(emitEvents: true));

await foreach (WorkflowEvent evt in run.WatchStreamAsync())
{
    if (evt is WorkflowOutputEvent output)
    {
        foreach (ChatMessage m in output.As<List<ChatMessage>>()!)
            Console.WriteLine($"{m.AuthorName}: {m.Text}");
        break;
    }
}

Other built-in orchestrations include handoff, where agents pass control and the user can reply between turns, and custom graphs built with WorkflowBuilder. Wrap a tool in ApprovalRequiredAIFunction and a sequential workflow pauses with a RequestInfoEvent until someone approves the call.

Tools and MCP

• Function tools: any method, passed through AIFunctionFactory.Create. A [Description] attribute is optional but is what the model reads.
• Local MCP tools: in .NET, through the official MCP C# SDK as above; in Python, MCPStdioTool, MCPStreamableHTTPTool and MCPWebsocketTool. The MCP tools page↗ (opens in a new tab) notes these work with any provider that supports function tools.
• Hosted MCP tools: the provider’s service calls the server for you. The provider matrix lists this for the OpenAI Responses client, Foundry, Anthropic and GitHub Copilot, not for Chat Completions or Ollama.
• An agent as an MCP server: wrap it with AsAIFunction() and register it with McpServerTool.Create, so another MCP client, such as an assistant in VS Code, can call it as a tool.
• Agents as tools: AsAIFunction() also lets one agent call another like a function.

Migrating from Semantic Kernel

• No Kernel. Agents are created from a client with AsAIAgent(...), and the per-service agent classes (ChatCompletionAgent, AzureAIAgent, OpenAIAssistantAgent) collapse into one ChatClientAgent.
• Plugins become tools passed at creation. [KernelFunction] is no longer required; a plain method with an optional [Description] will do.
• Threads become sessions, created by the agent: await agent.CreateSessionAsync().
• InvokeAsync becomes RunAsync, which returns one AgentResponse, and InvokeStreamingAsync becomes RunStreamingAsync.
• Namespaces move to Microsoft.Agents.AI and Microsoft.Extensions.AI, and dependency injection registers an AIAgent instead of a Kernel.
• In Python, an existing KernelFunction converts with as_agent_framework_tool() from Semantic Kernel 1.38, so you can move agents first and tools later.

If your Semantic Kernel code used the OpenAI Assistants agent, migrate that part to the Responses API rather than looking for an equivalent: OpenAI shut the Assistants API down on 26 August 2026, and Agent Framework no longer documents an Assistants client.

Migrating from AutoGen

• AssistantAgent maps to Agent, which keeps calling tools until it has an answer; AutoGen’s agent was single-turn unless you raised max_tool_iterations.
• FunctionTool wrappers become the @tool decorator, or a plain function whose docstring becomes the description.
• Teams such as RoundRobinGroupChat and MagenticOneGroupChat become workflows, with built-in orchestrations for the common patterns.
• The runtime is single-process today; the guide says distributed execution is planned.

Who it suits

It suits .NET teams first: nothing else here is as native to C#, dependency injection and Microsoft.Extensions.AI. It suits teams on Azure and Microsoft Foundry, and anyone with Semantic Kernel or AutoGen code that needs a future. It is a harder sell for a TypeScript shop, and for anyone who wants a tiny dependency; for a comparison with the other frameworks, see AI agent frameworks compared.

Giving the agent a board to report to

The example above already does it. fenbs is an MCP server, so ListToolsAsync() hands the agent the board’s tools: reading a task, commenting, moving it between To Do, Next Up, In Progress and Completed. For a service with no browser, issue a token by hand under Settings, “Connect an AI assistant”, with a name, the scopes it needs and an optional expiry, and keep it in configuration, never in code. The board checks every call against those scopes and your role, records each change under the assistant’s name, and stops the agent at once if you revoke the token.