AutoGen Is in Maintenance Mode: What to Do If You Built on It

You have a multi-agent system in production built on AutoGen. A GroupChat, a few AssistantAgents, a UserProxyAgent running model-generated code in a sandbox. It works. Then you bump the dependency, read the release notes, and the project's own README tells you AutoGen is in maintenance mode and new users should start with something called Microsoft Agent Framework.

The question that follows isn't "is AutoGen dead." It's the more annoying one: how much of what I built do I have to throw away, and when.

What actually changed

On April 3, 2026, Microsoft shipped Agent Framework 1.0. It merges two of the company's own agent projects, AutoGen and Semantic Kernel, into a single SDK for Python and .NET, with Go in preview. Both predecessors are now in maintenance mode. Microsoft's README puts it plainly: AutoGen will not receive new features or enhancements and is community-managed going forward, and new users should start with Microsoft Agent Framework. The Agent Framework overview calls itself the direct successor to both, built by the same teams.

Maintenance mode is a specific status, and it's worth being precise about it before deciding anything.

AutoGen isn't deleted, and your production system will not stop running on Monday. Maintenance mode means bug fixes, security patches, and stability updates continue. What stops is new capability. It's the software equivalent of a car model that's been discontinued but still gets parts and service: it starts every morning, the dealer will still fix it, and no new model year is coming while the service network quietly reorganizes around the replacement. You're not stranded. You're also not getting anything new, and the ecosystem around you is moving to a different platform.

Why this isn't a find-and-replace

The reason migration is more than swapping import statements is that the successor deliberately dropped AutoGen's central idea.

AutoGen's whole personality was conversational multi-agent orchestration. You defined AssistantAgents and a UserProxyAgent, dropped them into a GroupChat with a GroupChatManager, and let them talk. The control flow was emergent: who speaks next, when the conversation ends, what actually gets solved, all of it fell out of the message-passing between agents. That model is genuinely elegant for prototyping and genuinely hard to reason about in production, because the behavior you're debugging is a property of a conversation, not a program.

Agent Framework replaces that with graph-based workflows: typed executors connected by edges, with deterministic routing, checkpointing, and human-in-the-loop points you place explicitly. Single agents map across cleanly. An AssistantAgent becomes an agent, tool calls stay tool calls, the sandbox code executor has an equivalent. The orchestration layer is where the work is. If the value of your system lived in the GroupChat choreography, that's precisely the part with no drop-in equivalent, because the implicit-conversation model is the thing Microsoft decided was too hard to run in production and designed out.

The framework didn't lose your favorite feature by accident. It retired it on purpose.

Do you actually have to move, and when

Maintenance mode is not an eviction notice. There's no announced end-of-life date, security patches keep coming, and a working AutoGen system can keep running in production for the foreseeable future. Panic is not the right response.

Neither is doing nothing forever. No new features means no new model-provider integrations, no new orchestration primitives, and a shrinking pool of people who know the framework. Mindshare is draining toward Agent Framework and the other graph-based frameworks, and that shows up first in small ways: the answers you find get older, the new provider SDK lands somewhere else first, the engineer you hired last month has never touched it.

So the trigger to migrate isn't a date on the calendar. It's the first time you need something maintenance mode won't give you: a capability that only exists in the new framework, a provider integration that never comes to AutoGen, durable or resumable execution you'd otherwise have to hand-build, or a re-architecture you were already planning. Until one of those hits, migration is a project you can schedule, not a fire you put out.

The real decision isn't Agent Framework vs. AutoGen

When you do migrate, the obvious path is Agent Framework. It's the sanctioned successor, it's built by the same teams, and if you already live in the Azure and Microsoft ecosystem it's the least surprising choice. You get the workflow engine, an opinionated agent harness for long multi-step tasks, and the enterprise plumbing Semantic Kernel brought: telemetry, middleware, session state.

But notice what the migration actually forces. If your orchestration is moving from an implicit conversation to an explicit graph, you're paying a re-architecture cost no matter which graph you land on. And Agent Framework isn't the only graph-based option that reached production maturity. LangGraph hit 1.0 GA in October 2025 on the same basic premise: typed, durable, checkpointed graphs of steps, without a hard tie to one cloud. The re-architecture bill is roughly the same either way, which means the decision that matters isn't "Agent Framework or stay on AutoGen." It's "which orchestration model do I want to be locked into for the next three years," and that's worth deciding on purpose rather than defaulting to whichever logo matches the one you already have.

The one move to avoid is a like-for-like port: rebuilding the GroupChat choreography on top of a graph engine so it behaves exactly as it did before. That pays the entire migration cost to preserve the exact pattern the migration exists to retire. If you're going to move, move to the model, not just the library.

The uncomfortable part

Microsoft didn't retire AutoGen because conversational multi-agent orchestration failed in the lab. It retired it because that model, the one that made AutoGen fun to demo, was the part that didn't hold up in production, and the replacement is built around explicit graphs specifically to fix that. If you built on the conversational model, the maintenance-mode announcement is just the messenger.

Which turns the migration into a question worth answering honestly, separate from any framework: was your multi-agent choreography ever load-bearing, or was it decoration on top of what a graph of typed steps would have done with less mystery? Migrating forces you to answer. Depending on how honest the original design was, that's either a tax or a favor.