Microsoft's AutoGen entered maintenance mode in October 2025 when its team merged with the Semantic Kernel team to build the unified Microsoft Agent Framework. Critical bug fixes and security patches still ship, new features do not. Existing projects keep running, and Microsoft publishes a migration guide.
That is a smaller story than it sounds, and a bigger one. Smaller because nothing broke. Bigger because AutoGen is where a lot of us learned what a multi-agent system actually is, and it is worth being precise about which parts of that education transfer and which parts were just API surface.
Four ideas transfer.
Conversation History As Shared State
Every component in AutoGen is an agent that sends and receives messages. ConversableAgent, the base class, gives each one a name, a system message that defines its behavior, and configurable capabilities for inference, code execution and human input.
The design decision underneath is what holds shared state. AutoGen's answer is the conversation history itself. No separate workflow database tracks which step finished and what it returned, because the transcript is the record.
The upside is that any agent can read what came before it, debugging means reading a log you already have, and adding an agent does not mean migrating a schema. The cost is that the transcript grows and every agent pays for it in context on every hop. Systems that stay healthy keep the shared history deliberately small and structured rather than letting it accumulate whatever each agent felt like saying.
Who Speaks Next Is The Whole Design
AutoGen scales from a two agent back and forth up to a group chat where a manager agent selects the next speaker from context. You can also hand it a custom function and route by your own rules.
Speaker selection is not a layer on top of a multi-agent system. It is the system. Every time you ask a model to decide who goes next, you have added an inference call, a latency hop, a cost line and a nondeterminism source to the control flow itself. That is sometimes exactly right, when the routing genuinely requires judgment about ambiguous content. It is very often wrong, when a switch statement over a task type would have done the same job for free and the same way every time.
The useful habit is to write the routing rule out in plain language first. If you can write it, code it. If you cannot, that is the hop that earns a model.
One Model Per Agent Changes The Cost Math
Each agent in an AutoGen system can run on a different model. A frontier model on the single step that has to reason, and a small cheap model on routing, formatting, extraction and summarizing.
This moves the economics of a multi-agent system further than prompt tuning will. Most hops in a real agent workflow are not hard. They are shaping data so the next hop can use it, and paying frontier prices for that is where multi-agent budgets quietly disappear.
The inference layer under AutoGen also handled caching, rate limiting, cost tracking, and automatic fallback across providers, so one provider having a bad afternoon did not take the run with it. When you evaluate any replacement framework, that list is the checklist worth using. Feature matrices will not tell you which of them survives a 429.
For the longer version of all of this, including tool calling, deployment considerations, framework comparisons and the migration path, I keep a full writeup at Auto Learning Agents.
The Execution Boundary Is Not Optional
An AssistantAgent reasons and writes code. A UserProxyAgent runs that code in a sandbox and relays human input, configured to approve every action, approve some of them, or run fully autonomously.
Splitting the thing that writes code from the thing that executes it is the choice that makes an agent system operable. It gives you one place for the approval gate and one place for the sandbox, instead of both being scattered across agent definitions where nobody can audit them.
It also makes the autonomy level a configuration value rather than a rewrite. You can ship with a human approving everything, watch what it actually does for two weeks, and loosen the gate on the categories that earned it.
Takeaway
If AutoGen is in your production stack, nothing is on fire. Security patches are still landing, so plan the migration on your own schedule instead of a panicked sprint.
If you are starting something new, start on the Agent Framework and read AutoGen as documentation of why the design looks the way it does.
Either way, learn the patterns and not the imports. This space has been consolidating for two years and it is not done. The people who came through the last round fine are the ones who understood group chat orchestration, sandboxed execution and per-agent model assignment as concepts, which is knowledge no deprecation notice can take back.
This article was originally published by DEV Community and written by Paul Crinigan.
Read original article on DEV Community