Microsoft Agent Frameworks Compared: Which One Should You Use?

I get this question constantly: "Which Microsoft agent framework should I use?" And honestly, I don't blame anyone for being confused. With so many Microsoft agent frameworks now available — Agent Framework, Foundry SDK, M365 Agents SDK, Semantic Kernel, plus a wave of open-source options — the landscape is genuinely overwhelming for Alberta businesses and startups trying to pick the right one.

I recently deployed agents in the new Microsoft Foundry experience and built out our Azure Agentic Engineering open-source repo to document the patterns. This article is the comparison guide I wish existed when I started.

New to AI agents? Start with our getting started with AI guide for the fundamentals before diving in.

The Microsoft Agent Framework Landscape

Let's start by mapping the territory. Microsoft doesn't have one agent framework — they have several, each targeting a different audience and deployment model. Here's the quick overview:

If you're thinking "why so many?" — Microsoft evolved here organically. Semantic Kernel and AutoGen were separate projects. Agent Framework is their unification, combining AutoGen's simple abstractions with Semantic Kernel's enterprise features. The other SDKs target different deployment surfaces (Azure vs. M365 vs. local).

Microsoft Agent Framework — The Flagship

This is the one to pay attention to. Microsoft Agent Framework (9.4K GitHub stars, 125+ contributors) is the direct successor to both Semantic Kernel and AutoGen, built by the same teams.

When to use it: You need multi-agent orchestration with explicit control over execution. You want graph-based workflows. You're building on Azure or need deep Microsoft integration. You're migrating from Semantic Kernel or AutoGen.

The key decision Microsoft's docs highlight is straightforward:

And the golden rule from their docs: "If you can write a function to handle the task, do that instead of using an AI agent."

Foundry SDK & Foundry Agent Service

The Foundry SDK is your bridge to Azure's AI platform. It connects to a single project endpoint that provides access to models, agents, evaluations, and tools.

When to use it: You want managed agent hosting on Azure. Security and compliance are non-negotiable (VNet isolation, RBAC, managed identity). You need built-in observability. You want to pair hosted agents with the Agent Framework for local orchestration.

The Foundry SDK exposes two client types — a Project client for Foundry-native operations and an OpenAI-compatible client for running agents, evaluations, and calling models. Most production apps use both.

I covered the Foundry Agent Service GA announcement in detail — check that post for the full breakdown of capabilities including Voice Live and MCP auth.

Microsoft 365 Agents SDK

The M365 Agents SDK targets a different surface entirely — deploying agents to Microsoft Teams, Copilot, and other M365 channels.

When to use it: Your agents need to live in Teams or Copilot. You're building for a Microsoft 365 enterprise environment. You want channel management (deploy once, reach Teams + web + Copilot).

Worth noting: You can now publish agents to Teams and Copilot directly from the new Microsoft Foundry experience as well — meaning you don't have to use the M365 Agents SDK to get your agents into those channels. If your agent is already built with Agent Framework and hosted in Foundry, publishing to Teams or Copilot is a configuration step, not a rebuild.

Comparing Microsoft Agent Frameworks to Open-Source Alternatives

This is where the conversation gets interesting. Microsoft's frameworks aren't your only options — and depending on your requirements, the open-source alternatives may be the better fit.

LangGraph (by LangChain)

When to use it: You need a mature, provider-agnostic solution. Your team knows Python or TypeScript. You want fine-grained control over execution graphs. You're not locked into Azure.

CrewAI

When to use it: You want the simplest path to multi-agent workflows. Your team is Python-native. You prefer role-based agent design (researcher, analyst, writer). You want minimal boilerplate.

PyTorch & the Foundation Ecosystem

This one requires context. PyTorch itself isn't an agent framework — it's the foundational ML framework that powers virtually all modern AI. But the PyTorch Foundation (under the Linux Foundation) is expanding into an umbrella organization that increasingly matters for agent developers:

• vLLM — The leading open-source LLM serving engine. If you're self-hosting models for your agents, vLLM is likely your inference layer.
• DeepSpeed — Microsoft's distributed training library, now under the PyTorch Foundation. Critical for fine-tuning models that back your agents.
• ExecuTorch — Edge/local deployment for agent capabilities on devices.
• TorchAO — Model compression for deploying efficient agent-backing models.

PyTorch isn't a direct alternative to Agent Framework or CrewAI — it's the layer underneath. When you self-host Llama or Mistral models that power your agents, PyTorch and its ecosystem are what makes that possible.

When it matters: You're self-hosting models (not using cloud APIs). You need to fine-tune or compress models for your agent use cases. You want complete control over the inference stack. You're building agents that run at the edge or on-device.

Decision Flowchart: Pick the Right Framework

Here's the decision tree I use when advising Alberta businesses and startups on which framework to adopt:

Head-to-Head Comparison

For the visual learners, here's everything in one table:

Lessons from Production: What I Learned

I built and open-sourced the Azure Agentic Engineering repo a few weeks back to document real patterns for deploying agents on Azure. Here's what I learned the hard way:

1. Start with the Foundry SDK if you're on Azure. The single-endpoint pattern (one URL for models, agents, and tools) dramatically simplifies configuration. Don't manage separate Azure OpenAI endpoints.
2. Use Agent Framework for orchestration, not the Foundry Agent Service alone. Foundry Agent Service handles hosting. Agent Framework handles the multi-agent logic. They're complementary, not competing.
3. DefaultAzureCredential everywhere. No API keys in code. Ever. Use managed identity in production — DefaultAzureCredential is fine for development but switch to ManagedIdentityCredential for production to avoid latency from credential probing.
4. Don't over-agent. If a function can handle the task, write a function. Agents add latency, cost, and unpredictability. Reserve them for genuinely open-ended tasks.
5. Observability from day one. Set up OpenTelemetry tracing before you scale. Debugging multi-agent systems without tracing is brutal.

The architecture pattern that worked best for us:

For the full reference architecture and deployment templates, see our Azure AI Landing Zones guide and the Foundry Blueprints.

When to Go Open Source Instead

Microsoft's frameworks are excellent if you're in the Azure ecosystem. But there are clear cases where open-source alternatives win:

The Bigger Picture: Cloud Adoption Framework for AI

Choosing a framework is just one decision in the Cloud Adoption Framework for AI. Microsoft's CAF AI guidance covers the full lifecycle: strategy, planning, readiness, governance, security, and management. Before you commit to a framework, make sure you've addressed:

• AI Strategy — Define your use cases and technology strategy
• AI Plan — Assess skills, prioritize use cases, create a proof of concept
• AI Ready — Build your environment, choose an architecture (that's where the Landing Zone decision comes in)
• Govern AI — Enforce policies and monitor organizational risks
• Secure AI — Protect resources and data, detect threats
• Manage AI — Operations, deployment, model management, cost management

Key Resources

Microsoft Frameworks

• Microsoft Agent Framework — Overview
• Agent Framework on GitHub
• Foundry SDK Overview
• M365 Agents SDK Overview
• Cloud Adoption Framework for AI

Open Source

• LangGraph on GitHub
• CrewAI on GitHub
• PyTorch: The Open Language of AI

Code To Cloud Resources

• Azure Agentic Engineering — Open Source Repo
• Microsoft Foundry Agent Service GA — Full Breakdown
• Azure AI Landing Zones Guide
• Azure Foundry Blueprints — Deploy in 15 Minutes

Connect with us on Discord! Join the Code to Cloud community here.

Frequently Asked Questions

What is the difference between Microsoft Agent Framework and Semantic Kernel?

Microsoft Agent Framework is the successor to both Semantic Kernel and AutoGen. It unifies AutoGen's simple agent abstractions with Semantic Kernel's enterprise features into a single framework. Semantic Kernel is still maintained for existing users, but new projects should start with Agent Framework.

Can I deploy agents to Microsoft Teams without the M365 Agents SDK?

Yes. You can now publish agents to Teams and Copilot directly from the Microsoft Foundry experience. If your agent is already built with Agent Framework and hosted in Foundry, publishing to Teams is a configuration step — no rebuild required. The M365 Agents SDK is still useful for deep channel management and custom activity protocols.

Is LangGraph or CrewAI better than Microsoft Agent Framework?

It depends on your stack. LangGraph (29.1K GitHub stars) is best for provider-agnostic, graph-based workflows in Python or TypeScript. CrewAI (48.8K stars) is ideal for Python teams wanting the simplest multi-agent setup. Microsoft Agent Framework is the best choice if you need .NET support, deep Azure integration, or A2A protocol support.

What is the Foundry Agent Service?

Foundry Agent Service is a fully managed agent hosting platform inside Azure AI Foundry. It provides VNet isolation, built-in evaluations, Azure Monitor integration, and MCP with complete auth coverage. It reached General Availability in April 2026.

Know someone building AI agents who needs to read this? Send them this article. And if you want to discuss which framework fits your team, book a free strategy call or join our Discord community.

Kevin Evans

Fractional CTO & Founder, Code To Cloud Inc.

Kevin Evans is a fractional CTO and technology advisor based in Calgary, Alberta. He helps startups and growing businesses across Western Canada make smart technology decisions. More about Kevin