Microsoft Agent Framework: A Multi-Language SDK for Agents You Intend to Operate, Not Just Demo
A framework for building, orchestrating and deploying AI agents and multi-agent workflows with support for Python and .NET.
At a glance
- What is it?
- MAF packages agent construction, graph-based orchestration and Foundry hosting behind consistent Python and .NET APIs under the MIT licence. The interesting part is not the agent loop, it is the checkpointing, middleware and human-in-the-loop machinery that only pays off if your agents actually run in production.
- Who is it for?
- Adopt MAF if you are building multi-agent workflows in Python or .NET and you need checkpointing, human-in-the-loop control and provider flexibility from the start; the graph workflow samples under python/samples/03-workflows/ are the fastest way to judge whether the orchestration model matches your design. Skip it if you want a thin wrapper around one provider's chat API, since the framework's value sits in layers you would not use.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap MAF targets: prototypes that were never meant to stay prototypes
Most agent code starts as a loop around a chat completion call. That shape survives a demo and then breaks the moment you need two agents to hand work to each other, a human to approve a step, or a process that resumes after a restart. Microsoft Agent Framework, referred to throughout the repository as MAF, is aimed at that second stage. The README's own fit checklist is explicit: it lists production operation, orchestration beyond a single prompt or stateless chat loop, graph patterns such as sequential, concurrent, handoff and group collaboration, and concerns like durability, restartability, observability, governance and human-in-the-loop control. The intended audience is a team that has already decided agents belong in a real system and now needs a foundation that does not have to be rewritten when the provider or the topology changes. The framework ships for Python and C#/.NET with what the README describes as consistent APIs, and a separate Go SDK lives in its own repository, microsoft/agent-framework-go. That split matters: if Go is your target language, this repository is not where you will spend your time.
Agents, middleware and graph workflows: the three layers the README actually describes
The architecture visible in the material has three distinct layers, and they are worth separating because each one is adopted independently. The first is the agent itself, constructed against a provider, with Python examples under python/samples/02-agents/providers/ and .NET examples under dotnet/samples/02-agents/AgentProviders/. The second is middleware, described as a system for request and response processing, exception handling and custom pipelines, with samples at python/samples/02-agents/middleware/ and dotnet/samples/02-agents/Agents/Agent_Step11_Middleware/. The third is orchestration: graph-based workflows supporting sequential, concurrent, handoff and group collaboration, with checkpointing, streaming, human-in-the-loop and time-travel listed as features of that layer. The data flow implied by this arrangement is conventional in shape but consequential in placement. A request enters the agent, passes through middleware before and after the provider call, and the workflow graph decides which agent node runs next and where a checkpoint is written. Because middleware sits between the caller and the model, exception handling and retry policy live in one place rather than being duplicated per agent. Observability is handled through built-in OpenTelemetry integration for distributed tracing, monitoring and debugging, with samples at python/samples/02-agents/observability/ and dotnet/samples/02-agents/AgentOpenTelemetry/. The README does not describe span names, attribute schemas or exporter configuration, so treat the tracing story as something to inspect in those sample directories rather than something documented at this level.
Installation and the quickstart path in each language
Python installation is a single command: pip install agent-framework. The README notes that this installs the standard package set and that experimental modules live in a separate package, agent-framework-lab, under python/packages/lab/. It also warns that the first install on Windows may take a minute. That warning is worth reading literally: if you are scripting installs in CI, budget for it rather than assuming a timeout is a network fault. The .NET side is split across several packages. dotnet add package Microsoft.Agents.AI is the base, and the Foundry integration used in the README's .NET quickstart adds Microsoft.Agents.AI.Foundry, Azure.AI.Projects and Azure.Identity. The Python quickstart shown in the README builds an Azure Responses agent that writes a haiku about Microsoft, which tells you the default sample path runs against Azure rather than a local model. Two further surfaces are described but not fully specified: declarative agents defined in YAML, with samples under declarative-agents/, and Agent Skills, which the README describes as domain-specific knowledge bases built from files, inline code or class libraries, with the design recorded in docs/decisions/0037-agent-skills-design.md. If you want YAML-defined agents or a skills layer, read those two locations before writing code, because the README gives the pointer and not the schema.
Foundry hosting and what the two-line claim leaves out
The most concrete deployment claim in the README is that Foundry Hosted Agents let you deploy and host agents on Foundry-hosted infrastructure with two additional lines of code, with samples at python/samples/04-hosting/foundry-hosted-agents/ and dotnet/samples/04-hosting/FoundryHostedAgents/. Two lines is a claim about the code delta, not about the total work. It says nothing about what the surrounding project must contain, what authentication the hosting environment expects, or how state is carried between the hosted agent and the workflow checkpointing described elsewhere. The .NET package list for the Foundry quickstart (Microsoft.Agents.AI.Foundry, Azure.AI.Projects, Azure.Identity) suggests the hosting path is entangled with Azure project and identity configuration, which is consistent with a two-line change only after that configuration exists. Anyone evaluating this should read the hosting samples first and count the files, not the lines. The same caution applies to the DevUI, an interactive developer UI for agent development, testing and debugging that the README links to a video for rather than documenting in text. A debugging UI that is demonstrated in a video and not described in the README is a reasonable thing to try and an unreasonable thing to plan around.
Where MAF is the wrong choice
The framework's own fit list doubles as a disqualification list. If your agent is a single prompt against one provider with no branching, no human approval step and no restart requirement, the graph workflow layer, checkpointing and middleware pipeline are overhead you will carry without using. The README positions MAF for teams taking agents from prototype to production, and the feature set reflects that: time-travel, checkpointing and governance concerns are not features a prototype needs. There is a second, sharper limitation in the material itself. The README is a map of sample directories more than a specification. It tells you that checkpointing exists and that samples live under python/samples/03-workflows/, but it does not describe the checkpoint store interface, what gets serialised, or how resumption interacts with streaming. For a framework whose selling point is durability and restartability, that is a real gap in the front-door documentation, and it means your evaluation has to happen in the sample code. A third point: the multi-language promise is real for Python and .NET, and separate for Go. Teams that assumed one repository covers all three languages will find the Go SDK in microsoft/agent-framework-go with its own documentation, samples, contribution guidance and issue tracker.
Migration paths and the alternative worth comparing against
The README links two migration guides, one from Semantic Kernel and one from AutoGen, both hosted on Microsoft Learn. Their existence is the most useful signal in the repository for anyone choosing between frameworks, because it tells you which projects MAF expects to absorb. For a concrete alternative, consider Semantic Kernel on its own. The difference in approach is structural rather than cosmetic: Semantic Kernel is organised around plugins, functions and planners that you compose into a pipeline, while MAF is organised around agents as first-class objects plus a workflow graph that decides which agent runs next, with checkpointing and human-in-the-loop control attached to that graph. If your system is fundamentally a chain of functions with a model call inside one of them, Semantic Kernel's model matches the shape of the problem and MAF's graph adds a layer you would not populate. If your system is several agents passing work between each other with approval gates and resume-after-crash requirements, the graph is the thing you would otherwise build yourself, and the migration guide from Semantic Kernel exists precisely because teams move in that direction. The same reasoning applies to AutoGen: the guide is there for teams whose multi-agent conversations have outgrown the conversation model.
Release cadence, licence and what to check before you depend on it
The release history shows a fast cadence. In the recent window listed, python-1.18.0 landed on 2026-09-10, python-1.17.0 on 2026-09-03, and dotnet-1.20.0 on 2026-08-31. Python and .NET version numbers are tracked independently, so a Python 1.18 and a .NET 1.20 are not the same release, and the README's promise of consistent APIs across the two languages should be read as intent rather than as a guarantee that version numbers move together. A weekly Python cadence means you should pin versions in your dependency file rather than float, and read release notes before upgrading, because a minor bump on that schedule is not automatically a drop-in. The licence is MIT, which is permissive and places few obligations on how you redistribute or modify the code; that is a statement about the licence text, not legal advice, and anything involving hosted Foundry infrastructure or Azure services sits under separate terms that the repository does not cover. The framework is not archived and the default branch is main. Given how much of the operational story lives in samples rather than prose, the first thing to verify is narrow and concrete: open python/samples/03-workflows/, find the checkpointing example, and confirm the persistence mechanism matches the store you already run. If it does not, you are looking at adapter work before you are looking at agents.
Editorial conclusion
Adopt MAF if you are building multi-agent workflows in Python or .NET and you need checkpointing, human-in-the-loop control and provider flexibility from the start; the graph workflow samples under python/samples/03-workflows/ are the fastest way to judge whether the orchestration model matches your design. Skip it if you want a thin wrapper around one provider's chat API, since the framework's value sits in layers you would not use. Before committing, verify two things yourself: that the provider you depend on appears in python/samples/02-agents/providers/, and that the Foundry hosting path in python/samples/04-hosting/foundry-hosted-agents/ runs against your own subscription, because the README states that hosting costs two additional lines of code without documenting what those lines assume about your Foundry setup.
Community notes