Microsoft shipped Microsoft Agent Framework 1.0 for .NET and Python, positioning it as a production-ready release with stable APIs and long-term support (Microsoft announcement). If you have been watching AutoGen and Semantic Kernel evolve in parallel, this is Microsoft putting a single “here is the successor” stake in the ground (Microsoft Learn overview).

What shipped in 1.0 (stable surface)

The 1.0 announcement describes a stabilized feature set that Microsoft says is battle-tested and committed to backward compatibility, including (Microsoft announcement):

  • Single agents and service connectors across .NET and Python
  • Middleware hooks
  • Agent memory and context providers
  • Agent workflows (graph-based engine)
  • Multi-agent orchestration patterns (sequential, concurrent, handoff, group chat, Magentic-One)
  • Declarative agents and workflows (YAML)
  • MCP support, plus A2A positioning (with “A2A 1.0 support coming soon”)

Why the “graph-based workflow” part is the real engineering upgrade

Agent Framework’s workflow engine is described as graph-based, meant to connect agents and functions into deterministic, repeatable processes. Microsoft explicitly calls out branching, parallel fan-out, and convergence, plus checkpointing and hydration for long-running runs that need to survive interruptions (Microsoft announcement).

Microsoft Learn summarizes workflows similarly: “graph-based workflows that connect agents and functions for multi-step tasks with type-safe routing, checkpointing, and human-in-the-loop support” (Microsoft Learn overview).

For practitioners, that “graph” word signals a shift away from treating an agent as an opaque loop:

  • You can test it: a workflow is explicit about what happens next, so you can unit test steps and integration-test paths.
  • You can resume it: checkpoints help when you have approval gates, flaky external dependencies, or long-running processes.
  • You can govern it: middleware + explicit step boundaries are a natural place for safety checks, audit logging, and policy enforcement.

If you have ever tried to debug a multi-agent system where failure looks like “the model decided not to call the tool”, this kind of explicit topology is the difference between “demo works” and “operations can own it”.

Interop: MCP now, A2A soon

Microsoft calls out “cross-runtime interoperability via A2A and MCP” in the 1.0 release post (Microsoft announcement).

MCP: tool discovery as a boundary

In Microsoft’s wording, MCP support lets agents discover and invoke external tools exposed by MCP-compliant servers (Microsoft announcement). The Learn overview also treats “MCP servers” as a first-class tool surface for agents (Microsoft Learn overview).

If you are building internal tools, MCP gives you a cleaner separation:

  • Tools live behind a protocol boundary
  • Your agent code can swap tool providers without rewriting “tool calling glue”

A2A: roadmap signal, not a stability claim (inference)

Microsoft says “A2A 1.0 support coming soon” in the 1.0 post (Microsoft announcement). That reads like a roadmap signal, not a guarantee of production compatibility today.

Inference (clearly labeled): If Microsoft lands a versioned A2A implementation, it can become the structured equivalent of “service-to-service” for agent-to-agent collaboration, particularly useful in mixed estates where some teams ship Python services and others ship .NET.

“Successor” is not subtle: AutoGen + Semantic Kernel consolidation

Microsoft Learn explicitly frames Agent Framework as “the next generation of both Semantic Kernel and AutoGen”, combining AutoGen’s abstractions with Semantic Kernel’s enterprise features and adding workflows for explicit multi-agent orchestration (Microsoft Learn overview).

The 1.0 announcement tells a similar story: unify the enterprise foundations of Semantic Kernel with the orchestration patterns from AutoGen into one open-source SDK, with a release-candidate period in February before the 1.0 cut (Microsoft announcement).

What’s new since October (preview features)

Microsoft labels several “preview” features as functional but still evolving based on feedback, including (Microsoft announcement):

  • DevUI (local, browser-based debugger for execution and tool calls)
  • Foundry hosted agent integration (managed services and Azure Durable Functions)
  • Foundry tools, memory, observability, evaluations dashboards
  • AG-UI and frontend adapters (CopilotKit, ChatKit)
  • Skills (reusable capability packages)
  • GitHub Copilot SDK and Claude Code SDK integrations
  • A customizable “agent harness” and local runtime for automation and coding-agent patterns

Treat these as promising, but version them like any other preview API.

Practical decision rules (quick)

Microsoft Learn offers a simple framing that holds up well in production planning (Microsoft Learn overview):

  • Use an agent when the task is open-ended, conversational, or a single tool-augmented call is enough.
  • Use a workflow when the process has well-defined steps, needs explicit control over execution order, or multiple agents and functions must coordinate.

Interop decisions:

  • Adopt MCP early if you want tool portability and you can expose internal tools as MCP servers.
  • Be cautious with A2A until the “coming soon” part becomes a versioned, documented 1.0 integration with compatibility guarantees.

Getting started (official links)

Install snippets Microsoft highlights:

  • Python: pip install agent-framework
  • .NET: dotnet add package Microsoft.Agents.AI