Log in
Learn how to build production-ready AI agents in C# using Microsoft Agent Framework. Covers setup, memory management, tools, and multi-agent workflows.
Last Updated: January 2, 2026
I spent the better part of last month trying to figure out which Microsoft AI framework I should actually be using for AI orchestration. Semantic Kernel? AutoGen? Microsoft.Extensions.AI? The answer turned out to be all of them, sort of.
Microsoft Agent Framework is the new kid on the block. It launched in public preview a few months back, and it's basically what happens when the teams behind AutoGen and Semantic Kernel decide to stop maintaining two separate frameworks and build one that doesn't make you choose.
What Is Microsoft Agent Framework?
It's what Microsoft is building to replace both AutoGen and Semantic Kernel. Same teams, one framework.
You get agents that can remember conversations, call C# methods as tools, and coordinate with other agents. The underlying abstraction layer works with OpenAI, Azure OpenAI, Ollama, whatever.
Thread-based state management is built in. So is telemetry, filters, and all the production stuff you'd have to bolt on yourself with the older frameworks.
It's in public preview right now. GA is expected in early 2026.
That means breaking changes could happen. I've already hit a couple while testing. The team removed NotifyThreadOfNewMessagesAsync in one release. Added a breaking change to how you create threads in another. Nothing catastrophic, but worth knowing if you're planning to ship this to production next week.
Why You'd Use This Instead of Semantic Kernel
I asked myself the same question.
Semantic Kernel works fine for prompt chains and function calling. But if you need agents that maintain context across a dozen conversation turns, or coordinate with other agents, Semantic Kernel starts fighting you.
Agent Framework handles that natively. Graph-based execution, conditional routing, persistent threads. The stuff that requires custom plumbing in Semantic Kernel just works here.
Migration path exists if you're already using the older frameworks. They're not going away, just not getting new features.
Setting Up Your First Agent
You'll need .NET 8 or later. I'm using .NET 10, which has Agent Framework baked in with better integration.
Install the packages:
dotnet add package Azure.AI.OpenAI --version 2.1.0
dotnet add package Azure.Identity --version 1.17.1
dotnet add package Microsoft.Extensions.AI.OpenAI --version 10.1.1-preview.1.25612.2
dotnet add package Microsoft.Agents.AI.OpenAI --version 1.0.0-preview.251219.1
The Microsoft.Extensions.AI packages are in preview. The Agent Framework packages (Microsoft.Agents.AI.OpenAI) are also preview as of January 2026.
Here's the simplest possible agent:
using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;
using OpenAI;
AIAgent agent = new OpenAIClient("your-api-key")
.GetChatClient("gpt-4o-mini")
.AsIChatClient()
.CreateAIAgent(instructions: "You help developers find accurate technical information.");
var response = await agent.RunAsync("What is C#?");
Console.WriteLine(response);
That's it. You've got an agent.
It won't do much yet. But it exists, it has a personality (defined by the instructions), and it knows how to talk to OpenAI. You can also use Azure OpenAI by swapping OpenAIClient with AzureOpenAIClient and providing your Azure endpoint.
Adding Memory with Thread Management
Agents need memory. Otherwise every conversation starts from scratch.
Agent Framework handles this with threads. Each thread maintains its own conversation history and context.
AIAgent agent = new OpenAIClient("your-api-key")
.GetChatClient("gpt-4o-mini")
.AsIChatClient()
.CreateAIAgent(instructions: "You are a helpful technical assistant.");
AgentThread thread = agent.GetNewThread();
// First turn
var response1 = await agent.RunAsync(
"What's the difference between IAsyncEnumerable and Task<List>?",
thread
);
Console.WriteLine(response1);
// Second turn - agent remembers the context
var response2 = await agent.RunAsync(
"Which one should I use for streaming large datasets?",
thread
);
Console.WriteLine(response2);
The thread persists state. Next time you call RunAsync with the same thread, the agent remembers what you talked about.
I tested this with a five-turn conversation about SQL Server indexing. The agent referenced earlier points in the conversation without me having to repeat context. Worked exactly how you'd hope.
Giving Your Agent Tools
Tools are where this framework earned my respect.
You write normal C# methods. Slap some attributes on them. The agent figures out when to call them.
using System.ComponentModel;
using Microsoft.Extensions.AI;
[Description("Gets the current weather for a location")]
async Task<string> GetWeather([Description("City name")] string city)
{
// Simulate API call
await Task.Delay(500);
return $"Sunny, 72°F in {city}";
}
var chatClient = new OpenAIClient("your-api-key")
.GetChatClient("gpt-4o-mini")
.AsIChatClient();
AIAgent weatherAgent = chatClient.CreateAIAgent(
name: "WeatherAgent",
instructions: "You provide weather information.",
tools: [AIFunctionFactory.Create(GetWeather)]
);
var response = await weatherAgent.RunAsync("What's the weather in Seattle?");
Console.WriteLine(response);
The agent sees the question, recognizes it needs weather data, calls your GetWeather method, and incorporates the result into its response. You don't write any of that orchestration logic.
You can give an agent multiple tools. The model figures out which ones to use.
I built a documentation agent that could search GitHub, read file contents, and query Stack Overflow. Gave it six different tools. It figured out which ones to use based on the question. Still feels like magic even after testing it fifty times.
Multi-Agent Workflows
Single agents are fine for simple tasks. But some problems need specialization.
You can coordinate multiple agents. Give each one a specific job:
var openAIClient = new OpenAIClient("your-api-key");
var researchAgent = openAIClient
.GetChatClient("gpt-4o-mini")
.AsIChatClient()
.CreateAIAgent(instructions: "You find and verify technical information. Be concise.");
var writerAgent = openAIClient
.GetChatClient("gpt-4o-mini")
.AsIChatClient()
.CreateAIAgent(instructions: "You write clear, concise documentation based on research.");
// Research phase
var researchThread = researchAgent.GetNewThread();
var researchResult = await researchAgent.RunAsync(
"Provide key technical facts about: async/await in C#",
researchThread
);
Console.WriteLine($"Research: {researchResult}");
// Writing phase - pass research results to writer
var writerThread = writerAgent.GetNewThread();
var documentation = await writerAgent.RunAsync(
$"Based on this research, write a brief explanation:\n\n{researchResult}",
writerThread
);
Console.WriteLine($"Documentation: {documentation}");
You pass a question to the research agent. It does its work. Then you take those results and feed them to the writer agent, which produces documentation.
That's the simple version. You can also build conditional routing, shared state, graph-based patterns. Whatever the workflow needs.
I built a code review workflow with four agents: one that analyzed performance, one that checked security, one that looked for maintainability issues, and one that synthesized everything into actionable feedback. Worked better than I expected.
What About Microsoft.Extensions.AI?
You'll see both names floating around. Here's the distinction.
Microsoft.Extensions.AI is the abstraction layer. It's what lets you write code against IChatClient and swap between OpenAI, Azure OpenAI, or Ollama without changing anything.
Agent Framework sits on top of that. It gives you the agent primitives, thread management, tool orchestration. The actual agentic stuff.
You'll use both. Extensions.AI for the client, Agent Framework for everything else.
Things That Tripped Me Up
Breaking changes. Preview means the API surface can shift. Check the release notes before updating.
Token costs. Agents with memory accumulate conversation history. Long threads mean big token counts. You'll want to implement some kind of summarization or truncation strategy.
Error handling. If a tool throws an exception, you need to catch it and return something the agent can understand. Otherwise the conversation just stops.
Testing. I'm still figuring out the best way to test agent behavior. Unit testing individual tools is straightforward. Testing multi-turn conversations with nondeterministic responses? Harder.
Is It Ready for Production?
Depends on your risk tolerance.
The underlying Microsoft.Extensions.AI layer is GA. Stable. Supported.
Agent Framework is still in preview with GA expected soon. Microsoft says existing workloads on AutoGen or Semantic Kernel are safe. No breaking changes planned for migration paths. But "no breaking changes planned" isn't the same as "no breaking changes will happen."
If you're building something new, the framework is stable enough for most use cases. Just pin your package versions and watch for updates as it approaches GA.
I've been running Agent Framework in a side project for the last month. Zero production traffic, but enough testing to get a feel for it. It's stable enough that I'm not worried. Just keeping an eye on the GitHub releases.
Frequently Asked Questions
What's the difference between Agent Framework and Semantic Kernel?
Agent Framework is the replacement. Microsoft's consolidating both AutoGen and Semantic Kernel into this.
Main difference is state management. Semantic Kernel doesn't have built-in conversation persistence. Agent Framework does. If you're building anything that needs to remember context beyond a single turn, this is the easier path.
Is Microsoft Agent Framework production-ready?
Depends on your definition of production-ready.
The underlying Microsoft.Extensions.AI layer is GA. That part's stable and supported. Agent Framework itself is still in preview as of January 2026, but it's close to GA.
I've been using it for side projects. Haven't hit anything catastrophic. Just pin your package versions and keep an eye on the release notes. Breaking changes are possible until GA, but Microsoft says the migration paths won't break.
Can I migrate from AutoGen or Semantic Kernel to Agent Framework?
Yes. That's exactly what Microsoft designed this for.
I migrated a Semantic Kernel project last month. Thread management replaced some of my orchestration patterns. Agent definitions replaced others. Took about a day for a medium-sized codebase.
The core abstractions are similar enough that you're not rewriting everything from scratch. And both AutoGen and Semantic Kernel still get security updates, so you're not on a hard deadline.
What AI models does Agent Framework support?
Anything that implements IChatClient from Microsoft.Extensions.AI.
I've tested it with Azure OpenAI, OpenAI, and Ollama. All worked without changing agent logic. That's the whole point of the abstraction layer. Write once, swap providers when your budget or requirements change.
Final Thoughts
Microsoft Agent Framework finally gives .NET developers a first-class way to build AI agents without duct-taping together three different libraries.
If you've been waiting for the AutoGen and Semantic Kernel teams to pick a direction, this is it. Start here. The documentation is solid, the patterns are clear, and the migration path from older frameworks exists.
Just remember it's preview. Pin your versions. Watch for breaking changes. Test your tools thoroughly.
The future of AI in .NET looks like this. You might as well get familiar with it now.
About the Author
I'm Mashrul Haque, a Systems Architect with over 15 years of experience building enterprise applications with .NET, Blazor, ASP.NET Core, and SQL Server. I specialize in Azure cloud architecture, AI integration, and performance optimization.
When production catches fire at 2 AM, I'm the one they call.
- LinkedIn: Connect with me
- GitHub: mashrulhaque
