Solutions for
Please select
Try the Web App
ki-werkzeuge

Microsoft Agent Framework

Redaktion ·

Microsoft Agent Framework — why this matters

If you’ve built on Microsoft’s agent tooling in recent years, you faced an awkward choice: Semantic Kernel or AutoGen? Both came from the same company, solved similar problems, but had different philosophies, separate APIs, and no shared roadmap. Pick wrong and you built on a dead-end track.

With the Microsoft Agent Framework, that choice has been settled since October 2025. Microsoft merged both projects into a single SDK and released it as version 1.0 for .NET and Python on April 3, 2026 (described by Microsoft as “production-ready”). Semantic Kernel and AutoGen move into maintenance mode — they still get bug and security fixes, but no new features.

This is relevant if you develop in the Microsoft or Azure ecosystem, if you need .NET as an agent platform (a gap the Python-heavy competition barely fills), or if you simply want to know where Microsoft stands against LangGraph and CrewAI. This article walks through the core concepts, the architecture, the market positioning — and who should actually adopt it.

The core idea: two projects, one line

To understand the framework, it helps to look at its two predecessors and what each contributed.

AutoGen — the simple abstractions

AutoGen was Microsoft’s research-driven multi-agent framework. Its strength: lean, intuitive abstractions for single agents and for conversations among multiple agents. You could quickly build a setup where two or three agents talk to each other, correct one another, and solve a problem through dialogue. AutoGen was great for prototypes and experiments — less so for hard production workloads.

Semantic Kernel — the enterprise machinery

Semantic Kernel came from the other direction: an enterprise-oriented SDK focused on stability, type safety, telemetry, filters (middleware), and broad model and embedding support. It was more robust, but also heavier and more complex to get into.

The Agent Framework as synthesis

The Agent Framework takes the best of both: AutoGen’s simple agent abstractions plus Semantic Kernel’s enterprise features — session-based state management, type safety, middleware, telemetry. On top of that it adds something new: graph-based workflows for explicit multi-agent orchestration. It was built by the same teams that previously worked on SK and AutoGen — so it isn’t a foreign object but the direct continuation of both lines.

The two pillars: agents and workflows

The central design decision is the split into two categories. Internalize this distinction and you’ve understood the framework at its core.

Agents — autonomous individual actors

An agent is a unit that uses a language model to process inputs, call tools and MCP servers, and generate responses. Agents are the right choice when the task is open-ended or conversational, when the model itself should decide which tool is useful when, and when a single model call (possibly with tools) is enough.

A minimal agent in Python looks like this:

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(result)

In .NET the pattern is almost identical — dotnet add package Microsoft.Agents.AI.Foundry, then an AIAgent via the AIProjectClient. That both languages are first-class citizens is perhaps the single biggest differentiator versus the rest of the market.

Workflows — explicit orchestration

A workflow is a directed graph that connects agents and ordinary functions into multi-step processes — with type-safe routing, checkpointing, and human-in-the-loop support. Workflows are the right choice when the process has well-defined steps, when you want explicit control over execution order, and when multiple agents or functions must coordinate.

The difference in one sentence: an agent decides for itself what happens next; a workflow prescribes the path and lets the model only fill in the individual nodes.

The building blocks underneath

Below agents and workflows sit the components that concrete applications are assembled from. This list is useful because it shows how far the framework goes beyond “LLM call in a loop.”

  • Model clients — connection to chat-completion and responses APIs. Per Microsoft, supported providers include Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic, and Ollama (local).
  • Agent session — session-based state management for multi-turn dialogues and long-running processes.
  • Context providers — the agent’s memory: relevant context is supplied through this interface.
  • Middleware — intercepts agent actions to log, filter, or modify them (the former “filter” concept from Semantic Kernel).
  • MCP clients — tool integration via the Model Context Protocol, plus support for the A2A (agent-to-agent) protocol.
  • Checkpointing — workflows can be saved and resumed at defined points, important for long runs and failure resilience.
  • Telemetry — observability via OpenTelemetry, tightly integrated with Azure AI Foundry for tracing, evaluation, and monitoring.

The MCP and A2A support is notable: Microsoft bets on open protocols instead of a closed proprietary standard — which eases interoperability with tools and agents from other vendors.

Positioning: where does it stand in the market?

The agent-framework market consolidated in 2026 to a handful of serious options. An honest assessment against the two main alternatives — more in our overview of agent frameworks.

| Criterion | Microsoft Agent Framework | LangGraph | CrewAI | |---|---|---|---| | Model | Agents + graph-based workflows | Graph-based state machine | Role-based “crews” | | Languages | Python + .NET | Python (TS separate) | Python | | Strength | Azure integration, .NET, open protocols | Production maturity, durable state | Fastest prototype | | Maturity (as of 2026) | GA 1.0 since April 2026 | Long production track record | Large community | | Protocols | MCP, A2A | MCP | MCP and others |

The rough rule of thumb that crystallized in 2026’s comparison articles: LangGraph is the default for stateful, durable production workflows — especially in regulated industries with long live experience (reportedly Uber, LinkedIn, and Klarna have run on it for over a year). CrewAI is the fastest path from concept to a working multi-agent demo. And the Microsoft Agent Framework is the obvious choice if you need .NET, are deep in Azure, or value A2A/MCP.

Pitfalls

A few things that surprise people in practice.

You’re building on young software

Despite the 1.0 label, the framework in its unified form has only been GA since April 2026 — that is a few weeks, measured against the date of this article. The SDK packages carried the --prerelease flag until shortly before. If you depend on maximum stability and a large ecosystem of tutorials, LangGraph simply offers more material and more production miles.

Migration is necessary, not optional

If you sit on Semantic Kernel or AutoGen today, maintenance mode is a statement: new features only land in the Agent Framework. Microsoft provides migration guides for both paths, but it’s real work, not a drop-in replacement. Plan for it instead of deferring it.

”Third-party systems” at your own risk

Microsoft explicitly notes in the docs: if you connect non-Azure models or external agents/servers, you do so at your own risk and under their license terms. Data protection, data flows beyond Azure boundaries, and your own responsible-AI mitigations (content filters, metaprompts) are your responsibility — the framework does not handle them for you.

Who should adopt it?

Clear yes cases: you develop in .NET and want to build agents in production — the selection of mature frameworks here is thin, and Microsoft’s solution is first-class. You’re deep in the Azure ecosystem and want Foundry Agent Service, observability, and deployment from one source. Or you already sit on Semantic Kernel or AutoGen and have to migrate anyway.

More likely no: you’re building a pure Python project without Azure ties and need maximum production maturity today — then LangGraph is the more conservative choice. Or you want to build a multi-agent demo in an afternoon — then CrewAI gets there faster.

FAQ

Is the Microsoft Agent Framework the same as Azure AI Foundry?
No, but they interlock. The Agent Framework is the open-source SDK and runtime for building agents. Azure AI Foundry (with the Foundry Agent Service) is the hosted platform where you run, observe, and deploy those agents. You can use the framework without Foundry, but Foundry adds tracing, evaluation, and deployment.
Are Semantic Kernel and AutoGen dead now?
Not dead, but in maintenance mode. They still receive bug and security fixes, but no new features. Microsoft recommends migrating to the Agent Framework to access new capabilities.
Which languages are supported?
Python and .NET (C#), both first-class with largely parallel APIs. This strong .NET support is the key difference from the Python-dominated competition like LangGraph and CrewAI.
Can I use non-Microsoft models?
Yes. Per Microsoft, supported providers include OpenAI, Anthropic, and local models via Ollama — alongside Azure OpenAI and Microsoft Foundry. For non-Azure models, however, their license and data-protection terms apply, and you carry the risk yourself.
What's the difference between an agent and a workflow?
An agent decides autonomously what happens next and is good for open-ended, conversational tasks. A workflow is an explicit, directed graph with fixed steps — you control the order, the model only fills the nodes. Workflows offer checkpointing and human-in-the-loop.

Conclusion

The Microsoft Agent Framework is Microsoft tidying its own garden: two competing projects merged into one line, with a clear concept (agents for autonomy, workflows for control) and serious enterprise equipment. The real strengths lie in first-class .NET support, deep Azure integration, and the bet on open protocols (MCP, A2A).

The caveat is its youth: GA only since April 2026, fewer production miles than LangGraph. If you build in the Microsoft universe, you should still make it your default option. If you can choose freely and need maximum maturity today, compare honestly against the alternatives — and decide by language, cloud ties, and the degree of control you want.

Themenuebersicht

KI-WerkzeugeAgenten-Frameworks