If you have spent the last year weighing Semantic Kernel against AutoGen for an Azure project, I have annoying news. The choice is gone. In April 2026 Microsoft folded both projects into one SDK, Microsoft Agent Framework, and moved the two originals into maintenance mode. Bug fixes and security patches keep coming. New features do not. So the useful question for this part is not which of the two to adopt. It is how the merged framework works, and what a migration actually costs you.

Where Semantic Kernel and AutoGen came from

Two different teams built two different tools for two different jobs. Semantic Kernel was Microsoft’s open-source SDK for connecting large language models to real applications, with plugins, memory, planners, and strong typing aimed at production shops running .NET or Python. AutoGen came out of Microsoft Research as a framework for multi-agent conversations, meaning several model-backed agents that talk to each other to work through a task, and it was built for fast prototyping and experiments.

For a while the honest answer to which one to use was blunt. Pick Semantic Kernel if you were shipping to production and cared about typing, tracing, and support. Pick AutoGen if you were exploring agent-to-agent patterns and did not mind rough edges. Then Microsoft did the sensible thing and stopped making people choose. The preview landed in October 2025, a release candidate for both languages arrived on 19 February 2026, and 1.0 shipped in early April 2026 with a long-term support commitment.

What Microsoft Agent Framework replaces

Agent Framework is the successor to both. It takes AutoGen’s simple abstractions for single-agent and multi-agent patterns and bolts on the enterprise features Semantic Kernel was known for: session-based state management, type safety, filters, telemetry, and broad model and embedding support. One SDK, two lineages, one supported code path going forward.

It talks to models through providers rather than hard-wiring one vendor. Out of the box it supports Microsoft Foundry (the Azure agent and model platform covered in Part 2), Azure OpenAI, OpenAI directly, and the GitHub Copilot SDK. That provider layer matters for lock-in, and I come back to it below. The shape of the stack looks like this.

How an agent runs in the new SDK

The Python install is one line. The base package pulls in the sub-packages, including Azure OpenAI and OpenAI support plus the workflow engine. If you only want the Foundry integration you can install agent-framework-foundry instead. Python 3.10 through 3.14 is supported, and 3.11 or newer is what Microsoft recommends.

Here is a first agent that points at a Foundry project and answers one question. It runs as written once you set up a project and sign in with the Azure CLI.

# pip install agent-framework azure-identity
import asyncio
from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient  # import path [VERIFY]
from azure.identity import AzureCliCredential

async def main():
    client = FoundryChatClient(
        project_endpoint="https://your-project.services.ai.azure.com",
        model="gpt-4o",
        credential=AzureCliCredential(),
    )
    agent = Agent(
        client=client,
        name="HelloAgent",
        instructions="You are a friendly assistant. Keep answers brief.",
    )
    result = await agent.run("What is the capital of France?")
    print(result)

asyncio.run(main())

Expected output is a single short line, something like Paris. The failure you will hit first is authentication. If you have not run az login, or your identity has no role on the project, the call raises a credential error before the model is ever reached. For a stream instead of a single answer, call agent.run(…, stream=True) and read each chunk’s text as it arrives. That is the whole loop. No kernel to build first, no orchestrator to register.

Workflows for multi-agent orchestration

One agent answering a question is the easy part. The reason AutoGen existed was many agents cooperating, and that is where Agent Framework earns its keep with workflows. A workflow gives you explicit control over the execution path between agents, rather than the free-form back-and-forth conversation that AutoGen leaned on. You describe who runs, in what order, and what happens to the result, and the framework carries the state between steps.

That state system is the other half. Workflows support long-running jobs and human-in-the-loop steps, so a run can pause for a person to approve something and resume later without losing context. If you built a Foundry Agent Service agent back in Part 13, the single-agent shape carries over. Workflows are the layer you add on top when one agent is not enough. My advice is to resist reaching for them early. Most projects that think they need five agents actually need one agent and three tools.

Migrating a Semantic Kernel or AutoGen project

Microsoft published migration guidance alongside the release candidate, and the good news is that the concepts map cleanly. An AutoGen agent becomes an Agent Framework agent with the same idea behind it. A Semantic Kernel plugin becomes a tool. Your prompts, your model choices, and your business logic move over largely intact. What changes is the surrounding plumbing: how you construct the client, how settings are read, and the exact method names.

The Python settings model changed in particular. Earlier previews used pydantic settings classes, and the current SDK moved to typed dictionaries with an explicit load step. That is a mechanical edit, not a redesign, but it touches every file that read configuration. Budget a day for a small service and a week for anything with custom planners or heavy AutoGen group-chat logic.

Cost and lock-in trade-offs

The SDK itself is open source and free. Your bill is the model inference and, if you use it, the Foundry platform underneath. So the framework choice does not move your token costs. What it moves is your exposure. Because Agent Framework routes through providers, the same agent can point at Azure OpenAI today and plain OpenAI tomorrow with a client swap, which keeps one door open.

The lock-in that does bite is the Foundry-specific surface. The moment your agents lean on Foundry agent features, Foundry tools, and Foundry threads, moving off Azure stops being a client swap and becomes a rewrite. That is a fair trade for the tooling if you are committed to Azure, and a trap if you are hedging. Decide which you are before you build, not after.

Where teams get burned on the migration

The most common mistake is reading maintenance mode as permission to never move. Maintenance means security patches, not feature parity. Every new model integration, every new orchestration pattern, every fix that is not a security fix now lands in Agent Framework and not in Semantic Kernel or AutoGen. Staying put is a decision to fall behind on a schedule you do not control.

The second burn is subtler. Teams port the happy path, the agent that answers, and quietly drop the filters, the telemetry wiring, and the retry logic the old service had accreted over a year. The new agent works in a demo, then falls over the first time a tool times out in production, because nobody carried across the guardrails. Treat the boring parts as part of the migration, not as a follow-up you will get to later. The other thing I pin is the SDK version itself. The framework is young and still moving, and a minor release can shift a default under you. Pin an exact version in production, read the change notes before you bump it, and bump on your schedule rather than letting a fresh install pull whatever is newest on the day your build happens to run.

Observability you inherit from Semantic Kernel

One of the quieter wins in the merge is tracing. AutoGen gave you agents that talked, but watching what they did in production was largely your problem. Semantic Kernel brought structured telemetry, and Agent Framework keeps it. Runs emit OpenTelemetry spans, which are timed records of each step, so every model call, tool call, and workflow hop shows up in the same tracing backend you already use for the rest of your services. Send traces to Azure Monitor and agent activity lands next to your API latency and error rates, not in a separate silo.

That matters more than it sounds. The hardest thing about running agents in production is answering a simple question after something goes wrong: what did the agent actually do. Without spans you are reading log lines and guessing. With them you can see the exact tool the agent chose, the arguments it passed, and how long each hop took. When a workflow stalls, the trace tells you which step stalled instead of leaving you to bisect the code by hand.

Filters are the other inherited piece. A filter is a hook that runs before or after a model or tool call, and it is where the cross-cutting logic lives that does not belong inside the agent: redacting sensitive fields before they reach a model, blocking a tool call that fails a policy check, or capturing a prompt for later review. In Semantic Kernel these were a core pattern, and porting them is mostly a rename rather than a rethink.

Tool calling deserves a word too. A tool here is a plain function you expose to the agent, and the model decides when to call it. Keep tools small and single-purpose. An agent with one clear database tool and one clear search tool behaves far better than an agent handed a single do-everything function with ten optional arguments. The model reasons about tools by their names and descriptions, so a vague description is a bug, not a cosmetic issue. Write them as if a new teammate had to pick the right one from the name alone.

Where Agent Framework fits, and where I would wait

For anything new, I start on Agent Framework and do not look back. It is GA, it is supported, and it is where the features land. The old Semantic Kernel versus AutoGen debate is a historical footnote now, and choosing either for a greenfield project in 2026 means building on a base that only gets security fixes.

Where I would wait is a large, stable, in-production Semantic Kernel service that is meeting its goals. There is no fire. Plan the migration, get it on the roadmap for the next quarter or two, and move when you have test coverage and a quiet window, not because a blog told you to rush. The framework will still be there. What you should not do is start a new agent on a maintenance-mode SDK to save a week of learning. That week comes back with interest. If you want the next layer up, Part 22 takes this into Microsoft Copilot Studio, where the same agent ideas meet a low-code builder. Read that before you decide how much to hand-code.

For a contrast in how another cloud frames agents, compare this with the supervisor-and-collaborator model in the AWS Bedrock multi-agent approach. Same problem, different shape.

References

Microsoft Agent Framework overview (Microsoft Learn)
Migrating Semantic Kernel and AutoGen projects (Microsoft DevBlogs)
microsoft/agent-framework (GitHub)
agent-framework (PyPI)

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts