%% Created on: `=dateformat(this.created, "MMM dd, yyyy")` %% > Created on: Oct 15, 2025 # Microsoft Agent Framework: A Unified Approach to Multi‑Agent AI --- ![[agent-framework.png]] --- Building real-time AI “copilot” applications – for example, a smart meeting assistant that transcribes, summarizes, and answers questions on the fly – is **hard**. Without a proper framework, developers must wrangle threads, synchronize multiple AI calls, and ensure nothing blocks critical tasks like audio capture. Even with modern AI coding assistants, orchestrating **multiple agents in parallel** can quickly become a tangle of race conditions and complexity. Microsoft’s new **Agent Framework** aims to change that by combining the best of Semantic Kernel and AutoGen into one open-source toolkit, **bringing cutting-edge AI orchestration together with enterprise-grade stability** . In this post, I will introduce the Agent Framework and explore how it simplifies real-time multi-agent projects for .NET developers and AI enthusiasts – with an example of a Meeting Copilot that would be nearly impossible to build cleanly without such a framework. ## **Best of Both Worlds: AutoGen + Semantic Kernel in One Framework** The **Microsoft Agent Framework** is essentially the successor to both Semantic Kernel and AutoGen, created by the same teams to unify their strengths . AutoGen, a Microsoft Research project, pioneered simple abstractions for multi-agent patterns, whereas Semantic Kernel offered enterprise-ready support (robust state management, security filters, connectors, telemetry, etc.) for integrating AI into real applications. The new framework **combines AutoGen’s simplicity with Semantic Kernel’s production-grade capabilities**, so developers no longer have to choose between rapid experimentation and stability . It’s open-source and cross-platform, currently supporting .NET (C#) and Python, with support for other languages like Java on the way . In short, Agent Framework gives you one unified **SDK for building, orchestrating, and deploying AI agents** without sacrificing flexibility or enterprise requirements . Importantly, Agent Framework is designed to be flexible in the AI models and tools you use. It works out-of-the-box with **Azure OpenAI** and OpenAI APIs, but also allows plugging in other popular cloud-based or local models. For example, you can easily swap the AI backend to a local **Ollama** instance or Foundry’s local container models instead of cloud endpoints . This means developers can experiment with open-source LLMs or **hybrid scenarios** without changing their code – the framework’s abstraction layer (built on Microsoft.Extensions.AI in .NET) makes the AI provider interchangeable . The framework also embraces open standards: it supports the **Model Context Protocol (MCP)** for tool plugins and **Agent-to-Agent (A2A)** messaging for agent collaboration, ensuring your agents remain portable and can even communicate across different runtimes and environments . All of these features come in a familiar NuGet package (Microsoft.Agents.AI) that you can drop into your .NET project to start building agents with minimal boilerplate. It even has the full flow-chart like Workflow support including human in the loop process as well with full designer and mermaid process export support. ## **Real-Time Multi‑Agent Example: A Meeting Copilot Prototype** To illustrate the kind of complex AI application enabled by the Agent Framework, let’s look at a prototype **Meeting Copilot** scenario. In this example (based on an open-source sample project), three AI agents run concurrently to assist in a live meeting: - **Transcription Agent** – Listens to the meeting audio in real time and transcribes it into text. This agent uses Azure OpenAI’s new streaming transcription API, continuously capturing audio from the microphone and streaming text results as the participants talk. Its job is to produce a live transcript with near-zero latency. - **Key Point Extraction Agent** – Listens to the stream of transcribed text and generates a running summary of key points and action items from the conversation. Essentially, it’s doing real-time meeting minutes: condensing the verbose transcript into the most important facts, decisions, or tasks mentioned. - **Q&A Agent** – Monitors the transcribed conversation for any questions that participants ask (e.g. _“Do we have the sales figures from last quarter?”_). When it detects a question, this agent **immediately formulates an answer** by querying an LLM (and possibly calling external tools or knowledge bases if needed), then provides the answer in real time. It’s like having an AI expert in the meeting that can instantly respond to questions. These three agents operate **in parallel**. While the transcription agent is busy streaming audio-to-text, the summarizer agent is simultaneously generating updates, and the Q&A agent is on standby to jump in with answers. Each agent has its own role and they exchange information (the live transcript) through asynchronous channels rather than direct calls, so no single agent blocks the others. The result is a prototype “meeting copilot” that can listen, understand, and contribute to a conversation all at once – a highly complex dance of AI tasks that would be extremely difficult to implement reliably from scratch. ## **Why Building This by Hand Is So Difficult** When you sit down and think, “Okay, I’ll just roll my own multi-agent system,” the complexity climbs fast. For our Meeting Copilot example—with live transcription, summarization, and on-the-fly Q&A agents—here are key pain points and how Microsoft Agent Framework solves or alleviates them: ### 1. Memory (State & Context) Management One major challenge is **agent memory**: each agent must remember relevant past interactions (chat history, intermediate results, tool outputs), while discarding noise or stale context. Without a framework, you’d have to build: - A memory buffer for each agent (short-term history). - A storage system (e.g. vector DB, persistent store) for long-term memory across sessions. - Logic to inject memory into prompts or context when invoking the LLM. - Serialization / deserialization if your process restarts mid-meeting. In Microsoft Agent Framework, memory is a first-class concept. You can supply a custom `ChatMessageStore` (persisted in a DB or in memory) when you create an agent, and the framework will wire it in for you. You can also inject **context providers** that observe messages being sent or received (`InvokingAsync` / `InvokedAsync`) and optionally inject or extract extra memory bits—e.g. user preferences, summary sketches, or cross-agent shared state. Because memory is abstracted, you don’t need to litter your code with “read memory, compute embeddings, re-insert into prompt” boilerplate. And you can switch out memory backends (in-memory store, vector DB, Redis, etc.) later without rewriting your agents. ### 2. Tool / Function Calling (External APIs, Custom Logic) In a real system, your agents rarely just do “prompt → text.” You’ll want them to call **functions or external services** in response to reasoning. For example: - The Q&A agent may need to query a company database or Graph API. - The keypoint agent might run a summarizer or custom logic beyond what is easy in plain text. - The transcription agent might trigger a timeout or control logic. Implementing this yourself means intercepting LLM outputs that indicate “call this tool,” parsing arguments, invoking the function, handling errors, returning results, and then re-entering the LLM chain. The control flow gets messy when multiple agents can call tools concurrently. Agent Framework supports **function tools** (or “AIFunctions”) out of the box. You can wrap any C# method (with optional parameter descriptions) and register it as a tool for an agent. When the LLM chooses to call it, the framework handles the invocation, error handling, and integration of the returned output. This drastically simplifies integration of custom logic or external APIs into your agent prompts. You don’t have to parse JSON blobs or write orchestration plumbing yourself. ### 3. Concurrency, Interruption, and Scheduling Without a framework, you’d likely write `Task.Run`, `CancellationToken`s, and custom queues to manage parallel execution. But ensuring that one long-running operation (like summarization or answering a question) doesn’t block audio capture is error-prone. You’d also need to build your own scheduling logic or priority queuing to ensure urgent tasks (like answering a question) jump ahead, while background tasks (summary) can yield or skip partial results if overloaded. Agent Framework gives you **agent threads**, channels, and priority scheduling out of the box. You can run agents concurrently in separate execution contexts (threads or tasks) and route messages between them safely via channels, with built-in support for preemption or priority handling. The framework’s runtime ensures your audio transcription isn’t starved, while letting summarization and Q&A run in lockstep. ### 4. Fault Tolerance, Serialization & Durability In a non-framework version, an agent failure (e.g. a transient API error) could crash your entire app or leave your system in a half-baked state. Restarting mid-session means losing memory, losing intermediate state, and often manual recovery logic. Agent Framework provides **thread serialization and rehydration**: you can serialize an `AgentThread` (and associated state) to JSON or durable storage, then deserialize it later to resume. This lets your multi-agent system survive restarts, scale-out, or transient faults. You don’t have to rewire every stateful component yourself. ## Beyond Parallelism: a Full Orchestration Layer for Real-Time, Multi-Agent Apps **Microsoft Agent Framework (MAF)** isn’t just “run a few tasks in parallel.” It’s a complete runtime and SDK that unifies ideas from AutoGen and Semantic Kernel to build durable, observable, multi-agent systems in .NET and Python, with open standards for integration. ### Built-in concurrent orchestration (without DIY plumbing) MAF’s orchestration model lets agents and workflow steps branch and run **concurrently** while the runtime manages scheduling, back-pressure, and safe message passing—crucial for cases like your Meeting Copilot where transcription must never block while key-pointing and Q&A run alongside. In other stacks (e.g., vanilla LangChain), you typically hand-roll concurrency, queues, and cancellation. MAF bakes this into its workflow/agent execution model, so you can focus on the agent logic instead of thread choreography. ### Agents as first-class tools (MCP) and cross-agent interoperability Agents can **consume** tools (built-in or custom) and can also be **exposed as tools** to other agents via open protocols—most notably **MCP (Model Context Protocol)**—plus **Agent-to-Agent (A2A)** messaging for cross-runtime collaboration. That means your real-time transcription agent can be surfaced as a callable capability inside a planning agent, or plugged into a broader agent mesh without glue code. ### Agent Middleware for policy, logging, and safety MAF includes a **middleware pipeline** (think ASP.NET for agents) so you can intercept runs, tool invocations, and LLM calls to add logging, redaction, rate limits, approvals, or safety checks—uniformly across all agents. This tackles cross-cutting concerns systematically rather than scattering ad-hoc callbacks through prompts. (See the user guide’s emphasis on developer-grade configuration and interception points.) ### Multi-turn conversation state with AgentThreads Agents are stateless by design, but **AgentThreads** carry conversation history and context across turns, and can be **serialized/rehydrated** for long-running sessions. In a live meeting, your Q&A agent can pause/resume with full context, while the transcription agent streams continuously—no custom state machine required. ### Memory and function tools—first-class, not afterthoughts MAF treats **memory** as a pluggable concern (short- and long-term) via context providers and stores; you can persist chat history or inject distilled summaries without bespoke plumbing. Likewise, **function tools** (AIFunction/AITool) make external APIs or your own methods discoverable and callable by the agent—MAF handles argument binding, invocation, and result hand-off. This is how your Q&A agent can safely call search, line-of-business APIs, or local utilities in real time. ### Open source, model-agnostic, and portable MAF is **open-source** and provider-flexible: swap Azure OpenAI/OpenAI for local or third-party models, and compose agents and tools via MCP/A2A without vendor lock-in. This keeps your Meeting Copilot adaptable—e.g., prototype with cloud models, then run with local backends when needed. ### Enterprise-grade integrations—when (and if) you want them Because MAF is the **unified foundation** for Microsoft’s agent stack, the same agents can plug into **Azure AI Foundry Agent Service** (identity, networking, content safety, approvals, observability) or be packaged for **Copilot** surfaces—_without_ rewriting core logic. But you can also host agents anywhere (containers/on-prem/other clouds) and still keep the same abstractions. ### Observability that’s native, not bolted on Tracing, metrics, and logs are first-class—wired to OpenTelemetry and visualized in Azure AI Foundry—so you can watch every agent step, tool call, latency, and cost across a multi-agent run (akin to LangSmith, but **built-in** to the ecosystem). This is invaluable when debugging “why didn’t the Q&A agent answer that question?” during a live session. ### Extensibility, and Developer Experience MAF’s **pluggable architecture** makes swaps routine: choose your vector store (Redis, Postgres/pgvector, Pinecone, etc.), register new tools from OpenAPI, or wrap existing agents as callable functions—all with consistent .NET APIs (`Microsoft.Extensions.AI`) and documentation that favors clear, production-ready patterns. The result: less scaffolding, more shipping. _How this maps to Meeting Copilot:_ the **Transcription agent** streams audio with zero interruption, **Key-Point agent** batches transcripts and emits deduped insights, and **Q&A agent** detects and answers questions—each on its own thread, exchanging messages via channels. Memory and function tools provide context and actions; middleware enforces hygiene; observability tells you exactly what happened and when. That’s the difference between a fragile prototype and a reliable, live meeting assistant. ## Workflows: Orchestrating AI Agents with Structured Flows Another cool feature In the Microsoft Agent Framework (MAF), is workflow. A **workflow** is a typed, graph-based orchestration that wires together agents, tools, and "regular code" into reliable multi-step jobs. It adds structure, observability, and deterministic control (including **type-based routing**, nesting, checkpointing, and human-in-the-loop request/response) so you’re not hand-rolling queues and threads for every scenario. ### Core concepts (4 quick pieces) - **Executors** – fundamental building blocks that process messages in a workflow. They are autonomous processing units that receive typed messages, perform operations, and can produce output messages or events. - **Edges** – define how messages flow between executors with optional conditions. They represent the connections in the workflow graph and determine the data flow paths. there are different types of edges similar to a traditional flow-chart: 1. **Direct Edges**: Simple one-to-one connections between executors 2. **Conditional Edges**: Edges with conditions that determine when messages should flow 3. **Fan-out Edges**: One executor sending messages to multiple targets 4. **Fan-in Edges**: Multiple executors sending messages to a single target - **Workflows** – ties everything together and manages execution. It's the orchestrator that coordinates executor execution, message routing, and event streaming. - **Events** – runtime signals for tracing and side-effects (start/complete, errors, etc.). ### Built-in orchestration patterns - **Sequential pipeline** — A → B → C; each step enriches the last (great for staged enrichment). - **Concurrent / fan-out–fan-in** — run steps/agents in parallel, then aggregate results (ideal for speed or ensembles). - **Manager/worker (“Magentic”)** — a coordinator dynamically delegates to specialized agents for open-ended tasks. - **Request/response (HITL)** — pause for approvals or human input mid-flow, then continue. ### Tiny example (how it feels in C#) ```cs // Two agents, chained in a tiny workflow var writer = new ChatClientAgent(chatClient, writerPrompt); var reviewer = new ChatClientAgent(chatClient, reviewerPrompt); var wf = new WorkflowBuilder(writer) .AddEdge(writer, reviewer) // direct edge: writer → reviewer .Build<string>(); // type-safe message flow ``` You can also flip it around and **wrap a whole workflow as an Agent** to plug into other agent systems. You can fine a full example at Microsoft learn for [Create a Workflow with Branching Logic](https://learn.microsoft.com/en-us/agent-framework/tutorials/workflows/workflow-with-branching-logic?pivots=programming-language-csharp) Overall, MAF’s workflow layer gives you a **composable, observable, and type-safe** way to mix existing agents and new steps—then orchestrate them with well-defined patterns. It turns complex, real-time, multi-agent apps from DIY concurrency puzzles into clean, testable flows you can reason about and ship. ## **Conclusion** The Microsoft Agent Framework represents a significant step forward in enabling **real-world multi-agent AI applications**. For .NET developers and AI enthusiasts, it offers a compelling mix of simplicity and power: you get the ease of high-level abstractions (no need to manage threads or hand-craft orchestrations from scratch) along with the robustness of a production-ready framework (enterprise integration, safety, and support for your favorite tools and models). Whether you’re prototyping a voice-enabled assistant like our Meeting Copilot, or building a complex workflow of analytical agents for your business, the Agent Framework can help you **stay “in flow” and focus on the logic** rather than the plumbing . By combining the lessons of Semantic Kernel and AutoGen, it truly gives developers the best of both worlds – the innovation of cutting-edge AI research and the stability of proven software practices – in one unified package. Even for python developers coming from legacy AI frameworks such as Lang-chain, this is fresh change that embraces new paradigm of modern Multi-agent workflow based that is compatible with most today's standard protocols and tools such as MCP or A2A and OpenAPI. If you’ve been dreaming of creating your own AI copilots or autonomous agents, now is a great time to dive in. The framework is still in public preview (and welcoming feedback), which means you can influence its direction while benefiting from what’s already there. In fact I have created a [pull request](https://github.com/microsoft/agent-framework/pull/1170) for this very example I am writing up a blog which should be merged soon. And as the Meeting Copilot example demonstrates, **previously daunting projects become achievable** with the right framework support. No doubt, we’re going to see a new wave of multi-agent AI applications built on this foundation. With Microsoft Agent Framework, a lot of the hard parts of orchestration are handled for you, so you can spend your time building the **intelligent behavior** and let the framework worry about the rest. **Sources:** - [Microsoft Agent Framework Overview](https://aka.ms/agentframework/docs) - [Microsoft Azure AI Foundry Blog – _Introducing Microsoft Agent Framework_](https://devblogs.microsoft.com/foundry/introducing-microsoft-agent-framework-the-open-source-engine-for-agentic-ai-apps) - [_Microsoft Agent Framework: Combining Semantic Kernel + Autogen_ (Dev Community)](https://dev.to/sreeni5018/microsoft-agent-framework-combining-semantic-kernel-autogen-for-advanced-ai-agents-2i4i) - [.NET Blog – _Introducing Microsoft Agent Framework_](https://devblogs.microsoft.com/dotnet/introducing-microsoft-agent-framework-preview)