datarekha
Frameworks May 11, 2026

Microsoft Agent Framework, six months in

Microsoft consolidated Semantic Kernel and AutoGen into a single Agent Framework in late 2025. Half a year later, the picture is clear: MAF is the Azure-native option for shops that already speak C# and .NET, and its workflow/agent split is the most pragmatic in the industry.

11 min read · by datarekha · microsoftagentsazuresemantic-kernelautogen

In late 2025, Microsoft did something rare for a large incumbent — they acknowledged that two of their own AI frameworks had been competing for the same workload and merged them. Semantic Kernel and AutoGen were each well-loved by their respective communities. They were also confusingly overlapping, and any Microsoft customer trying to pick one had to read three blog posts and one GitHub issue thread to feel confident.

The result of the merger is Microsoft Agent Framework (MAF), released to public preview in October 2025. Six months in, with several big Microsoft customers shipping MAF-based agents on Azure, it’s now possible to give a real assessment instead of a launch-post summary.

What MAF is, in one paragraph

MAF is an open-source SDK in Python and .NET that gives you two primitives: Workflows, which are deterministic graphs of typed activities (this is the part that came from Semantic Kernel’s process framework), and Agents, which are non-deterministic LLM-driven loops (this is the part that came from AutoGen). The two compose: an agent can be a node inside a workflow, and a workflow can be a tool invoked by an agent. Both run on the same execution engine and share the same observability story. Azure AI Foundry is the first-class deployment target, but MAF runs anywhere .NET or Python runs.

The Workflow / Agent split is the interesting design choice

Most agent frameworks blur the line between “code that decides what to do” and “model that decides what to do.” LangGraph blurs it via conditional edges. ADK blurs it via agent-as-tool. CrewAI hides it entirely behind a manager agent.

MAF picks the opposite philosophy: it makes you declare which mode you’re in.

WORKFLOW — DETERMINISTICextractvalidatestoretyped activities, static edges,replayable, durableif you can draw the DAG,use a WorkflowAGENT — NON-DETERMINISTICLLMlooptoolsmodel picks next action,tool, or final responseif the model has to decide,use an Agent
The MAF split: workflows are graphs you can draw on a whiteboard; agents are loops where the model picks the next step. Both compose freely.

This sounds pedantic, but it has real consequences for production teams. A Workflow is replayable, idempotent, and durable. A run is just a sequence of activity invocations and their results. If a worker crashes, another worker resumes from the same activity. This is the Temporal / Azure Durable Functions playbook — and indeed MAF’s workflow runtime shares lineage with Durable Task.

An Agent is the opposite. The state is the conversation; the next step is whatever the LLM emits. MAF persists agent state (messages, tool calls, results), but the decisions are inherently non-replayable. If you re-run an agent from the same checkpoint, you will get a different sequence of tool calls — because the model is stochastic.

The cleanest production application of this split: an order-processing workflow that calls an agent only when it hits an ambiguous step. The workflow is durable, idempotent, and auditable. The agent is where the ambiguity lives. You don’t have to argue with your security team about whether “the agent” can be replayed for an audit — the workflow can, the agent can’t, and that’s an explicit design choice.

Azure AI Foundry is the deployment story

The other half of the MAF pitch is the Azure AI Foundry integration. Foundry is Microsoft’s umbrella for “deploy a model, build an agent, ship to production” — it owns model hosting, evaluation, content safety, tracing, and the agent runtime. MAF agents target Foundry the way Spring Boot apps target Azure App Service: you can run them anywhere, but the gravity well is real.

What you get for free when you deploy a MAF agent to Foundry:

  • OpenTelemetry traces shipped to Application Insights, with the agent’s tool calls and LLM turns shown as a single distributed trace.
  • Content safety filters in front of inputs and outputs without writing a line of code, with the same configuration UI a Microsoft enterprise admin already knows.
  • Evaluation pipelines wired into the same eval system that ships models — you can run an agent against a test set the same way you’d benchmark a fine-tuning run.
  • Managed identity and RBAC for the agent’s access to Azure resources. The agent doesn’t get a service principal key in an environment variable; it gets a managed identity, and you grant it scoped permissions.

For a Fortune 500 customer with an existing Azure footprint and a security review board, that pile of features is more valuable than any particular framework decision. The agent is just another Azure workload.

What a MAF agent actually looks like

The .NET version, since that’s the audience MAF is uniquely positioned to serve:

using Microsoft.Agents.AI;

var agent = new ChatClientAgent(
    chatClient: new AzureOpenAIClient(...).GetChatClient("gpt-4.1"),
    name: "support-triage",
    instructions: "Classify the incoming ticket and route it.")
    .WithTools(new[]
    {
        Tool.FromMethod(GetCustomerTier),
        Tool.FromMethod(LookupSimilarTickets),
        Tool.FromMethod(EscalateToHuman),
    });

await foreach (var update in agent.RunStreamingAsync(ticketText))
{
    Console.Write(update.Text);
}

If you’ve written Semantic Kernel before, this will look familiar — that’s deliberate. If you’ve written AutoGen, the multi-agent composition primitives (Sequential, Concurrent, GroupChat) are also there. The merge is real.

The Python version reads almost identically; Microsoft has gone to unusual lengths to keep the two SDKs in lockstep API-wise, which matters if you’re a polyglot shop with Python data scientists and .NET application engineers.

Where it lands six months in

The case studies Microsoft has been quietly publishing on the Azure AI Foundry blog point to a specific kind of adopter:

  • Enterprise IT departments that are already running on Azure and want agents inside their existing security model.
  • Internal developer-productivity teams using Foundry’s tracing to understand why an agent did what it did.
  • Financial-services and healthcare shops where the durable workflow primitive is a regulatory requirement, not a nice-to-have.

The conspicuously absent adopter: AI-native startups. MAF is not the fastest way to ship the first prototype. It is the fastest way to ship the fiftieth iteration of a prototype, inside an enterprise, on Azure. That’s a coherent niche and Microsoft is being honest about it.

Where it bites

A short, honest list:

  • The .NET SDK is more mature than the Python one. This is unusual in the AI ecosystem and worth flagging — most Python teams will find rough edges that .NET teams won’t.
  • Foundry lock-in is real. You can run MAF off-Azure, but the observability, eval, and safety integrations get noticeably worse. If you’re not committed to Azure, you give up a lot of what makes MAF compelling.
  • The “Workflow as a first-class primitive” idea is the right one, but the API still leaks Durable Task heritage. Concepts like OrchestrationContext and explicit activity declarations feel heavier than LangGraph’s equivalents. The trade-off is that the workflows are genuinely durable in the Temporal sense, not the best-effort sense.
  • Multi-agent orchestration is less battle-tested. The AutoGen community had years of multi-agent experimentation; the MAF primitives that absorbed it are newer and have a smaller proven surface area in production.

When to pick MAF

A simple test:

  • Your stack is .NET, or your security team has standardised on Azure.
  • You need agents that compose with deterministic, auditable workflows.
  • You want the agent’s traces, evals, and safety policies in the same place as the rest of your AI workloads.

If two of those three are true, MAF is the right call. If none are true, you’ll probably be happier with LangGraph or one of the cloud-native alternatives.

What to take away

The Semantic Kernel / AutoGen merger could have gone badly. Two overlapping projects from a large company often produce a third overlapping project with the worst of both. MAF didn’t do that — it took the strongest piece of each (Workflow from SK, Agent from AutoGen) and gave them a single execution model.

For Microsoft’s actual customer base — large enterprises on Azure with existing .NET investments — MAF is now the clearly correct choice for production agents. For everyone else, it’s worth understanding as the example of an enterprise-shaped agent framework, even if you never deploy one.

Further reading: the MAF launch post on DevBlogs is the canonical introduction. The Microsoft Learn module on building MAF agents covers the SDK in depth, and the Azure AI Foundry agent runtime docs explain the deployment story.

Skip to content