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 lev