Two research projects converged into one enterprise SDK.

I run platform reviews for a LegalTech shop, which means I do not get excited about a new SDK until I know who maintains it in three years and what it costs me to move off the thing I already run. So when a client asks me about Microsoft's agent story, I do not start with the API. I start with the awkward fact that for most of the last two years Microsoft shipped two agent stacks that did not agree with each other: AutoGen, the research-flavored multi-agent conversation framework, and Semantic Kernel, the enterprise middleware kit with the type safety and telemetry. Two answers to one question is not a strategy. It is a fork you eventually have to pay for.

A cyanotype-style blueprint schematic showing two lineage lanes, AutoGen for multi-agent conversation loops and Semantic Kernel for enterprise middleware, converging through a junction into a single labeled module marked Microsoft Agent Framework 1.0, drawn with dimension lines and registration marks on a faint measurement grid in navy and cyan. — The whole story on one sheet: two research lineages routed into a single supported SDK. The left lanes are where Microsoft learned the lessons. The merged module on the right is what you actually build against now. The interesting engineering is in the junction, not the boxes.

The merger is real and it has a date. In GitHub Discussion #7066 the AutoGen maintainers stated it plainly: "AutoGen and Semantic Kernel are merging into a single, unified framework under the name Microsoft Agent Framework." Microsoft's own overview is blunter still, calling the Agent Framework "the next generation of both Semantic Kernel and AutoGen." Then the part that should set your roadmap: per the 1.0 GA writeup, the unified framework (call it MAF) reached 1.0 GA in early April 2026 across .NET and Python, and the two legacy stacks entered maintenance mode, bug and security fixes only.

I want to be precise about what maintenance mode means for planning, because the marketing language is gentle and the budget consequence is not. It means no new features on AutoGen or Semantic Kernel. It means the runway is finite. And it means that the moment a client tells me "we standardized on AutoGen last year," I am no longer evaluating a framework, I am scoping a migration. That is not a complaint. A forced convergence is often the healthiest thing that can happen to a vendor's agent story. But you should price it in with eyes open, so let me walk the lineage the way I would in a design review.

The lineageTwo research bets, one supported SDK

Start with what each side was actually good at, because MAF is not a rewrite that throws the lessons away. It is a merger that keeps them. AutoGen was conversation-centric: simple agent abstractions, group chat between agents, the Magentic-One orchestration patterns, the stuff that made multi-agent prototypes feel alive in a notebook. Semantic Kernel was the enterprise half: a middleware pipeline you could insert policy into, session state, first-class OpenTelemetry, a stable of model connectors. One was fun to demo. The other was safe to deploy. Neither was both.

So the honest framing of MAF 1.0 is not "new framework." It is "the merge of the conversational ergonomics from one side and the production plumbing from the other, finally under one support contract." Figure 1 is how I draw that for a steering committee.

Figure 1 · The lineage

AutoGen plus Semantic Kernel, converging into MAF 1.0 GA

The dashed amber box is the part that sets your timeline. The two lanes on the left are where the lessons came from. The merged module on the right is the only one getting new features. If your team lives in either left lane today, you are on a clock, and the clock is the reason this article exists.

If you want the one-line version to paste into a planning doc, the sources give a clean text lineage that I have stolen wholesale because it reads better than anything I would draw twice.

Figure 2 · The merge, as text

One block to paste into the roadmap

# Microsoft agent lineage
AutoGen (multi-agent loops) ─┐
                             ├──► Microsoft Agent Framework 1.0 (Apr 2026)
Semantic Kernel (enterprise) ┘     + graph workflows, YAML agents, MCP/A2A, CodeAct

Two inputs, one output, and a short list of what the merged framework adds on top. Everything below this figure is just unpacking that last line and the cost of getting onto it.

What carries over

The inheritance is the reassuring part

Here is the good news for anyone already invested. The migration is not a teardown, because MAF deliberately keeps the load-bearing pieces from both parents. From AutoGen it inherits the simple Agent and ChatAgent abstractions, group chat, and the Magentic-One orchestration patterns. From Semantic Kernel it keeps the middleware pipeline, session state, OpenTelemetry instrumentation, and the model connectors. If you built on the conversational side, the single-agent interface in MAF is close enough to what you know that the diff is small. If you built on the enterprise side, the plumbing you depended on did not vanish, it got a new home.

That continuity is exactly why I tell clients not to panic about the maintenance-mode notice. Maintenance mode sounds like a fire alarm. In practice it is a forcing function with a friendly on-ramp. The official migration guidance exists precisely because Microsoft knows two large user bases need to move, and the AutoGen single-agent path in particular is nearly a drop-in. The cost is real but it is bounded, and a bounded cost is a thing a steering committee can actually approve.

What is genuinely new, and what that buys you

Now the part that is not just a port. MAF adds four things worth naming, because they are the reasons to treat it as more than a rebranding. There is a graph-based workflow API for orchestration that does not fit a simple conversation loop. There are declarative YAML agents, so an agent definition becomes a versioned artifact rather than a pile of constructor calls. There is support for the interop standards (MCP for tools, A2A for agent-to-agent, AG-UI for surfaces), which matters more every quarter as the ecosystem stops being one vendor's island. And there is the developer-experience layer: a DevUI debugger and CodeAct, which runs generated code in a Hyperlight sandbox instead of trusting it on your host.

Of that list, the two I actually care about in a regulated shop are the YAML agents and the standards support. A YAML agent definition is something I can put in a pull request, diff, review, and roll back. The standards support is what keeps me from betting the platform on a closed orchestration API. The graph workflow API is promising, and I will get to my reservation about it shortly. CodeAct and DevUI are nice, but they are developer ergonomics, not governance, and I try not to let ergonomics drive a platform commitment.

The reason the new pieces matter for planning is that they are where the build-deploy-operate loop lives. Figure 3 is the loop I draw when a client asks "fine, but what does running this actually look like."

Figure 3 · The operating loop

Build in MAF, deploy to a framework-agnostic runtime, operate with tracing

Read the amber bar twice. The headline most people miss is that the Foundry runtime is framework-agnostic: it will host MAF, but also the GitHub Copilot SDK, the Claude Agent SDK, or LangGraph without a rewrite. That decoupling is the most enterprise-friendly thing in the whole story, because it means committing to the hosting does not force you to commit forever to the SDK.

That last point deserves its own sentence, because it changes how I score the risk. If the runtime accepts more than one SDK, then "should we standardize on MAF" stops being an all-or-nothing bet. You can host on Foundry, build new agents in MAF, and still keep a LangGraph service running on the same runtime while you migrate. For the Foundry hosting and CodeAct announcements in full, the Build 2026 agents recap is worth a look, since that is where the runtime story was laid out in detail.

So which migration are you actually running?

This is the question that decides everything, and the answer is not the same for two teams sitting in the same building. There are really three starting positions, and each one has a different recommended move. I keep the decision on a single sheet so a room can self-sort in about ninety seconds.

Figure 4 · Where do you start?

The three-position migration checklist

Three rows, three different decisions. If you are on AutoGen, port early while the diff is small. If you are on Semantic Kernel, plan a managed move and budget the connector audit. If you are greenfield, build on MAF, but only after you have honestly answered the portability question in row C. The position you are in is the whole plan.

The counterpoint I owe you before you commit

I would not trust an architect who only listed upsides, so here is the honest other side. The first caveat is the obvious one: MAF is Microsoft-centric, .NET and Python first. If your real constraint is multi-cloud portability and provider freedom, a stack built on LangGraph with your own model routing will give you more room to move between clouds, and the framework-agnostic Foundry runtime does not fully erase that, because the SDK ergonomics still pull toward the Microsoft ecosystem. Weigh that genuinely rather than letting the convergence story make the decision for you.

The second caveat is more specific and it is the one I would flag in a review. The graph-based workflow API is new. New means less battle-tested. LangGraph has been shipping durable checkpointing and recovery semantics for a while, and at GA the MAF graph API simply has fewer production miles on it. That is not a reason to avoid it. It is a reason to pilot the graph workflows on a non-critical path first and not bet a regulated production flow on an orchestration API that is still settling. If you are mapping these orchestration choices against your own architecture, it is worth taking a look at the agentic architecture components breakdown, which lines the orchestration layer up against the rest of the stack so you can see where the graph API actually sits.

And the third, quietly: the maintenance-mode status of both legacy stacks means the migration is not optional on a long enough timeline. Teams on AutoGen and teams on Semantic Kernel both bear a transition cost eventually. The only real choice is whether you pay it deliberately now, while the diffs are small and the guides are fresh, or reactively later when the runway is short and the people who wrote the original code have moved on.

Wrap-upPlan against the merger, not the split

If you take one thing from this, let it be the reframing I opened with: Microsoft's agent story is no longer two competing answers, it is one converged SDK with a finite runway on the legacy stacks. That means the question worth your steering committee's time is not "AutoGen or Semantic Kernel," a question the merger already answered. It is "which migration are we running, and when do we start it." Build against MAF, host on the framework-agnostic runtime so the SDK choice stays reversible, and treat the graph workflow API as promising-but-young until your own traces say otherwise.

Do this this quarter

Take an inventory of every agent project in the org and sort each one into row A, B, or C from the checklist. For the AutoGen projects, run one through the migration guide as a spike and measure the real diff, because that number is your whole migration estimate in miniature. For anything greenfield, write down the portability answer before you write any code. You will have turned a vague "we should look at MAF" into a dated, scoped plan, which is the only version of this decision a budget approves.

The third-framework question (whether to bet on MAF at all when LangGraph and CrewAI are right there) is its own debate, and it is one I have strong opinions about for regulated teams. An interesting read for that comparison is the LangGraph versus CrewAI enterprise breakdown, which frames MAF as one bet among several rather than the default. Pick the framework for the constraint you actually have, not the one with the newest blog post.

Two research projects converged into one enterprise SDK. The migration path, not the demo, is the enterprise decision.

Plan against the unified Agent Framework. Port the easy lane early, audit the harder one honestly, and let the convergence be the gift it actually is: one fewer fork to maintain, on someone else's support contract.

Comments (4)

Join the discussion

Grace KimUnproven4/14/2026

The migration story matters more than the feature list is exactly right for anyone already on Semantic Kernel. We have production SK code and the question that keeps me up is not what the unified framework can do, it is what breaks when we move and who owns the regression testing. The demo never shows you the migration, and the migration is the entire cost.

Mateo LeeUnproven4/15/2026

That was the reason I framed it around the convergence rather than the announcement. If you have SK in prod, the unified framework is a migration project with a feature list attached, not a new toy. I would pin your eval suite before touching it, because that is the only way you will know what the migration quietly changed.

Wei BakshiDormant4/15/2026

Worth remembering AutoGen and Semantic Kernel came from different cultures, research conversation loops versus enterprise plumbing, and the merged framework still shows both seams. Not a criticism, just set expectations that the unified part is a journey. The two halves still feel like two halves in places.

Yuki KhanAwakened4/16/2026

Helpful for planning. I am going to set the internal expectation as this is a migration with a timeline, not a version bump we do in a sprint. Managing that expectation early is most of my job and this gives me the language for it.