Microsoft Agent Framework 1.0 Guide 2026 (MAF)

What is Microsoft Agent Framework 1.0?

In short

Microsoft Agent Framework (MAF) is Microsoft's official open-source SDK for building single- and multi-agent AI systems in .NET and Python. It reached 1.0 GA on April 3, 2026, after public preview at Microsoft Build 2026, and ships as Microsoft.Agents.AI on NuGet and agent-framework on PyPI under an MIT license.

Microsoft Agent Framework is the SDK Microsoft asks every new agent project to build on in 2026. It replaces Semantic Kernel for agent code and absorbs the AutoGen research lineage into a supported, versioned, cross-language runtime.

The 1.0 GA release shipped April 3, 2026, following a public preview announced at Microsoft Build 2026. The package names are stable and worth remembering:

• .NET: Microsoft.Agents.AI on NuGet, plus provider packages such as Microsoft.Agents.AI.Foundry and Microsoft.Agents.AI.Hosting.A2A.
• Python: agent-framework on PyPI, with sub-packages like agent-framework-foundry, agent-framework-openai, agent-framework-copilotstudio, and agent-framework-a2a.
• Repo: MIT-licensed and developed in the open at github.com/microsoft/agent-framework.

The distinctive design choice is that concepts and API shape are the same across runtimes. A .NET team and a Python team can review each other's agent code and read it like a translation, not a rewrite — a first for Microsoft's AI SDKs.

Where MAF fits in the broader landscape is covered in Alice Labs' pillar on the best AI agent frameworks for 2026. This deep-dive assumes you have already narrowed the shortlist to include MAF and need the operational detail to commit.

Why Microsoft merged Semantic Kernel and AutoGen into MAF

In short

Microsoft ran two parallel agent bets from 2023 to 2025: Semantic Kernel for enterprise model connectors, memory, and tool calling, and AutoGen for multi-agent conversation patterns and the Magentic-One orchestration. MAF absorbs both — Semantic Kernel becomes the foundation layer and AutoGen-style orchestration becomes a graph on top.

For roughly three years, Microsoft shipped two overlapping agent stacks. Semantic Kernel, out of Azure and the Office group, focused on enterprise plumbing — connectors to Azure OpenAI, chat completion, function calling, plugins, and vector-store memory. AutoGen, out of Microsoft Research, focused on the research question of how multiple LLM agents converse and coordinate, and produced the influential Magentic-One orchestration.

The two teams solved different problems, but their customer surfaces started to collide. Enterprises using SK for tool-calling agents wanted the Magentic-One planner. Research teams using AutoGen wanted SK's Azure connectors and Foundry hosting. Neither team could deliver both without duplicating the other's roadmap.

MAF is the resolution. According to Microsoft's introduction blog, the goal is "enterprise-grade multi-agent orchestration, multi-provider model support, and cross-runtime interoperability via A2A and MCP." In practice:

• Foundation layer: Semantic Kernel's model connectors, function calling, and memory abstractions become the base primitives.
• Orchestration layer: AutoGen's Group Chat, Handoff, and Magentic-One patterns become first-class MAF workflows on top of that base.
• Migration path: Both SK and AutoGen users get a formal migration guide. Semantic Kernel packages remain; AutoGen v0.4 users port to MAF workflows.

The commercial motivation is straightforward. Microsoft needs one agent SDK it can recommend to every Azure customer, and one runtime — Foundry Agent Service — that can host it consistently. Two parallel SDKs made the pitch to CIOs unnecessarily complicated. MAF removes the choice.

MAF architecture: one AIAgent type across every provider

In short

MAF collapses Semantic Kernel's ChatCompletionAgent, AzureAIAgent, and OpenAIAssistantAgent into a single AIAgent base type (Agent in Python). Any IChatClient from Microsoft.Extensions.AI produces an agent via a one-line extension, and sessions replace SK's manual thread creation.

The most-felt change from Semantic Kernel is the collapse of the agent-type zoo. In SK, you picked between ChatCompletionAgent, AzureAIAgent, OpenAIAssistantAgent, and a handful of others, and each had subtly different constructors and lifecycle methods.

MAF gives you one abstraction:

• .NET: AIAgent is the base type. ChatClientAgent handles the common case; CopilotStudioAgent and A2AAgent are the two additional built-ins.
• Python: Agent is the base (built on BaseAgent plus the SupportsAgentRun interface).
• Provider surface: Any IChatClient from Microsoft.Extensions.AI can produce an agent with a single .AsAIAgent(...) extension.

Supported model providers at 1.0 include Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini, and Ollama. Adding a new provider is an IChatClient implementation — same shape as any other Microsoft.Extensions.AI client.

The second visible change is session management. In SK you manually constructed an AzureAIAgentThread and threaded it through calls. In MAF you call agent.CreateSessionAsync() (.NET) or agent.create_session() (Python) and MAF handles thread identity, checkpointing, and continuation.

A minimal .NET agent illustrates how compact the surface is:

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

var projectClient = new AIProjectClient(
    new Uri("https://your-project.services.ai.azure.com/api/projects/YourProject"),
    new AzureCliCredential());

AIAgent agent = projectClient.AsAIAgent(
    model: "gpt-4o",
    instructions: "You are a Nordic banking compliance assistant.",
    name: "ComplianceAgent");

AgentResponse response = await agent.RunAsync("Summarise the PSD3 draft changes.");
Console.WriteLine(response.Text);

And the Python equivalent, which reads almost identically:

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

agent = FoundryChatClient(
    credential=AzureCliCredential(),
    project_endpoint="https://your-project.services.ai.azure.com/api/projects/YourProject",
).as_agent(
    model="gpt-4o",
    instructions="You are a Nordic banking compliance assistant.",
    name="ComplianceAgent",
)

response = await agent.run("Summarise the PSD3 draft changes.")
print(response.text)

Installing MAF: Python and .NET package layout

In short

Python users install pip install agent-framework for the meta-package plus provider sub-packages such as agent-framework-foundry, agent-framework-openai, and agent-framework-a2a. .NET users install Microsoft.Agents.AI plus Microsoft.Agents.AI.Foundry, Azure.AI.Projects, and Azure.Identity for Foundry-hosted deployments.

The install story is intentionally boring — one meta-package plus provider-specific sub-packages, matching the pattern of langchain-community or openai-agents.

Python:

# Core + common providers
pip install agent-framework

# Provider-specific extras
pip install agent-framework-foundry        # Azure AI Foundry
pip install agent-framework-openai         # OpenAI + Azure OpenAI
pip install agent-framework-copilotstudio  # Copilot Studio agents
pip install agent-framework-mem0           # Mem0 memory backend
pip install agent-framework-a2a --pre      # A2A client + server

All imports remain under agent_framework.* regardless of which sub-package is installed — you never write from agent_framework_foundry import .... Sub-packages register their providers with the core registry.

.NET:

# Core
dotnet add package Microsoft.Agents.AI

# Foundry hosting
dotnet add package Microsoft.Agents.AI.Foundry
dotnet add package Azure.AI.Projects
dotnet add package Azure.Identity

# A2A hosting (ASP.NET Core)
dotnet add package Microsoft.Agents.AI.Hosting.A2A
dotnet add package Microsoft.Agents.AI.Hosting.A2A.AspNetCore

For enterprise pipelines, pin the exact version in both requirements.txt and *.csproj. MAF 1.0 has stable APIs, but preview sub-packages (A2A Python, Agent Optimizer) still ship breaking changes. Alice Labs' internal policy is to treat any package tagged --pre as pinnable-only, no wildcards.

Building your first MAF agent (Python and .NET side by side)

In short

The minimum working MAF agent is a five-line snippet in either runtime: instantiate a chat client, call .AsAIAgent() or .as_agent(), and await RunAsync/run. Streaming uses RunStreamingAsync in .NET and stream=True in Python, yielding AgentResponseUpdate deltas.

Once the packages are installed, the minimum working agent is small enough to fit on a slide in either runtime. The design goal was that a developer coming from any prior agent SDK — SK, AutoGen, LangChain, or the OpenAI SDK — could recognise the pattern immediately.

Adding a tool in Python is a single-line change from bare-Python: pass the function directly, and MAF introspects the signature and docstring:

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

def get_weather(city: str) -> str:
    """Return the current weather for a Nordic city."""
    return f"The weather in {city} is 14C and cloudy."

agent = FoundryChatClient(credential=AzureCliCredential()).as_agent(
    model="gpt-4o",
    instructions="You are a travel assistant.",
    tools=[get_weather],
)

response = await agent.run("What is the weather in Stockholm today?")
print(response.text)

In .NET, tool wrapping uses AIFunctionFactory.Create from Microsoft.Extensions.AI:

using Microsoft.Extensions.AI;
using Microsoft.Agents.AI;

[Description("Return the current weather for a Nordic city.")]
static string GetWeather(string city) => $"The weather in {city} is 14C and cloudy.";

AIAgent agent = chatClient.AsAIAgent(
    instructions: "You are a travel assistant.",
    tools: new[] { AIFunctionFactory.Create(GetWeather) });

AgentResponse response = await agent.RunAsync("What is the weather in Stockholm today?");
Console.WriteLine(response.Text);

Streaming replaces RunAsync / agent.run(...) with RunStreamingAsync / agent.run(..., stream=True). Both yield AgentResponseUpdate instances that you can push directly into a chat UI token-by-token.

Native Model Context Protocol (MCP) support in MAF

In short

MCP support ships at MAF 1.0, not as a preview add-on. The .NET Agent Framework integrates with the official MCP C# SDK, and tool registration is symmetric: local Python or .NET functions and remote MCP tools appear identically to the agent, so switching between them requires no agent-side code change.

Model Context Protocol is the emerging standard for exposing tools and resources to LLM agents in a language-neutral way. MAF's decision to ship MCP support at 1.0 GA — rather than as a preview — matters for two reasons.

First, it means an MAF agent can consume any MCP-compliant server without a Microsoft-specific adapter. That includes servers built with the Anthropic MCP Python SDK, the community MCP Node SDK, or the official MCP C# SDK that MAF's .NET runtime integrates directly.

Second, it means tool registration is symmetric. From the agent's perspective, a local Python function and a remote MCP tool are indistinguishable — both surface as callable tools with a schema, a name, and a description. That symmetry lets you develop with local functions and swap to production MCP servers without changing the agent definition.

from agent_framework.openai import OpenAIChatClient
from agent_framework.mcp import MCPStdioClient

# Connect to a remote MCP server (stdio transport in this example)
mcp = MCPStdioClient(command="mcp-server-filesystem", args=["/data"])
await mcp.connect()

agent = OpenAIChatClient(model="gpt-4o").as_agent(
    instructions="You help auditors read compliance documents.",
    tools=[get_local_summary, *await mcp.list_tools()],
)

MCP servers can be composed with A2A endpoints so the same MAF agent serves multiple clients — Copilot Studio, a bespoke chat UI, and an A2A caller from a LangGraph agent — without code changes. In Alice Labs' Nordic public-sector deployments, this is how we expose a single compliance-check agent to both Microsoft 365 Copilot and internal LangGraph workflows without maintaining two implementations.

For broader context on how MCP fits into the emerging agent-protocol landscape, see our Model Context Protocol explainer.

Native Agent-to-Agent (A2A) protocol and cross-runtime interop

In short

A2A v1 ships as Microsoft.Agents.AI.Hosting.A2A (and .AspNetCore) for .NET and as agent-framework-a2a for Python. Every A2A agent publishes an AgentCard describing its capabilities, and context_id maps to MAF session IDs for continuity. A2A supports Server-Sent Events streaming and long-running tasks with continuation tokens.

The Agent-to-Agent (A2A) protocol, incubated jointly by Microsoft, Google, and the Linux Foundation, defines how one agent calls another regardless of framework. MAF is an A2A-native runtime — an MAF agent can call a LangGraph agent, a Google ADK agent, or any other A2A-compliant remote agent as if it were a tool, and can itself be called from any A2A client.

The mechanics are:

• AgentCard: Every A2A agent publishes an AgentCard at a well-known URL, describing name, description, version, and capabilities. Callers inspect the card to decide whether to route a task to this agent.
• context_id: A2A carries a context_id that MAF maps to a session ID. Follow-up calls to the same agent with the same context_id resume the prior conversation.
• Streaming: A2A supports Server-Sent Events for token-level streaming, so a browser or upstream agent sees incremental output rather than a final blob.
• Long-running tasks: A2A supports background execution with continuation tokens — critical for research agents or long-running analysis where synchronous HTTP would time out.

The Python client-side pattern for calling a remote A2A agent as a tool is one call:

from agent_framework.a2a import A2AAgent

# Wrap a remote A2A endpoint as a callable agent tool
research_agent = A2AAgent(
    endpoint="https://research-agent.example.com/.well-known/agent.json",
)

# Use it inside another agent as a tool
orchestrator = OpenAIChatClient(model="gpt-4o").as_agent(
    instructions="Coordinate research and drafting.",
    tools=[research_agent.as_tool()],
)

The server-side pattern in ASP.NET Core exposes any local MAF agent as an A2A endpoint with an AddA2AAgent registration and a mapped endpoint. The framework handles the AgentCard, the SSE streaming, and the task-lifecycle plumbing.

Outbound A2A (calling a remote agent as a tool) went GA at BUILD 2026. Incoming A2A endpoint exposure — turning your own agent into an A2A-callable service — is in public preview and slated for GA later in 2026.

MAF Workflows: graph-based orchestration with WorkflowBuilder

In short

Workflows are directed graphs of executors connected by type-validated edges. The superstep execution model provides deterministic parallel fan-out and fan-in with checkpoints at each boundary. Two APIs exist: Functional (@workflow + @step decorators, Python experimental) and Graph (WorkflowBuilder in both runtimes).

The distinction between an agent and a workflow in MAF is worth internalising early. An agent is LLM-driven and dynamic — you tell it what to do and it decides which tool to call next. A workflow is deterministic — you draw the graph, and MAF executes it step-by-step with type validation between nodes.

Workflows are the right primitive when the sequence is known, the intermediate outputs need type safety, or the process must be checkpointable and resumable across days. In practice, most enterprise MAF deployments blend the two: a workflow orchestrates the high-level pipeline, and individual nodes inside the workflow are LLM-driven agents.

The graph API (WorkflowBuilder) is the stable primary interface. Executors are functions or classes wired together with typed edges. The superstep execution model gives deterministic parallel fan-out and fan-in with a checkpoint at each superstep boundary — a failure at superstep N resumes from N, not from the beginning.

from agent_framework.workflows import WorkflowBuilder, RequestInfoExecutor

builder = WorkflowBuilder()
builder.add_executor("classify", classify_intent)
builder.add_executor("draft", draft_reply)
builder.add_executor("human_review", RequestInfoExecutor())
builder.add_executor("send", send_email)

builder.add_edge("classify", "draft")
builder.add_edge("draft", "human_review")
builder.add_edge("human_review", "send")

workflow = builder.build()

Human-in-the-loop is handled by the RequestInfoExecutor primitive (graph API) or ctx.request_info() inside a functional-API workflow. The workflow pauses, persists its checkpoint, and resumes when the human response is submitted — hours or days later if needed.

Any workflow can be exposed as an agent via .as_agent(), which means workflows can be chained inside workflows and consumed from agent-shaped call sites. That composition is the trick that lets MAF avoid a hard separation between "agent code" and "workflow code" the way earlier frameworks (including SK plus a separate orchestrator) did.

Orchestration patterns in MAF 1.0: Sequential, Concurrent, Handoff, Group Chat, Magentic

In short

All five orchestration patterns reached 1.0 GA on April 3, 2026. Sequential and Concurrent are the base primitives; Handoff enables one-agent-passes-to-next patterns; Group Chat is the AutoGen many-to-many conversation pattern; Magentic is a direct port of the Magentic-One design with a dedicated manager LLM selecting the next agent.

MAF 1.0 shipped every stable orchestration pattern simultaneously on April 3, 2026 — no preview footnotes, no "coming soon." That matters because prior Microsoft agent SDKs frequently shipped the orchestration primitives out of sync with the base agent, forcing enterprise teams to backport or pin to preview.

MAF 1.0 Orchestration Patterns and When to Use Each

Every pattern emits OpenTelemetry spans, so Foundry tracing shows agent-level and tool-level detail without additional instrumentation. That is the practical difference between "we could add tracing" and "an auditor can replay every decision" — the latter being what EU AI Act Article 12 logging requirements expect from a high-risk system.

Semantic Kernel migration: eleven concrete API changes

In short

The SK to MAF migration has eleven repeatable API changes: namespace rename, agent-creation one-liner, session replaces thread, raw functions replace [KernelFunction], RunAsync replaces InvokeAsync, and keyed DI registration replaces AddKernel plus keyed Agent. Microsoft ships a compatibility layer so KernelFunction converts to MAF tools via .as_agent_framework_tool().

Microsoft's official migration guide at learn.microsoft.com/en-us/agent-framework/migration-guide/from-semantic-kernel/ enumerates every SK concept that changes in MAF. In practice, most Alice Labs SK migrations touch the same eleven diff points repeatedly.

Semantic Kernel to MAF — The Eleven Changes

The compatibility layer is the migration accelerator most SK teams underestimate. Existing KernelFunction-decorated methods and SK vector-store search functions can be exposed to a new MAF agent via .as_agent_framework_tool() without rewriting the underlying implementation — port the agent surface first, retire the SK-decorated internals opportunistically.

AutoGen v0.2 and v0.4 migration to MAF

In short

AutoGen AssistantAgent maps to MAF Agent with tools=[...]. AutoGen GroupChat becomes the Group Chat orchestration pattern under agent_framework.workflows. Magentic-One becomes a first-class pattern in agent_framework.workflows.orchestrations.magentic. UserProxyAgent becomes a RequestInfoExecutor inside a workflow for human-in-the-loop.

AutoGen and MAF speak different vocabularies for many of the same ideas, but the underlying primitives — agents that hold LLM state, conversation histories, and orchestrators that route messages — line up cleanly.

AutoGen to MAF — Primary Mappings

The pattern to internalise: AutoGen encoded roles (Assistant, UserProxy, GroupChat manager) as different agent classes. MAF encodes them as different executors inside workflows, letting you compose them freely. A UserProxyAgent that also holds tool state, for example, becomes a workflow with a RequestInfoExecutor node upstream of a tool-using Agent node — no monolithic hybrid class required.

The AutoGen repository continues to exist for research use, but the production migration path is documented and supported. Alice Labs' recommendation to teams still on AutoGen v0.4 in 2026 is to plan the port to MAF within the next release cycle, because Foundry Agent Service hosting and A2A interop increasingly assume MAF-shaped agents.

Azure AI Foundry Agent Service: hosting MAF agents in production

In short

Foundry Agent Service reached GA on June 2, 2026 (BUILD 2026) as a framework-agnostic runtime hosting MAF, GitHub Copilot SDK, and LangGraph agents identically. It provides durable state, long-running autonomous execution, Routines for scheduled agents, and publishing to Microsoft Teams, Microsoft 365 Copilot, and Autopilot agents with Entra Agent ID.

Foundry Agent Service is the managed runtime that closes the loop from local MAF development to enterprise production. It reached GA within thirty days of Microsoft Build 2026 (announced June 2, 2026), and it is framework-agnostic — the same runtime hosts MAF agents, GitHub Copilot SDK agents, and LangGraph agents through a common hosting contract.

The features that matter for enterprise deployments are:

• Durable state: Agent sessions persist across the runtime lifecycle — a restart or scaling event does not lose in-flight conversations.
• Long-running autonomous execution: Agents can execute for hours or days without a client connection. Progress is checkpointed and resumable.
• Routines: Scheduled agent execution (cron-shaped) for background tasks like nightly compliance sweeps or weekly report generation.
• Publishing destinations: Deploy the same agent to Microsoft Teams, Microsoft 365 Copilot, or Autopilot with Entra Agent ID for organisational identity and least-privilege delegation.
• Procedural memory (public preview): Microsoft reports gains of roughly seven to fourteen percentage points in absolute task success rate at near-baseline inference cost.

The deployment pattern is intentionally minimal: build the agent locally with MAF, push it to Foundry, and Foundry handles scaling, session storage, telemetry, and publishing. In Alice Labs' Nordic public-sector rollouts, this replaces a bespoke Azure Container Apps stack we would previously assemble by hand around SK — with a typical reduction in infrastructure-code footprint of roughly seventy percent.

Data residency is configurable per Foundry project. For Nordic banking clients where EU data-boundary requirements are contractual, Foundry regions in Sweden Central and West Europe are the default targets. Verify the specific data-processing terms in your Microsoft enterprise agreement.

Observability: OpenTelemetry, Foundry tracing, and evaluation loops

In short

OpenTelemetry integration is built into MAF — every agent invocation, tool call, and workflow superstep emits a span. Microsoft contributed a cross-framework OTel schema with Outshift and Cisco that covers MAF, LangChain, LangGraph, and OpenAI Agents SDK. Foundry Tracing and Evaluation reached GA in June 2026 with production trace to evaluation-score linking.

EU AI Act Article 12 requires that high-risk AI systems keep automatically-generated logs sufficient to reconstruct the system's behaviour. MAF makes this a default rather than an add-on: every agent invocation, tool call, and workflow superstep emits an OpenTelemetry span with consistent attributes.

The three observability layers that Alice Labs configures for every enterprise MAF deployment:

• OpenTelemetry export: Configure OTLP export to whichever backend your SRE team already runs — Foundry-native, Grafana Tempo, Datadog, or Azure Monitor. No agent code changes.
• Cross-framework schema: Microsoft contributed with Outshift and Cisco a shared OTel schema that covers MAF, LangChain, LangGraph, and the OpenAI Agents SDK. A hybrid stack sees one trace format across every framework.
• Foundry Tracing and Evaluation (GA June 2026): Links production traces to evaluation scores so regressions are attributable to specific agent versions, prompt changes, or model swaps.

Responsible AI features shipping in public preview at the time of writing include Task Adherence (does the agent stay within its declared scope), Prompt Shields with Spotlighting (defence against prompt injection with visible source tagging), and PII Detection at both input and output boundaries. Agent Optimizer — which generates candidate improvements with rollback — moved from private to public preview after BUILD 2026.

For deployments that will undergo formal EU AI Act conformity assessment, document the OTel export configuration, retention policy, and evaluation cadence in your technical documentation. See our EU AI Act compliance checklist for 2026 for the full evidence set high-risk systems must maintain.

BUILD 2026 updates and the MAF roadmap through 2026

In short

BUILD 2026 (June 2) took MAF's agent harness with skills, memory, and middleware to stable, alongside GitHub Copilot SDK integration, Claude Agent SDK integration, and Magentic-One orchestration. Public preview: file system tools, memory tools, deep research agent, incoming A2A endpoint exposure, and Agent Optimizer. Outbound A2A also went GA at BUILD.

BUILD 2026 was the first major post-1.0 milestone for MAF, and the pattern of announcements was informative: the base runtime is stable and Microsoft is now layering hosted capabilities on top rather than reshaping the core.

Stable at BUILD 2026:

• Agent harness with skills, memory, and middleware
• GitHub Copilot SDK integration (for coding-specific agents)
• Claude Agent SDK integration (Anthropic models as first-class citizens)
• Magentic-One orchestration
• Outbound A2A (calling remote agents as tools)

In public preview:

• File system tools and memory tools (bounded, sandboxed defaults)
• Deep research agent primitive (long-running, multi-step research workflows)
• Incoming A2A endpoint exposure (turn your MAF agent into an A2A-callable service)
• Agent Optimizer (candidate improvements with rollback)
• DevUI browser debugger for local workflow inspection
• Foundry hosted-agent integration for Copilot SDK
• Skills (reusable domain capability packages)

The Go SDK (agent-framework-go) develops on a separate cadence from the .NET and Python runtimes. Check github.com/microsoft/agent-framework-go for current status if your stack is Go-first.

For .NET teams, the Claude Agent SDK integration is worth flagging specifically. Alice Labs is an Anthropic Partner, and this integration means Claude models can back an MAF agent without leaving the MAF programming model — the same code that talks to Foundry or Azure OpenAI now talks to Claude with a single client swap.

When to choose MAF vs LangGraph, CrewAI, or the Claude Agent SDK

In short

Pick MAF when the stack is .NET-centric, Azure Foundry-hosted, or requires Entra Agent ID and Microsoft 365 publishing. Pick LangGraph for Python-first teams that prefer explicit state graphs. Pick the Claude Agent SDK when Anthropic is the primary model and you want native computer-use and subagents. Pick CrewAI when role-and-task orchestration simplicity outranks graph control.

No framework is right for every use case. In Alice Labs' 100+ production implementations, we deploy MAF, LangGraph, CrewAI, and the Claude Agent SDK against different stacks, and the decision is usually a function of two variables: the engineering language and the model or hosting constraint.

Framework Selection Cheat Sheet (Alice Labs Production Data)

Alice Labs' default for Nordic banking, industrial, and public-sector clients is MAF — because those environments have existing Azure sovereignty commitments, .NET application stacks, and Microsoft 365 as the delivery surface. Where the constraint is "Anthropic Claude models specifically," we bring in the Claude Agent SDK; where the constraint is "Python research team already on LangGraph," we keep LangGraph and use A2A to bridge to any MAF-hosted enterprise services.

For a full head-to-head comparison of the shortlist including benchmarks and licensing, see the Alice Labs pillar guide on the best AI agent frameworks for 2026 and the direct comparison of LangGraph vs CrewAI vs AutoGen.