Microsoft Agent Framework 1.0: Multi-Agent Orchestration with MCP and A2A for Platform Engineers

Q: Is Microsoft Agent Framework the same as Semantic Kernel or AutoGen?

No. Agent Framework 1.0 is the production successor that unifies both. It combines AutoGen's multi-agent orchestration patterns with Semantic Kernel's enterprise features. Microsoft provides migration guides for teams transitioning from either SDK.

Q: What is the difference between MCP and A2A in Agent Framework?

MCP handles agent-to-tool communication - agents discover and invoke external tools. A2A handles agent-to-agent communication - agents discover and collaborate with other agents across frameworks. MCP gives your agent tools; A2A gives your agent collaborators.

Q: Is the Magentic-One orchestration pattern available in .NET?

Not yet. As of Agent Framework 1.0/1.1.0, Magentic orchestration is Python-only. The other four patterns (sequential, concurrent, handoff, group chat) are available in both .NET and Python.

Microsoft Agent Framework 1.0 is Microsoft’s production-ready SDK for building multi-agent AI systems, unifying Semantic Kernel and AutoGen with native MCP and A2A protocol support.

The 1.0 GA shipped April 2, 2026 - SDK packages Microsoft.Agents.AI v1.0.0 for .NET and agent-framework v1.0.0 for Python. The announcement blog followed April 3. If you build AI agent infrastructure and haven’t looked at it yet, this post covers what you actually need to know: which orchestration pattern fits your use case, how MCP and A2A work under the hood, and what production deployment looks like.

What Is Microsoft Agent Framework 1.0?

The Semantic Kernel + AutoGen Unification

Agent Framework is positioned as the production successor to both Semantic Kernel and AutoGen. Per the official overview: “Agent Framework is the direct successor, created by the same teams. It combines AutoGen’s simple abstractions for single- and multi-agent patterns with Semantic Kernel’s enterprise-grade features such as session-based state management, type safety, filters, telemetry, and extensive model and embedding support.”

Microsoft provides migration guides for both SDKs. The release blog is direct: “Now is the time to migrate to Microsoft Agent Framework.”

First-party model connectors ship for Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini, and Ollama. All implement IChatClient (.NET) or a common client interface (Python), so provider switching doesn’t require code changes.

Latest stable versions as of April 15, 2026: Python 1.0.1 and .NET 1.1.0, both released April 10.

SDK Quick Start

Getting an agent running takes about 10 lines.

Python:

pip install agent-framework

from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential

client = FoundryChatClient(
    project_endpoint="https://your-foundry-service.services.ai.azure.com/api/projects/your-project",
    model="gpt-5.4-mini",
    credential=AzureCliCredential(),
)

agent = client.as_agent(
    name="HelloAgent",
    instructions="You are a friendly assistant. Keep your answers brief.",
)

result = await agent.run("What is the largest city in France?")
print(f"Agent: {result}")

.NET:

dotnet add package Microsoft.Agents.AI.Foundry --prerelease

using Azure.AI.Projects;
using Azure.Identity;
using Microsoft.Agents.AI;

AIAgent agent = new AIProjectClient(
        new Uri("https://your-foundry-service.services.ai.azure.com/api/projects/your-project"),
        new AzureCliCredential())
    .AsAIAgent(
        model: "gpt-5.4-mini",
        instructions: "You are a friendly assistant. Keep your answers brief.");

Console.WriteLine(await agent.RunAsync("What is the largest city in France?"));

From here you connect tools, build sessions, add middleware, and compose workflows.

Which Orchestration Pattern Should You Use in Microsoft Agent Framework?

Agent Framework ships five multi-agent orchestration patterns as stable. All support streaming, checkpointing, human-in-the-loop approvals, and pause/resume. The question most teams run into isn’t “does this work?” - it’s “which one do I need?”

Pattern	Best For	Key Behavior
Sequential	Document review pipelines, data ETL with agent stages	Agents execute one after another in defined order
Concurrent	Brainstorming, ensemble reasoning, parallel fact-gathering	Agents execute in parallel; results aggregated
Handoff	Customer support routing, expert delegation	Agents transfer control based on context
Group Chat	Collaborative problem-solving with multiple specialists	Manager controls speaker selection
Magentic-One	Open-ended tasks where the solution path isn’t known upfront	Manager plans, tracks progress, auto-replans on stalls

Use this decision flowchart to pick the right pattern:

flowchart TD
    A[New multi-agent task] --> B{Execution order fixed\nand known upfront?}
    B -->|Yes| C{Steps run sequentially\nor in parallel?}
    C -->|Sequentially| D[Sequential orchestration]
    C -->|In parallel| E[Concurrent orchestration]
    B -->|No| F{Do agents need to\ntransfer control dynamically?}
    F -->|Yes - one-at-a-time routing| G[Handoff orchestration]
    F -->|Yes - collaborative discussion| H[Group Chat orchestration]
    F -->|Solution path unknown,\nneed planning and replanning| I[Magentic-One\nPython only]

Fixed-order tasks go left toward Sequential or Concurrent. Dynamic delegation goes right toward Handoff, Group Chat, or Magentic-One.

Magentic-One: Autonomous Planning and Coordination

Magentic-One is the pattern for complex, open-ended tasks. A dedicated manager agent creates a plan, optionally pauses for human review, selects specialized agents dynamically, tracks progress, and auto-replans when stalled (max_stall_count) or resets the workflow (max_reset_count).

Important: Magentic-One is currently Python-only - not supported in C#. The other four patterns are available in both runtimes.

from agent_framework.orchestrations import MagenticBuilder

workflow = MagenticBuilder(
    participants=[researcher_agent, coder_agent],
    intermediate_outputs=True,
    manager_agent=manager_agent,
    enable_plan_review=True,        # Human reviews plan before execution
    max_round_count=10,
    max_stall_count=3,
    max_reset_count=2,
).build()

async for event in workflow.run(task, stream=True):
    if event.type == "request_info" and event.request_type is MagenticPlanReviewRequest:
        # Human reviews proposed plan and approves or provides revision feedback
        ...

The official Magentic docs note: “it is untested how well the Magentic orchestration will perform outside of the original Magentic-One design.” For well-understood workflows with known steps, Sequential or Handoff will behave more predictably in production.

How Does MCP Integration Work in Microsoft Agent Framework 1.0?

MCP (Model Context Protocol) is how agents discover and invoke external tools. Agent Framework treats MCP as a first-class integration. The same community MCP servers that work with Claude Code and VS Code Copilot work here without modification.

Three Transport Types

Python supports three transports:

Transport	Class	Use Case
stdio	`MCPStdioTool`	Local MCP servers - calculators, filesystem, SQLite
HTTP/SSE	`MCPStreamableHTTPTool`	Remote MCP servers, cloud-hosted tools
WebSocket	`MCPWebsocketTool`	Real-time data, streaming connections

.NET uses McpClientFactory.CreateAsync with StdioClientTransport from the official MCP C# SDK. Tools are retrieved via ListToolsAsync() and cast to AITool objects.

Connecting to an MCP Server (Python)

from agent_framework import Agent, MCPStdioTool
from agent_framework.openai import OpenAIChatClient

async with (
    MCPStdioTool(
        name="calculator",
        command="uvx",
        args=["mcp-server-calculator"]
    ) as mcp_server,
    Agent(
        client=OpenAIChatClient(),
        name="MathAgent",
        instructions="You are a helpful math assistant.",
    ) as agent,
):
    result = await agent.run("What is 15 * 23 + 45?", tools=mcp_server)
    print(result)

Exposing an Agent as an MCP Server

Agents can be published as MCP servers, making them callable from Claude Code, VS Code Copilot, or any MCP-compliant client:

Python: agent.as_mcp_server() wraps any agent as an MCP endpoint
.NET: McpServerTool.Create(agent.AsAIFunction()) registers an agent as an MCP tool

Authentication for Remote MCP Servers

For authenticated HTTP/SSE endpoints, use header_provider with function_invocation_kwargs. Credentials flow through runtime context rather than being baked into the client:

tools=MCPStreamableHTTPTool(
    name="secure-tool",
    url=mcp_server_url,
    header_provider=lambda kwargs: {"Authorization": f"Bearer {kwargs['mcp_api_key']}"},
),
# At run time:
result = await agent.run(query, function_invocation_kwargs={"mcp_api_key": api_key})

For .NET, pass credentials via tool_resources headers per-run so they’re scoped to the current invocation and not persisted.

How Does A2A Protocol Enable Cross-Framework Agent Communication?

A2A (Agent-to-Agent) is a distinct concern from MCP. MCP handles agent-to-tool communication. A2A handles agent-to-agent communication - structured messaging between agents that may run on different frameworks, different servers, or different clouds.

graph LR
    subgraph "Your Application"
        AF[Agent Framework Agent]
    end

    subgraph "MCP Layer - Tools"
        AF -->|MCPStdioTool| T1[GitHub MCP Server]
        AF -->|MCPStreamableHTTPTool| T2[Remote API MCP Server]
        AF -->|MCPWebsocketTool| T3[Realtime Data Server]
    end

    subgraph "A2A Layer - Collaborators"
        AF -->|A2A Protocol| R1[LangGraph Agent]
        AF -->|A2A Protocol| R2[CrewAI Agent]
        AF -->|A2A Protocol| R3[Other Agent Framework Agent]
    end

MCP gives your agent tools. A2A gives your agent collaborators. Both protocols compose in the same application.

A2A is governed by the Linux Foundation’s Agentic AI Foundation (AAIF), co-founded by OpenAI, Anthropic, Google, Microsoft, AWS, and Block. The protocol specification is at a2a-protocol.org.

Exposing an Agent via A2A (.NET)

var pirateAgent = builder.AddAIAgent("pirate", instructions: "You are a pirate. Speak like a pirate.");
app.MapA2A(pirateAgent, path: "/a2a/pirate", agentCard: new()
{
    Name = "Pirate Agent",
    Description = "An agent that speaks like a pirate.",
    Version = "1.0"
});

The agent publishes an AgentCard at /a2a/pirate/v1/card for discovery. Clients communicate using the A2A message format with contextId for conversation tracking. Multiple agents can be exposed on different paths from a single application - /a2a/math, /a2a/science, and so on.

Consuming an A2A Agent (Python)

from a2a.client import A2ACardResolver
from agent_framework.a2a import A2AAgent

# Discover agent capabilities via agent card
async with httpx.AsyncClient(timeout=60.0) as http_client:
    resolver = A2ACardResolver(httpx_client=http_client, base_url=a2a_host)
    agent_card = await resolver.get_agent_card()

# Connect and send a message
async with A2AAgent(name=agent_card.name, agent_card=agent_card, url=a2a_host) as agent:
    response = await agent.run("What are your capabilities?")
    for message in response.messages:
        print(message.text)

For long-running tasks, background=True returns a continuation token for polling. Streaming responses arrive via SSE. Authentication uses AuthInterceptor for secured endpoints.

What Production Features Does Microsoft Agent Framework 1.0 Include?

Checkpointing and Fault Recovery

Checkpoints capture full workflow state at the end of each “superstep” - after all executors in that step complete. Captured state includes all executor states, pending messages, pending requests/responses, and shared states.

Three storage backends are available for Python:

Backend	Package	Use Case
`InMemoryCheckpointStorage`	`agent-framework`	Tests, demos
`FileCheckpointStorage`	`agent-framework`	Local dev, single-machine
`CosmosCheckpointStorage`	`agent-framework-azure-cosmos`	Production, distributed, cross-process

Production pattern with Cosmos DB:

from azure.identity.aio import DefaultAzureCredential
from agent_framework import WorkflowBuilder
from agent_framework_azure_cosmos import CosmosCheckpointStorage

async with (
    DefaultAzureCredential() as credential,
    CosmosCheckpointStorage(
        endpoint="https://<account>.documents.azure.com:443/",
        credential=credential,
        database_name="agent-framework",
        container_name="workflow-checkpoints",
    ) as checkpoint_storage,
):
    builder = WorkflowBuilder(start_executor=start, checkpoint_storage=checkpoint_storage)
    builder.add_edge(start, executor_b)
    builder.add_edge(executor_b, end)
    workflow = builder.build()

    async for event in workflow.run(input, stream=True):
        ...

Here is how the checkpoint and resume flow works:

sequenceDiagram
    participant W as Workflow
    participant E as Executor
    participant CS as Checkpoint Storage

    W->>E: Execute Superstep 1
    E-->>W: Complete
    W->>CS: Save checkpoint (states + messages + requests)

    Note over W,CS: Process continues or crashes...

    W->>E: Execute Superstep 2
    E-->>W: Complete
    W->>CS: Save checkpoint

    Note over W: Failure or intentional pause

    W->>CS: Resume from checkpoint_id
    CS-->>W: Restore full state
    W->>E: Continue from last saved superstep

Checkpoints save at superstep boundaries. On failure or pause, the workflow resumes without replaying completed steps.

Storage security note: FileCheckpointStorage and CosmosCheckpointStorage use Python’s native binary serialization format (pickle) to handle non-JSON-native types like dataclasses and custom objects. Both use a restricted deserializer by default - only built-in safe types and agent_framework internal types are permitted. Custom types require explicit allowlisting via allowed_checkpoint_types. If your threat model requires avoiding binary deserialization entirely, use InMemoryCheckpointStorage or implement a custom CheckpointStorage with an alternative strategy.

For .NET, CheckpointManager.CreateInMemory() is included in the base package - no extra dependencies for in-memory checkpointing.

Resume on the same run: run.RestoreCheckpointAsync(checkpoint) (.NET) or workflow.run(checkpoint_id=id) (Python). Rehydration into a new run: InProcessExecution.ResumeStreamingAsync(newWorkflow, checkpoint, manager) (.NET) or pass checkpoint_storage to a fresh workflow.run() (Python).

Human-in-the-Loop Workflows

All five orchestration patterns support human-in-the-loop interactions through tool approval and request info. Magentic-One’s enable_plan_review=True (shown above) is one example. Sequential workflows support HITL tool approval at any step - the workflow pauses and waits for a human response before continuing.

Observability with OpenTelemetry

Agent Framework emits traces, logs, and metrics per the OpenTelemetry GenAI Semantic Conventions. Key spans generated:

invoke_agent <agent_name> - top-level span per agent invocation
chat <model_name> - LLM call with prompt and response attributes
execute_tool <function_name> - tool call with arguments and result

Key metrics:

gen_ai.client.operation.duration - operation duration (histogram)
gen_ai.client.token.usage - token usage per call (histogram)
agent_framework.function.invocation.duration - tool execution duration

Python configuration paths: environment variables (OTEL_EXPORTER_OTLP_ENDPOINT), Azure Monitor via FoundryChatClient.configure_azure_monitor(), Langfuse integration, or zero-code auto-instrumentation via opentelemetry-instrument.

.NET: builder pipeline with .UseOpenTelemetry(sourceName) and standard TracerProvider/MeterProvider. Aspire Dashboard works well for local dev.

Production warning: EnableSensitiveData / ENABLE_SENSITIVE_DATA logs prompt content. Disable in production to avoid exposing user data in traces.

Middleware Pipeline for Compliance

The middleware architecture intercepts and transforms agent behavior at every stage of execution. Content safety filters, audit logging, PII redaction, and compliance policies are all implemented as middleware without modifying prompts. This is the inherited Semantic Kernel “filters” pattern, generalized across agent and tool invocations.

How Do You Deploy Microsoft Agent Framework 1.0 in Production?

The Azure App Service deployment guide documents the standard pattern: agent instances on App Service, Service Bus for durable message queuing between agents, Cosmos DB for checkpoints and session state.

If you prototyped on a preview release, the RC-to-GA breaking changes to know:

thread parameter renamed to session
Agent instructions moved to the constructor
Microsoft.Extensions.AI upgraded to stable 10.4.1

For Kubernetes deployments, the key operational considerations:

Stateless agent pods: Agents are stateless when using Cosmos DB or Azure Cache for Redis for session storage. Horizontal scaling works without stickiness.
Checkpoint durability: Use CosmosCheckpointStorage - not FileCheckpointStorage - so checkpoints survive pod restarts and node failures.
MCP server lifecycle: Stdio-transport MCP servers (MCPStdioTool) spawn local subprocesses. In containerized environments, use HTTP/SSE transport (MCPStreamableHTTPTool) to MCP servers running as separate services instead.
A2A endpoints: Expose via Kubernetes Service and Ingress like any HTTP workload. The /v1/card endpoint serves agent discovery - make it reachable to any agents that need to call yours.

How Does Microsoft Agent Framework 1.0 Compare to LangGraph and CrewAI?

Capability	Agent Framework	LangGraph	CrewAI
Language	.NET + Python	Python	Python
Orchestration model	Workflow graph + 5 named patterns	Explicit DAG/graph	Role-based crew
State management	Session, checkpoints, context providers	Graph state	Crew-level memory
MCP support	Native (3 transports)	Community plugins	Community plugins
A2A support	Native (stable)	Via external adapter	Via external adapter
Checkpointing	InMemory / File / Cosmos DB	SQLite, Redis, Postgres	Limited
Human-in-the-loop	Built-in on all 5 patterns	Built-in	Built-in
Observability	Built-in OTel (GenAI conventions)	LangSmith, OTel	Limited
Production status	GA (1.0)	GA	GA

Comparison based on publicly available documentation as of April 2026. Check each project’s current docs for the latest.

Choose Agent Framework when: you need cross-language support (.NET plus Python), MCP and A2A as first-class protocol integrations, or Cosmos DB-backed checkpointing for distributed multi-agent workflows. The middleware pipeline is also a differentiator for compliance-heavy environments.

Choose LangGraph when: you need fine-grained control over graph topology and state transitions, or your team is already deep in the LangChain ecosystem.

Choose CrewAI when: you need role-based agent modeling with minimal infrastructure overhead and Python-only is acceptable.

Frequently Asked Questions

Is Microsoft Agent Framework the same as Semantic Kernel or AutoGen?

No. Agent Framework 1.0 is positioned as the production successor that unifies both. It combines AutoGen’s multi-agent orchestration patterns with Semantic Kernel’s enterprise features - session-based state management, middleware, telemetry, and type safety. Microsoft provides migration guides from Semantic Kernel and from AutoGen for teams transitioning from either SDK.

Does Microsoft Agent Framework support non-Microsoft LLM providers?

Yes. First-party connectors ship for Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini, and Ollama. All implement a common IChatClient abstraction in .NET (or equivalent in Python), so you can switch providers without changing application code.

Can I use the same MCP servers with Agent Framework that I use with Claude Code or VS Code Copilot?

Yes. Agent Framework’s MCP client connects to any MCP-compliant server. The same community MCP servers (GitHub, filesystem, SQLite) work without modification. Python supports three transports: stdio for local servers, HTTP/SSE for remote, and WebSocket for real-time connections. You can also expose your Agent Framework agent as an MCP server for other tools to consume.

What is the difference between MCP and A2A in Agent Framework?

MCP (Model Context Protocol) handles agent-to-tool communication - agents discover and invoke external tools via MCP servers. A2A (Agent-to-Agent) handles agent-to-agent communication - agents discover and collaborate with other agents across different frameworks using structured messaging over HTTP. MCP gives your agent tools; A2A gives your agent collaborators.

Is the Magentic-One orchestration pattern available in .NET?

Not yet. As of Agent Framework 1.0.0 / 1.1.0, the Magentic orchestration is Python-only. The other four patterns - sequential, concurrent, handoff, and group chat - are available in both .NET and Python. Check the official Magentic docs for updates on .NET support.