Microsoft Agent Framework
Microsoft Agent Framework is an open-source SDK for building AI agents and graph-based multi-agent workflows in .NET and Python, with Go in preview. It is the direct successor to Semantic Kernel and AutoGen, works with many model providers, and reached version 1.0 on 3 April 2026.1
Also known as Agent Framework, MAF, Successor to Semantic Kernel and AutoGen
- Intended for
- Application and AI developers in .NET, Python or Go, Teams migrating from Semantic Kernel or AutoGen, Solution architects designing multi-agent systems
- Runs on
- Open-source library (MIT) in your own application, Microsoft Foundry Agent Service hosted agents, Any environment that runs .NET, Python or Go
At a glance
- What is it?
- Agent Framework is a code library, released under the MIT license on GitHub, that Microsoft describes as the next generation of both Semantic Kernel and AutoGen, built by the same teams. It combines AutoGen's simple agent abstractions with Semantic Kernel's enterprise features, such as session-based state, type safety, middleware and telemetry, and adds workflows for explicit multi-agent execution paths. Version 1.0 for .NET (Microsoft.Agents.AI) and Python (agent-framework) shipped on 3 April 2026 with stable APIs and a long-term support commitment. The Go version lives in a separate repository and is in public preview.123
- What does it do?
- Developers create agents that call a language model, use tools and MCP servers, keep conversation state in sessions, and remember context through context providers. Middleware can intercept agent actions, for example for content safety or logging. Workflows connect agents and functions in explicit graphs with sequential, concurrent, handoff and group chat patterns, checkpointing for long-running processes, and human-in-the-loop steps. Agents and workflows can be defined in YAML. OpenTelemetry integration supports tracing. A Harness Agent adds planning, todo tracking, context compaction, file access and memory for long multi-step tasks.12
- Who needs it?
- Developers who want to write agent logic in code, choose their own model provider and keep it in source control, rather than use a low-code studio. Teams with Semantic Kernel or AutoGen code should look at it because Microsoft positions it as the forward path and publishes migration guides. Microsoft Foundry also recommends it for new workflow development because Foundry workflows retire on 1 December 2026.14
- What does it need?1
- .NET (NuGet package Microsoft.Agents.AI, plus Microsoft.Agents.AI.Foundry for Foundry), Python (pip install agent-framework) or Go (github.com/microsoft/agent-framework-go, preview)
- Access to a model provider, for example a Microsoft Foundry project endpoint, Azure OpenAI, OpenAI, Anthropic or a local Ollama model
- Credentials for that provider, such as Azure CLI credentials for Foundry
- In Python, environment variables set explicitly or loaded with load_dotenv(), since .env files are not loaded automatically
- Your own responsible AI measures, such as content filters and testing, which Microsoft says remain the developer's responsibility
- What it is not
- Agent Framework is not a hosted service: it is a library, and you run the resulting app yourself or deploy it, for example as a Foundry hosted agent. It is not a model or a model catalog; it connects to providers such as Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic and Ollama. It is not the Microsoft 365 Agents SDK, which handles channel plumbing for Teams, Copilot and other surfaces rather than agent reasoning. It is not a low-code tool like Copilot Studio. Microsoft also warns that if a plain function can do the task, you should not use an agent at all.15
Availability and licensing. Open source under the MIT license; no license fee for the framework itself (model and hosting costs apply). Version 1.0 for .NET and Python was released on 3 April 2026 with stable APIs. The Go version is in public preview (checked 26 Oct 2026). At 1.0, Microsoft listed DevUI, Foundry hosted agent integration, skills and the agent harness as preview features. Foundry workflows retire on 1 December 2026, and Microsoft recommends Agent Framework for new development.3
The problem it solves
Microsoft previously offered two overlapping open-source agent projects: Semantic Kernel, with enterprise features, and AutoGen, a research-led multi-agent toolkit. Developers had to choose between them or combine them.
Agent Framework merges both lines into one supported SDK with stable APIs from version 1.0, and adds graph-based workflows with checkpointing for processes that need explicit control. It stays model-agnostic, so the same code can target Foundry, OpenAI, Anthropic or local models.
How it works
Microsoft describes four primary areas:
- Agents: individual agents that use language models to process input, call tools and MCP servers, and respond.
- Harness Agent: an opinionated agent for long tasks, with planning, todo tracking, context compaction, file access, memory, tool approval and observability.
- Workflows: functional and graph-based workflows that connect agents and functions through explicit execution paths, with checkpointing and human-in-the-loop support.
- Integrations: model providers, agent services, tools, context providers, middleware, evaluation services and UI frameworks.
Underneath are model clients (chat completions and responses), agent sessions for state, context providers for memory, middleware and MCP clients. Agents can be hosted on Foundry Agent Service as hosted agents, which run your code in a container with a managed endpoint and Entra identity.16
Diagram as a list
Agents & automation
- AgentsCall models, use tools and respond
- Harness AgentOpinionated agent for long multi-step tasksConnects to Agents
- Workflows (graph-based)Explicit execution paths across agents and functions with checkpointingConnects to Agents
AI models & platform
- Model clients (Foundry, Azure OpenAI, OpenAI, Anthropic, Ollama and others)Chat completions and responses calls to the chosen provider
Data & analytics
- Sessions, context providers and middlewareState, memory and interception of agent actions
Developer tools
- Your application or serviceCode that creates and runs agents and workflows
- Tools and MCP serversFunctions and external tools the agent can call
Cloud & hybrid infrastructure
- OpenTelemetry tracingDistributed tracing and monitoring of agent runs
- Foundry Agent Service hosted agentsOptional managed hosting with endpoint, scaling and Entra identityConnects to Your application or service
Capabilities
Agents with many model providers13
Agents call language models, tools and MCP servers through model clients for Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic, Ollama and other providers; the 1.0 release lists Amazon Bedrock and Google Gemini connectors too.
Why it matters: The same agent code can move between providers.
Limits: Using third-party servers, agents or non-Azure models is at your own risk and under their terms, and data may leave your Azure compliance boundary.
Graph-based workflows13
Workflows connect agents and functions through explicit execution paths with sequential, concurrent, handoff, group chat and Magentic-One patterns, plus checkpointing and human-in-the-loop control.
Why it matters: Fits processes that need defined order and recovery, not just open-ended chat.
Limits: Go does not yet support declarative agents, RAG, CodeAct or functional workflows.
Sessions, memory and middleware3
Agent sessions manage state, context providers supply memory such as history, key-value state and vector retrieval, and middleware intercepts agent actions.
Why it matters: Adds the state handling and control points production apps need.
Limits: You choose and run the storage backends yourself.
Harness Agent13
An opinionated agent for long multi-step tasks with planning, todo tracking, context compaction, file access, memory, tool approval and observability.
Why it matters: Gives a ready structure for coding-agent style tasks.
Limits: The 1.0 announcement in April 2026 listed the agent harness among preview features that may change.
Declarative YAML and observability23
Agents and workflows can be defined in version-controlled YAML, and built-in OpenTelemetry integration supports tracing and monitoring.
Why it matters: Supports code review, CI and standard monitoring tools.
Limits: You still need a backend to collect and view traces.
Migration from Semantic Kernel and AutoGen3
Microsoft publishes migration guides and migration assistants for both predecessor projects.
Why it matters: Protects earlier investment in either framework.
Limits: Migration is still a code change; plan and test it rather than expect a drop-in swap.
Practical use cases
A team runs a Semantic Kernel or AutoGen prototype and needs a supported path to production.
- Approach
- Follow Microsoft's migration guide to Agent Framework 1.0 and add workflows with checkpointing for long-running steps.
- Role of Microsoft Agent Framework
- Agent Framework replaces both predecessor libraries with stable APIs.
- Data, infrastructure and skills
- Developers in .NET or Python and test coverage for the existing agent.
- Type of benefit
- Long-term maintainability
- Caveats
- Some features, such as DevUI and parts of Foundry integration, were preview at 1.0.
- First step
- Port one agent and compare its behavior against the original on recorded test cases.
An insurer needs a claims process where several specialized agents hand work to each other with a human approval step.
- Approach
- Model the process as an Agent Framework workflow with handoff and human-in-the-loop steps, and host it as a Foundry hosted agent.
- Role of Microsoft Agent Framework
- Agent Framework provides the workflow engine; Foundry provides hosting and identity.
- Data, infrastructure and skills
- A Foundry project, models and the systems the agents must call.
- Type of benefit
- Controlled automation
- Caveats
- Microsoft advises testing a single agent first unless the case clearly needs several.
- First step
- Build one agent for intake and add the workflow once it performs reliably.
A company is building new agent workflows in Foundry's workflow designer.
- Approach
- Build new workflows in Agent Framework instead, because Foundry retires its workflows on 1 December 2026.
- Role of Microsoft Agent Framework
- Agent Framework is Microsoft's recommended replacement for new workflow development.
- Data, infrastructure and skills
- Developer time to express workflows in code or YAML.
- Type of benefit
- Avoiding rework
- Caveats
- Existing Foundry workflows need migration before the retirement date.
- First step
- Inventory current Foundry workflows and read the migration guide.
Works with
Optional integration
- Microsoft Foundry Agent ServiceAgent Framework code can run as a Foundry hosted agent.
- Microsoft FoundryFoundry is a first-party model provider with a dedicated Foundry package.
- Microsoft Foundry ModelsAgents call models deployed in Foundry or Azure OpenAI.
Complementary tools
- Microsoft 365 Agents SDKThe Agents SDK lets developers bring their own orchestrator for Microsoft 365 channels.
- Microsoft FoundryHosted agents can run Agent Framework code; Microsoft points workflow users to Agent Framework.
Alternative approaches
- Microsoft Copilot StudioCopilot Studio is the low-code route; Agent Framework is the code-first route.
Optional integration for
- Azure AI SearchFoundry IQ knowledge bases can be used from Microsoft Agent Framework.
- Microsoft Foundry Agent ServiceHosted agents can run Agent Framework code, and Microsoft directs workflow users to Agent Framework.
Relationship labels follow Microsoft's documentation. "Alternative approaches" does not mean one is better: each profile says when it fits.
Compared with
Getting started
Install the package
Run pip install agent-framework for Python, or dotnet add package Microsoft.Agents.AI.Foundry for .NET; for Go use go get github.com/microsoft/agent-framework-go.
Check: The package imports without errors in a new project.
Connect a model
Point a model client at your provider, for example a Foundry project endpoint with Azure CLI credentials and a deployed model.
Check: A minimal agent returns an answer to a test question.
Add a tool and state
Register a function tool or MCP server and use an agent session for multi-turn conversation.
Check: The agent calls the tool when asked and remembers the previous turn.
Add tracing
Enable the OpenTelemetry integration and send traces to your monitoring backend.
Check: Each agent run appears as a trace with model and tool calls.
Decide hosting
Run the app on your own infrastructure or deploy it as a Foundry hosted agent.
Check: The agent responds from its deployed endpoint.
Official resources
Deciding whether you need it?
Three free tools apply Microsoft's own published guidance to your situation, and say when Microsoft Agent Framework or any new technology is not needed.
Sources
Each statement above links to the source it comes from. Labels say who reported it.
- Microsoft Agent Framework overview (opens in a new tab)
- microsoft/agent-framework (GitHub) (opens in a new tab)
- Microsoft Agent Framework version 1.0 (Microsoft Foundry Blog, 3 April 2026) (opens in a new tab)
- Microsoft Foundry portal general availability overview (opens in a new tab)
- What is the Microsoft 365 Agents SDK (opens in a new tab)
- What is Microsoft Foundry Agent Service? (opens in a new tab)
- Custom engine agents for Microsoft 365 (opens in a new tab)
- Technology plan for AI agents (Cloud Adoption Framework) (opens in a new tab)
Thank you. Your correction was sent.
The editors check it against the sources. If you left an email address, they may reply about it.