Microsoft Agent Framework is the open source .NET and Python agent SDK that Microsoft describes as the successor to both AutoGen and Semantic Kernel, and moving to it means relearning agents, tools, state and orchestration rather than renaming imports. AutoGen's repository is now archived, Semantic Kernel's repository opens by saying it "is now Microsoft Agent Framework", and Agent Framework reached version 1.0 on 3 April 2026. This explainer sets out what changes for each source framework, concept by concept, which packages replace which, what has no equivalent yet, and how to plan the move. It is written for developers and architects who own AutoGen or Semantic Kernel code, and for the people who approve the migration. Every fact comes from Microsoft's migration guides, the three GitHub repositories and Microsoft's own blog posts. Last checked: 2026-11-15.
This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.
Key takeaways
- Two predecessors, one destination. Microsoft's February 2026 release candidate post calls Agent Framework "the successor to Semantic Kernel and AutoGen", and both older repositories now point new users to it.
- The support positions differ. AutoGen is archived with no bug fixes or security fixes; Semantic Kernel v1.x keeps receiving critical bug and security fixes for at least one year after Agent Framework general availability.
- Agents become stateless. In Agent Framework, conversation state lives in a session that the agent creates, not inside the agent (AutoGen) or in a caller-created thread type (Semantic Kernel).
- Multi-agent code is rewritten, not ported. AutoGen teams and GraphFlow map to typed, data-flow workflows built with
WorkflowBuilderand orchestration builders; Swarm and SelectorGroupChat have no equivalent yet. - Incremental paths exist for Semantic Kernel. The
as_agent_framework_tool()bridge (semantic-kernel 1.38 or later) lets existing Kernel functions run as Agent Framework tools while agents move first.
What is changing, and why it matters
Microsoft built two agent projects in parallel. AutoGen began as a research framework for multi-agent conversation; its 0.4 line split into autogen-core, autogen-agentchat and autogen-ext. Semantic Kernel (SK) was the enterprise SDK, available for .NET, Python and Java, organised around a Kernel object that holds services and plugins. Microsoft Agent Framework (MAF) merges the two: Microsoft's 1.0 announcement says it combines Semantic Kernel's enterprise foundations with AutoGen's orchestration patterns, for .NET and Python, with a separate Go SDK repository.
For a team this is three kinds of change at once: a dependency change (new packages and namespaces), a programming model change (no Kernel, stateless agents, typed workflows) and a support change (the old code base stops getting fixes on different schedules). Treat it as a planned project with an owner and a date. For a product-level view of the destination, see the Microsoft Agent Framework page; this page covers only the move.
Status and timeline
The dates below are the ones Microsoft's own pages state. Neither AutoGen nor Semantic Kernel has a published end-of-life date in the sources checked.
| Date | Event | Source |
|---|---|---|
| 7 October 2025 | Microsoft announces Agent Framework as building on Semantic Kernel and AutoGen; commits to SK v1.x support for at least one year after MAF general availability | Agent Framework blog: Semantic Kernel and Microsoft Agent Framework |
| 19 February 2026 | Release candidate for .NET and Python; Microsoft says the API surface is stable and all intended 1.0 features are complete, and urges SK and AutoGen users to migrate | Semantic Kernel blog: release candidate migration post |
| 3 April 2026 | Version 1.0: "stable APIs, and a commitment to long-term support"; release candidate users upgrade with a version bump | Agent Framework blog: version 1.0 |
| Checked 15 November 2026 | AutoGen repository carries an archived banner: no bug fixes, security fixes, new features or support | microsoft/autogen README |
| Checked 15 November 2026 | Semantic Kernel repository: "Semantic Kernel is now Microsoft Agent Framework!", linking the SK migration guide | microsoft/semantic-kernel README |
Table as of 15 November 2026. On PyPI at that date the latest agent-framework version was 1.26.0, the latest semantic-kernel version was 1.47.0, and the latest autogen-agentchat release was 0.7.5, uploaded on 30 September 2025.
What 1.0 covers: the announcement lists as stable single agents and service connectors (Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini, Ollama), middleware, memory and context providers, graph workflows with checkpointing, the sequential, concurrent, handoff, group chat and Magentic-One orchestrations, declarative YAML agents, MCP and A2A support, and migration assistants. It lists as preview DevUI, Foundry hosted agents, AG-UI, CopilotKit and ChatKit adapters, Skills, and the Agent Harness. Only the stable set carries the backward compatibility commitment.
Packages and namespaces: what replaces what
| Area | AutoGen | Semantic Kernel | Agent Framework |
|---|---|---|---|
| Python install | autogen-agentchat, autogen-ext[openai] | semantic-kernel with provider extras | agent-framework (meta package over agent-framework-core) |
| Python import | autogen_agentchat, autogen_core, autogen_ext | semantic_kernel | agent_framework, with provider modules such as agent_framework.openai and agent_framework.foundry |
| .NET | Not applicable (Python framework) | Microsoft.SemanticKernel, Microsoft.SemanticKernel.Agents | Microsoft.Agents.AI, plus Microsoft.Extensions.AI for message and content types |
| Orchestration | Teams in autogen_agentchat.teams | Agent orchestration in SK agents | agent-framework-orchestrations; Microsoft.Agents.AI.Workflows in .NET |
| Licence | All three repositories are published by Microsoft on GitHub; the Agent Framework repository carries the MIT licence | ||
Agent Framework splits providers and integrations into separate Python packages, each with its own lifecycle state in the repository's python/PACKAGE_STATUS.md (alpha, beta, rc, released, deprecated). On 15 November 2026 that file listed agent-framework-core, agent-framework-openai, agent-framework-foundry and agent-framework-orchestrations as released, and the Anthropic, Bedrock, Gemini, Ollama, Mistral and A2A packages as beta. Check it before you pin versions, because a plain pip install agent-framework pulls in beta packages too.
Semantic Kernel to Agent Framework: the concept map
Microsoft's SK migration guide describes seven shifts. The table puts them side by side for both languages.
| Concept | Semantic Kernel | Agent Framework |
|---|---|---|
| Kernel | Agents require a Kernel (empty by default) holding services and plugins | No Kernel; agents are built from a chat client, for example chatClient.AsAIAgent(...) or client.as_agent(...) |
| Agent types | ChatCompletionAgent, OpenAIAssistantAgent, AzureAIAgent | .NET: one ChatClientAgent over any IChatClient. Python: Agent, plus CopilotStudioAgent, A2AAgent and BaseAgent |
| Functions | [KernelFunction] or @kernel_function, wrapped in a plugin and added to the Kernel | Tools passed at agent creation: AIFunctionFactory.Create(...) in .NET, @tool or plain functions in Python; no plugin wrapper |
| Conversation state | Caller creates a thread type, such as ChatHistoryAgentThread or AzureAIAgentThread | Agent creates an AgentSession: CreateSessionAsync() or create_session() |
| Deleting state | thread.DeleteAsync() | No delete on the session; delete through the provider SDK |
| Invocation | InvokeAsync / invoke, streaming via InvokeStreamingAsync / invoke_stream | RunAsync / run returning one AgentResponse; streaming via RunStreamingAsync or run(..., stream=True) |
| Settings | OpenAIPromptExecutionSettings inside KernelArguments | ChatClientAgentRunOptions (.NET); TypedDict options via default_options and options (Python) |
| Dependency injection | Register the Kernel and pass it to each Agent | Register AIAgent directly |
The bridge: in Python, as_agent_framework_tool() converts SK prompt functions, decorated @kernel_function methods and vector store search functions into Agent Framework tools. It needs semantic-kernel 1.38 or later. This is what makes an agents-first, plugins-later migration possible. The SK guide also notes that OpenAI Assistants is deprecated in favour of the Responses API, which matters if your SK code uses OpenAIAssistantAgent.
AutoGen to Agent Framework: the concept map
The AutoGen migration guide is Python only, because AutoGen 0.4 is a Python framework. Its mapping for single agents:
| Concept | AutoGen | Agent Framework |
|---|---|---|
| Agent | AssistantAgent(name, model_client, system_message, tools, max_tool_iterations) | Agent(name, client, instructions, tools, default_options) |
| Turn behaviour | Single tool iteration by default; raise max_tool_iterations to loop | Keeps calling tools until it reaches a final answer |
| State | Held in the agent (ChatCompletionContext) | Agent is stateless; pass session=agent.create_session() |
| Model clients | OpenAIChatCompletionClient, AzureOpenAIChatCompletionClient, AzureAIChatCompletionClient | OpenAIChatCompletionClient, OpenAIChatClient (Responses API), FoundryChatClient |
| Messages | TextMessage, MultiModalMessage with a string source | Message(role, contents) with Content items and a role enum |
| Function tool | FunctionTool(func, description) | @tool, schema inferred from type hints |
| Agent as tool | AgentTool, with parallel_tool_calls=False on the coordinator | agent.as_tool(...), no workaround needed |
| MCP | Basic support through extensions | MCPStdioTool, MCPStreamableHTTPTool |
| Streaming | agent.run_stream(task) | agent.run(..., stream=True) |
| Custom agent | BaseChatAgent.on_messages | BaseAgent.run returning AgentResponse or a stream |
| Tracing | tracer_provider on the runtime | configure_otel_providers() or the OTEL_EXPORTER_OTLP_ENDPOINT variable |
The change in turn behaviour is the one most likely to surprise in testing. An AutoGen agent that stopped after one tool call will, once ported, keep calling tools until it decides it is finished, so cost, latency and the number of tool side effects can all rise.
Orchestration: from teams and group chats to workflows
AutoGen's multi-agent model broadcasts messages between agents in a team. Agent Framework's model is a single typed Workflow: executors (agents, functions marked @executor, Executor subclasses or nested workflows) receive typed messages along edges and run when their inputs are ready. The migration guide calls GraphFlow control flow and Workflow data flow.
| AutoGen pattern | Agent Framework equivalent | Note |
|---|---|---|
RoundRobinGroupChat | SequentialBuilder(participants=[...]) | Termination conditions become workflow logic |
| No direct equivalent | ConcurrentBuilder | Fan-out, fan-in across agents |
MagenticOneGroupChat | MagenticBuilder with round, stall and reset limits and optional plan review | Limits are explicit parameters |
DiGraphBuilder / GraphFlow | WorkflowBuilder(start_executor=...).add_edge(a, b) | Typed routing instead of broadcast |
| Team as a participant | WorkflowExecutor | Isolated input and output, no broadcast |
Swarm, SelectorGroupChat | None yet (on the roadmap) | Redesign, often as handoff or group chat orchestration |
GrpcWorkerAgentRuntime (experimental) | None: single process today | Distributed designs need another approach |
Semantic Kernel users meet the same workflow model. The SK migration guide does not map SK's agent orchestration classes or its filters, so read the Agent Framework workflow and middleware documentation directly for those.
What is new, and what is not there yet
New with no predecessor: the AutoGen guide lists the Responses API clients, hosted tools such as get_code_interpreter_tool() and get_web_search_tool() (subject to provider and model entitlements), middleware that can block a call by not calling call_next(), human-in-the-loop requests with ctx.request_info() and @response_handler, and checkpointing with FileCheckpointStorage, which saves executor state, shared state, pending messages and workflow position and re-emits pending requests on resume.
Gaps to plan around: the AutoGen guide lists local code execution, a caching wrapper, Swarm, SelectorGroupChat and a distributed runtime as planned, and states that MCP WebSocket transport and MCP Tasks are not supported. It also marks Anthropic and Ollama clients as planned, while the repository's package status file already lists agent-framework-anthropic and agent-framework-ollama as beta packages; check both pages for the provider you need. AutoGen's OpenAIAssistantAgent has no Assistants-specific replacement: use the Responses client or FoundryAgent.
If your design depends on one of these gaps, the realistic options are to redesign around what exists, to wait with the old framework pinned and contained, or to evaluate a different framework. The AI Agent Frameworks and Platforms Hub lists the alternatives.
Where AG2 fits
AG2 is often confused with this migration. It is a community fork of AutoGen maintained by volunteers from several organisations, and it is not a Microsoft product. Its README says that as of AG2 v1.0 the ag2 package no longer ships the autogen import name or the classic ConversableAgent and GroupChat classes, which now live in a separate AG2 Classic repository that is still maintained. If your code imports autogen and uses ConversableAgent, check which project you actually installed before choosing a path: Microsoft's migration guide maps AutoGen 0.4 AgentChat classes, not AG2 classes. See What Is AG2? The Community Fork of AutoGen.
How to plan the migration
- Inventory. List every application, its framework and version, Python or .NET runtime, model providers, tools and plugins, MCP servers, state stores and credentials. Record which AutoGen patterns (Swarm, SelectorGroupChat, distributed runtime, local code execution) each uses, since those block a straight port.
- Choose the order. Archived AutoGen code goes first, because it no longer receives security fixes. SK code can follow, using the bridge to move agents before plugins.
- Pin and contain the old version. Freeze AutoGen and SK dependency versions and keep SK patched. The Microsoft Agent Framework and AutoGen security guide and the Semantic Kernel Security Guide cover the containment and control steps; this page does not repeat them.
- Rebuild one agent. Create the agent from a chat client, register tools explicitly, add a session, and set options. Re-derive the tool list from need rather than copying every plugin.
- Rebuild orchestration. Map each team or group chat to a builder or a
WorkflowBuildergraph, adding explicit termination, human approval and checkpointing where the old design relied on conventions. - Test side by side. Run old and new versions on the same inputs with OpenTelemetry on, and compare answers, tool calls, token use and latency. Watch especially for the extra tool iterations described above.
- Cut over and keep a dated rollback. Keep the previous deployment runnable for an agreed window, then remove the old packages from the build and the software bill of materials.
Decision guidance
| Situation | Factual considerations |
|---|---|
| AutoGen in production | No security fixes from Microsoft; the README advises against production use. Migration or a documented risk acceptance with containment is needed. |
| AutoGen prototype or research code | Lower urgency; consider rewriting only what survives into production. |
| SK on .NET or Python | Supported with critical and security fixes for at least one year after MAF general availability; most new features go to MAF. Migrate on a planned date, bridging plugins. |
| SK on Java | The migration guide covers .NET and Python only; Agent Framework is published for .NET and Python, with Go in a separate repository. |
| Design depends on Swarm, SelectorGroupChat or a distributed runtime | No Agent Framework equivalent as of November 2026; redesign or wait with the old version contained. |
| Small team, few agents | A direct rewrite of each agent is often quicker than incremental bridging. |
| Large estate | Use the migration assistants named in the 1.0 post, migrate by application, and track progress in the inventory. |
Measuring progress
- Coverage: share of agent applications running on Agent Framework, by environment.
- Residual risk: number of production deployments still importing
autogen_agentchat,autogen_coreorsemantic_kernel, from dependency scans. - Behaviour parity: share of regression test tasks with matching outcomes between old and new versions.
- Tool call drift: change in average tool calls and tokens per task after cutover.
- Prerelease exposure: number of beta or alpha Agent Framework packages in production builds.
Common failure patterns
- Treating it as an import rename: the programming model changes, so search-and-replace ports break at runtime, usually around state.
- Losing conversation memory: agents are stateless, so code that never passes a session silently answers each call without history, as Microsoft's own two-question example shows.
- Unbounded tool loops: ported AutoGen agents now loop until a final answer, raising cost and repeating side effects.
- Orphaned hosted state: SK code that deleted threads now needs provider SDK calls, or hosted conversations accumulate.
- Beta packages in production by default: the meta package installs beta integrations; pin the packages you need.
- Confusing AG2 with AutoGen: following Microsoft's guide for AG2 Classic code, or the reverse.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-22 Unsupported System Components | Archived AutoGen, and SK once its support window closes |
| NIST SP 800-53 Rev 5 | CM-8 System Component Inventory | Inventory of frameworks, packages and versions |
| NIST SP 800-53 Rev 5 | CM-3 Configuration Change Control | The migration as a controlled change with rollback |
| NIST SP 800-53 Rev 5 | SA-11 Developer Testing and Evaluation | Side-by-side regression testing |
| NIST CSF 2.0 | ID.AM-02 | Software inventory that shows where old frameworks remain |
Practitioner checklist
- Inventory every AutoGen and Semantic Kernel application, with versions, providers, tools and state stores.
- Flag AutoGen code that uses Swarm, SelectorGroupChat, the distributed runtime or local code execution.
- Migrate production AutoGen first; record a risk acceptance for anything that must wait.
- Upgrade SK to 1.38 or later before using the
as_agent_framework_tool()bridge. - Pass a session on every multi-turn call and test that history persists.
- Set explicit limits and approvals for tool loops that used to stop after one call.
- Check
PACKAGE_STATUS.mdand pin released packages for production. - Replace SK thread deletion with provider SDK deletion and test it.
- Run old and new versions side by side with OpenTelemetry before cutover, and keep a dated rollback.
Standards and references
- Microsoft Learn: AutoGen to Microsoft Agent Framework migration guide
- Microsoft Learn: Semantic Kernel to Agent Framework migration guide
- Microsoft Agent Framework blog: Microsoft Agent Framework version 1.0
- Microsoft Semantic Kernel blog: Migrate your Semantic Kernel and AutoGen projects to Microsoft Agent Framework release candidate
- Microsoft Agent Framework blog: Semantic Kernel and Microsoft Agent Framework
- GitHub: microsoft/autogen README
- GitHub: microsoft/agent-framework Python package status
- GitHub: ag2ai/ag2 README
Related NHI Mgmt Group resources: Microsoft Agent Framework · Microsoft Agent Framework and AutoGen security guide · Semantic Kernel Security Guide · AI Agent Frameworks Timeline · Securing Agent Frameworks Guide