Microsoft Agent Framework — Semantic Kernel Meets AutoGen in One SDK

What Happened to Semantic Kernel and AutoGen?

Two years of parallel development, two separate GitHub repos with a combined 50,000+ stars, two different programming models, and one increasingly confused developer community. That was the situation Microsoft found itself in by late 2025. Semantic Kernel (launched mid-2023) had become the go-to SDK for .NET shops building LLM-powered enterprise applications — plugin systems, prompt templates, memory stores, the works. AutoGen (released as a research project from Microsoft Research) took a different path: multi-agent conversations where AI agents negotiate, debate, and collaborate autonomously.

The problem was overlap. Both projects added agent capabilities. Both added tool calling. Both started supporting MCP. Developers kept asking: “Which one should I use?” Microsoft's answer for months was a vague “it depends on your use case,” which satisfied nobody.

Agent Framework 1.0, released April 7, 2026, is Microsoft's actual answer. Semantic Kernel becomes the foundation layer — its kernel, plugin model, and connector system survive intact. AutoGen's multi-agent orchestration concepts get rebuilt on top of that foundation as the graph-based workflow engine. The AutoGen name lives on as a compatibility layer, but new development happens in the unified repo at github.com/microsoft/agent-framework.

The unification is not cosmetic. The API surface changed. Import paths changed. The multi-agent programming model shifted from AutoGen's conversation-centric design (where agents talk to each other in chat threads) to a graph-based model (where agents are nodes in a directed graph with explicit transitions). If you have AutoGen code in production, migration requires real work. Semantic Kernel migration is gentler — most existing plugins and connectors port directly.

How Is the Agent Framework Architected?

The architecture has four layers, and understanding them saves you from the “where does this go?” confusion that plagued the two-project era.

Layer 1: The Kernel

Straight from Semantic Kernel. The kernel manages LLM connections, plugin registration, prompt templates, and memory. If you have written Semantic Kernel code, this layer is identical. You create a kernel, register your Azure OpenAI or OpenAI connector, add plugins (tool definitions), and the kernel handles serialization, token counting, and retry logic.

Layer 2: Agents

An agent wraps a kernel with identity, instructions, and state. Each agent has a system prompt, a set of available tools (plugins), and a conversation history. The framework ships with three built-in agent types: ChatCompletionAgent (single-turn tool-calling agent), OpenAIAssistantAgent (wraps the OpenAI Assistants API), and AzureAIAgent (Azure AI Foundry integration). You can subclass Agent to build custom types.

Layer 3: Orchestration

This is the new part. The orchestration layer defines how multiple agents collaborate. You build a directed graph where each node is an agent or a decision function, and edges define transitions. The framework executes the graph, passing messages between agents, managing shared state, and handling failures. Think of it as a state machine where each state happens to be an AI agent.

Three orchestration patterns ship out of the box: sequential (agents run in order), fan-out/fan-in (parallel execution with result aggregation), and handoff (one agent decides which agent runs next based on the conversation). You can compose these patterns, so a fan-out step can contain sequential sub-chains.

Layer 4: Infrastructure

Session management, middleware, telemetry. Sessions persist conversation state across requests — essential for multi-turn applications where a user interacts with an agent over minutes or hours. The middleware pipeline lets you inject logging, authentication, rate limiting, or custom logic at every step. Telemetry exports traces in OpenTelemetry format, which means your existing Datadog/Grafana/Azure Monitor setup can visualize agent execution without custom instrumentation.

According to Microsoft's announcement, over 12,000 organizations were already using Semantic Kernel in production before the merge, and the framework handles more than 1 billion AI interactions monthly across Azure services. That production track record is the main reason Microsoft committed to LTS for the 1.0 APIs — breaking changes would cascade across too many enterprise deployments.

How Do MCP and A2A 1.0 Work Together?

MCP (Model Context Protocol) and A2A (Agent-to-Agent) solve different problems, and the framework uses both simultaneously. MCP connects agents to tools. A2A connects agents to other agents. The distinction matters because they operate at different levels.

MCP: Tool Discovery and Invocation

When you configure an MCP server for your agent, the framework queries the server for available tools at startup. The agent's tool list gets populated automatically — no manual tool definitions needed. During execution, when the LLM decides to call a tool, the framework routes the call to the appropriate MCP server, handles serialization, and feeds the result back to the LLM.

This is the same MCP protocol that Claude Code uses natively. The practical benefit: any MCP server you or the community builds works with both tools. PostgreSQL MCP server, GitHub MCP server, Slack MCP server — they all plug in without framework-specific adapters. The ecosystem already has around 200 community-built MCP servers, and that number roughly doubles every quarter.

A2A 1.0: Cross-Framework Agent Collaboration

A2A is newer and more ambitious. The protocol defines how agents built with different frameworks — or different companies — discover each other, negotiate capabilities, and exchange messages. Every A2A-compatible agent publishes an Agent Card (a JSON metadata file describing what the agent can do, what inputs it accepts, and where to reach it). Client agents read these cards to decide which remote agents to involve.

In practice: you could have a research agent built with Microsoft Agent Framework, a code-writing agent built with LangGraph, and a deployment agent built as a custom service. Through A2A, the research agent sends findings to the code agent, which sends code to the deployment agent, all without any of them sharing a codebase or framework.

Google co-developed A2A with Microsoft, which is notable because it means the protocol is not a Microsoft-only standard. The specification is open, and early implementations exist for LangChain, CrewAI, and several smaller frameworks. Whether A2A gains the same adoption as MCP remains an open question — MCP had Anthropic pushing it aggressively with Claude, while A2A lacks a single killer application driving adoption. But the cross-framework interop promise is real, and it removes the most painful part of multi-vendor agent deployments: the custom glue code between systems.

What Are Graph-Based Multi-Agent Workflows?

The biggest conceptual shift from AutoGen to Agent Framework is how you define agent collaboration. AutoGen used a conversation model — you put agents in a group chat, gave them roles, and they figured out turn-taking and task allocation through conversation. It felt natural for demos but became unpredictable in production. An agent might dominate the conversation, two agents might argue in circles, or the group would converge on a suboptimal solution because one agent was more verbose.

Agent Framework replaces this with directed graphs. You explicitly define which agent runs when, what data passes between them, and what conditions trigger transitions. A simple example:

# Python — defining a 3-agent research pipeline
from agent_framework import AgentGraph, ChatCompletionAgent

researcher = ChatCompletionAgent(
    name="Researcher",
    instructions="Find relevant papers and data on the topic.",
    kernel=kernel,
)
writer = ChatCompletionAgent(
    name="Writer",
    instructions="Synthesize research into a coherent report.",
    kernel=kernel,
)
reviewer = ChatCompletionAgent(
    name="Reviewer",
    instructions="Check factual accuracy and flag unsupported claims.",
    kernel=kernel,
)

graph = AgentGraph()
graph.add_edge(researcher, writer)
graph.add_edge(writer, reviewer)
graph.add_conditional_edge(
    reviewer,
    lambda result: researcher if "needs_revision" in result else None
)

result = await graph.run("Analyze the impact of MCP adoption in 2026")

The graph model has clear advantages for production systems. You can reason about execution order, add timeouts to individual nodes, implement retry logic for specific agents, and visualize the entire workflow before running it. The DevUI debugger (covered in the next section) renders these graphs visually, which makes debugging multi-agent systems dramatically easier than reading conversation logs.

The tradeoff: graphs are more rigid than conversations. If your use case genuinely benefits from emergent agent behavior — agents discovering unexpected collaboration patterns — the graph model constrains that. For the roughly 90% of enterprise use cases where predictability matters more than emergence, the tradeoff is clearly worth it. For research and experimentation, you might miss AutoGen's conversational flexibility.

Does the DevUI Debugger Actually Help?

Short answer: yes, and it addresses a problem that every other agent framework handles poorly.

Debugging multi-agent systems typically means reading interleaved log lines, trying to reconstruct which agent did what, when, and why. If agent A called a tool that returned an error, and agent B made a decision based on that error being in the shared context, you need to trace backward through logs to understand the chain. With three or four agents, this becomes genuinely painful.

DevUI is a browser-based tool that runs alongside your agent application. It renders the agent graph visually, highlights the currently executing node, and shows the full message history for each agent in a split-pane view. You can click on any agent to see its system prompt, tool calls, LLM responses, and state at that point in execution. Tool calls show both the request and response, with timing data.

The most useful feature: you can replay executions. DevUI records every step, and you can scrub backward and forward through the timeline to see how state changed. This is the kind of debugging experience that LangSmith (LangChain's observability tool) tries to provide through log analysis, but DevUI's graph-native approach makes the relationships between agents and state changes much clearer.

Limitations: DevUI is for development only. It adds latency (around 15-30ms per step for the recording), and Microsoft explicitly warns against running it in production. For production observability, you use the OpenTelemetry integration, which is lighter but gives you less visual detail. The gap between dev-time and prod-time debugging tools is not great — a bug that only manifests in production under load will not be reproducible in DevUI.

How Does It Compare to Claude Agent SDK, LangGraph, and CrewAI?

Agent frameworks are proliferating, and picking one means committing to a programming model that is hard to switch later. Here is how Microsoft Agent Framework stacks up against three alternatives that target overlapping use cases.

Microsoft Agent Framework vs Claude Agent SDK

Different philosophies. Claude Agent SDK is optimized for one model family (Claude) and gives you deeply integrated tool use, managed agents, and server-side sessions with minimal configuration. Microsoft Agent Framework is model-agnostic and gives you more architectural control, but you pay for it in setup complexity. If you are building on Claude and want to ship fast, the Claude Agent SDK is simpler. If you need Azure OpenAI integration, multi-model support, or .NET, Microsoft's framework is the obvious choice.

For a practical look at what Claude's agent capabilities look like in production, our Claude Code skills ranked guide covers real-world automation patterns.

Microsoft Agent Framework vs LangGraph

The closest competitor architecturally. Both use graph-based orchestration. Both support state management and checkpointing. LangGraph benefits from LangChain's massive model integration library — connecting to niche or self-hosted models is easier. Microsoft Agent Framework has stronger enterprise infrastructure: Azure-native deployment, built-in DevUI vs LangSmith (which costs $39+/month for teams), and first-class .NET support. LangGraph's state management is more flexible (arbitrary state dictionaries); Microsoft's is more structured (session-based with typed schemas). Both have steep learning curves, and switching between them after building production workflows is painful.

Microsoft Agent Framework vs CrewAI

CrewAI is the easiest to start with. Define agents as “roles” with backstories, give them tasks, and CrewAI handles orchestration. For prototyping and simple pipelines, CrewAI gets you to a working demo in under an hour. The tradeoff: CrewAI's role-based abstraction hides the execution model, making debugging harder as complexity grows. Microsoft's graph model is more verbose but gives you explicit control over every transition. CrewAI is Python-only; if you need .NET, it is not an option.

Should You Migrate from Semantic Kernel or AutoGen?

From Semantic Kernel

The migration path is well-documented and manageable. The kernel, plugin model, and connector system are structurally the same. You update import paths (from semantic_kernel to agent_framework), replace deprecated class names, and adapt to the new agent abstraction. Microsoft estimates 2-4 hours for a typical application with 5-10 plugins. If you use custom prompt templates, those need minor syntax updates.

The one gotcha: if you relied on Semantic Kernel's experimental agent features (the AgentGroupChat class from the preview packages), those were replaced by the graph orchestration model. That specific migration requires rethinking your agent collaboration design, not just changing import paths.

From AutoGen

Harder. AutoGen's conversation-centric model (agents in a group chat, implicit turn-taking) has no direct equivalent. You need to redesign your agent interactions as explicit graph transitions. For simple two-agent setups (e.g., a coder and a reviewer), the translation is straightforward. For complex multi-agent conversations with dynamic role assignment, you are essentially rebuilding the collaboration logic.

Microsoft's migration guide acknowledges this and provides an autogen_compat module that emulates AutoGen's GroupChat pattern on top of the graph engine. It works for getting existing code running, but the compatibility layer adds overhead and will eventually be deprecated. Plan to migrate to native graphs within 6-12 months.

Starting fresh

If you are evaluating agent frameworks for a new project, start with Agent Framework directly. The LTS commitment means your investment in learning the APIs will pay off over years, not months. Microsoft is clearly consolidating here — Semantic Kernel and AutoGen will get maintenance updates but no new features.

What Are the Real Limitations?

I want to be straightforward about what does not work well, because Microsoft's announcement blog post naturally emphasizes the positives.

• ✕ Python and .NET only — no Java, Go, Rust, or TypeScript. This is the biggest limitation for many teams. Java is still the dominant language in enterprise backends. Go powers most cloud-native infrastructure. TypeScript is the default for web applications. Microsoft says “more languages are planned” but provides no timeline. If your team writes Java, you are stuck with LangChain4j or building custom abstractions.
• ✕ Documentation has gaps from the merge. Some pages reference Semantic Kernel concepts without explaining them in the Agent Framework context. Code samples occasionally use old import paths. The API reference is auto-generated and sometimes lacks usage examples. This will improve over weeks, but right now, you will hit moments where you need to read source code instead of docs.
• ✕ The 4-layer architecture adds boilerplate for simple use cases. If you just want one agent with a few tools, you still need to create a kernel, configure a connector, instantiate an agent, and set up a graph (even a single-node graph). CrewAI or Claude Agent SDK let you do this in about 15 lines; Agent Framework takes around 40-50. The extra layers pay off in complex systems, but they are tax on simple ones.
• ✕ Azure-centric defaults. The framework works with any OpenAI-compatible endpoint, but the first-party experience is clearly optimized for Azure OpenAI. Examples default to Azure. The deployment guidance assumes Azure. The AzureAIAgent type has features (like file search and code interpreter) that do not exist in the vanilla ChatCompletionAgent. If you run on AWS or GCP, the framework works, but you miss some integrations.
• ✕ A2A adoption is still nascent. The protocol is well-designed, but finding A2A-compatible agents to actually collaborate with is hard right now. The ecosystem needs a year or two to mature. In the meantime, A2A is mostly useful for connecting your own agents across services, not for discovering and using third-party agents.

None of these kill the framework for its target audience. But if you read the launch blog and imagined a smooth, all-languages, all-clouds experience, the reality is narrower. It is an excellent Python/.NET SDK with strong Azure integration. Everything beyond that is aspirational, not shipped.

Who Should Use Microsoft Agent Framework?

After three days of building with it — a research pipeline, a customer support agent with tool use, and a multi-agent code review system — I think the framework fits three profiles well and two poorly.

Strong fit:

• ✓ .NET shops already on Azure. This is where the framework shines brightest. If your team writes C# and deploys to Azure, Agent Framework is the native choice with the least friction. The AzureAIAgent type gives you file search, code interpreter, and managed deployment that no other framework matches for the Microsoft stack.
• ✓ Teams building multi-agent production systems. If you need more than one agent collaborating with predictable execution patterns, the graph model and DevUI debugger are the strongest combo available. LangGraph is the main competitor here, but DevUI is a meaningful advantage over LangSmith for development-time debugging.
• ✓ Organizations that need cross-framework agent communication. If you are running agents built with different frameworks across different teams, A2A is the most complete interop protocol available today. Getting ahead of A2A adoption now means smoother integration later as the ecosystem grows.

Not a great fit:

• ✕ Solo developers building simple agents quickly. The setup overhead is real. If you want a single-agent chatbot with a few tools, CrewAI or Claude Agent SDK will get you there in a fraction of the time.
• ✕ Java or TypeScript teams without Python/.NET experience. The language gap is not trivial. Wrapping Agent Framework in a REST API and calling it from Java is possible but adds latency and complexity.

For broader context on how agent frameworks fit into the AI coding tool ecosystem, our AI coding tools comparison guide covers dozens of options across different use cases. And if you are specifically interested in how agent capabilities play out in terminal-based coding assistants, our Hermes Agent review examines a different approach to agent orchestration.

Getting Started: First Agent in 15 Minutes

The fastest path to a working agent:

# Install
pip install microsoft-agent-framework

# Or for .NET
dotnet add package Microsoft.AgentFramework --version 1.0.0

# Python — minimal working agent
import asyncio
from agent_framework import Kernel, ChatCompletionAgent
from agent_framework.connectors.openai import OpenAIChatCompletion

kernel = Kernel()
kernel.add_service(OpenAIChatCompletion(
    model_id="gpt-4o",
    api_key="your-api-key",
))

agent = ChatCompletionAgent(
    name="Assistant",
    instructions="You are a helpful coding assistant.",
    kernel=kernel,
)

async def main():
    response = await agent.invoke("Explain Python generators in 3 sentences.")
    print(response)

asyncio.run(main())

That gets you a single agent. To add tool use, define a plugin:

from agent_framework import kernel_function

class FileTools:
    @kernel_function(description="Read a file from disk")
    def read_file(self, path: str) -> str:
        with open(path, "r") as f:
            return f.read()

    @kernel_function(description="Write content to a file")
    def write_file(self, path: str, content: str) -> str:
        with open(path, "w") as f:
            f.write(content)
        return f"Written {len(content)} chars to {path}"

kernel.add_plugin(FileTools(), plugin_name="files")

To connect an MCP server:

from agent_framework.mcp import MCPClient

# Connect to a running MCP server
mcp_client = MCPClient("http://localhost:3000/mcp")
tools = await mcp_client.list_tools()
kernel.add_mcp_tools(tools)

And to launch DevUI for debugging:

# Start DevUI alongside your agent
agent-framework devui --port 8080

# Then open http://localhost:8080 in your browser

The DevUI will show your agent graph, message flow, and tool calls in real time. For more complete examples, the GitHub repo includes sample applications for customer support, research pipelines, and multi-agent code review.

FAQ