Microsoft Agent Framework - Building Blocks for AI Part 3 - .NET Blog

Welcome back to the building blocks for AI in .NET series! In part one, we explored Microsoft Extensions for AI (MEAI) and how it provides a unified interface for working with large language models. In part two, we dove into Microsoft.Extensions.VectorData and how it brings semantic search and RAG patterns to .NET. Today, we’re exploring the third building block: the Microsoft Agent Framework.
Up to this point, we’ve been building the foundation. MEAI gave us a universal way to talk to models, and VectorData gave us the ability to store and search knowledge. But what if you want an AI that can do things? Not just answer questions, but take actions, use tools, remember context across conversations, and coordinate with other agents to solve complex problems? That’s where agents come in.
An AI agent is more than a chatbot. A chatbot receives input, passes it to a model, and returns the output. An agent, on the other hand, has autonomy. It can reason about a task, decide which tools to use, call those tools, evaluate the results, and decide what to do next. It can accomplish all this without forcing you to write explicit step-by-step instructions for every scenario.
Think of it this way: if MEAI is like having a conversation with a colleague, an agent is like handing that colleague a to-do list and letting them figure out how to get it done. They might search for information, run calculations, check the weather, look up a database and use whatever tools you’ve made available to them.
The Microsoft Agent Framework provides a production-ready SDK for building these intelligent agents in .NET (and other languages like Python, though we’ll focus on C# here). It achieved its 1.0 release in April 2026 and supports everything from simple single-agent scenarios to complex multi-agent workflows with graph-based orchestration.
Let’s start simple. If you’ve used MEAI and/or read Part 1, the Agent Framework will feel familiar because it builds directly on top of IChatClient. Create a console app, then install the agent framework:
Here’s all it takes to create an agent (01_hello_agent):
Notice the .AsAIAgent() extension method. Just like .AsIChatClient() bridges a provider’s SDK to the MEAI abstraction, .AsAIAgent() takes that a step further and wraps it in an agent that can manage sessions, tools, and memory. This works with multiple providers, including Azure OpenAI, OpenAI, GitHub Models, Microsoft Foundry, or even local models via Foundry Local or Ollama.
The agent also supports streaming out of the box:
A joke-telling agent is fun, but agents become truly powerful when you give them tools. Tools are simply functions that the model can decide to call based on the user’s request. The Agent Framework uses the same AIFunctionFactory from MEAI, so if you’ve already defined tools for your chat client, they work here too.
Here’s an agent with a weather tool (02_add_tools):
When the user asks about the weather, the agent doesn’t just guess but recognizes that it has a GetWeather tool available, calls it with the appropriate parameter, and uses the result to formulate its response. You didn’t have to write any “if the user asks about weather, call this function” logic. The model figures it out.
The Description attributes are important. They tell the model what the tool does and what each parameter means, which helps it decide when and how to use the tool. Think of them as the tool’s instruction manual for the AI.
Real conversations don’t happen in a single exchange. Users ask follow-up questions, provide additional context, and expect the agent to remember what was discussed. The Agent Framework handles this with AgentSession (03_multi_turn):
The session preserves the conversation history between calls. When the user asks to “add some emojis to the joke,” the agent knows which joke is being referenced because the session maintains that context.
Sessions can also be serialized and deserialized, which is essential for production scenarios where your agent runs in a stateless service:
Sessions preserve conversation history, but what about longer-term memory? What if you want your agent to remember facts about the user across sessions — their name, preferences, or previous interactions?
The Agent Framework provides AIContextProvider, a mechanism for injecting contextual information into the agent’s workflow. Here’s a simplified version of the memory sample (04_memory) that extracts and remembers user information:
The AIContextProvider has two key methods:
Wire it up when creating the agent:
This pattern is powerful because it separates what the agent remembers from how the agent converses. You can stack multiple context providers — one for user preferences, another for recent interactions, and a third that pulls relevant documents from your VectorData store.
Single agents are useful, but many real-world problems benefit from breaking the work across multiple specialized agents. The Agent Framework provides a graph-based workflow system where you connect executors (processing units) with edges (data flow paths).
Here’s a simple workflow that chains two text processors together (05_first_workflow):
The text processing example keeps things simple, but the real power of workflows shines when you use agents as executors. Here are some of the patterns the framework supports:
One of the most practical patterns is the writer-critic workflow. Imagine you have one agent that writes marketing copy and another that reviews it for quality:
The writer produces a draft, the critic evaluates it, and if it isn’t approved, the draft goes back to the writer for revision. This loop continues until the critic is satisfied. Of course, for safety, you probably want to provide a maximum iteration count.
AI doesn’t replace humans, and often may require human input. Think of agents as specialized workers that are directed by humans through code. The Agent Framework supports tool approval workflows where the agent proposes a tool call and