Most of us here have shipped something on an agent framework in the last year, and a fair number of those frameworks have already changed names or maintainers. This is a look at the parts of Microsoft's AutoGen that were worth keeping, written for anyone picking a stack this month rather than defending one they already chose.
AutoGen came out of Microsoft Research in August 2023 and picked up more than 54,000 GitHub stars by early 2026. In October 2025 it entered maintenance mode, its team merged with the Semantic Kernel team to build the unified Microsoft Agent Framework. Critical bug fixes and security patches still land, new features do not. That makes this a good moment to separate the package from the ideas, because the ideas moved into the successor intact.
Conversation History As Shared State
Every component in AutoGen is an agent that sends and receives messages. The base class, ConversableAgent, gives each agent a name, a system message that defines its behavior, and configurable capabilities for inference, code execution and human input.
The decision that matters is what plays the role of shared state. In AutoGen it is the conversation history itself. There is no separate workflow database tracking which step finished and what it produced, because the transcript is the record.
That buys you a lot. Any agent can read what happened before it, debugging is reading a log you already have, and adding an agent does not mean adding a schema. It also costs something real, which is that the transcript grows and every agent pays for it in context. The teams who get this right keep the shared history small and structured on purpose instead of letting it accumulate.
Deciding Who Speaks Next
AutoGen scales from a two agent back and forth to a group chat where a manager agent picks the next speaker based on context, and you can supply a custom function that routes by your own rules instead.
This is the part people underestimate. Speaker selection is not a detail sitting on top of a multi-agent system, it is the system. Ask a model to choose the next speaker and you have added an inference call, a failure mode, and a source of nondeterminism to every single hop. Route by rule wherever the rule is knowable, and save model driven selection for the hops that genuinely need judgment.
Per-Agent Model Assignment
Each agent in an AutoGen system can use a different model. Put an expensive frontier model on the one step that has to reason and a small cheap model on routing, formatting and summarizing, and the economics of the whole system move further than any prompt tweak will manage.
The inference layer underneath handled caching, rate limiting, cost tracking and automatic fallback across providers, so one provider outage did not take the run down with it. If you are evaluating a replacement, that list makes a better checklist than any feature matrix. The full architecture writeup, including tool calling, deployment, framework comparisons and the migration path, is at Auto Learning Agents if you want the long version.
The Execution Boundary
An AssistantAgent reasons and writes code. A UserProxyAgent executes that code in a sandbox and relays human input, and you configure whether it approves every action, approves some of them, or runs fully autonomously.
Splitting the thing that writes code from the thing that runs it is what makes an agent system safe to operate. It gives you exactly one place to put the approval gate and one place to put the sandbox, instead of scattering both through your agent definitions.
What To Carry Forward
If you run AutoGen in production today, nothing broke this morning, so plan the migration on your own schedule rather than in a hurry. If you are starting fresh, start on the Agent Framework and read AutoGen as documentation of why the design is shaped the way it is.
Either way the durable skill is the patterns and not the imports. Group chat orchestration, a real execution boundary, and per-agent model assignment are going to outlive several more framework names.