The Multi-Agent Patterns That Outlived AutoGen

Microsoft's AutoGen service ceased maintenance in October 2025 after merging with the Semantic Kernel team to create the unified Microsoft Agent Framework. While certain critical bug fixes and security patches continue to be released, new features are no longer being added. Existing projects remain operational, and Microsoft provides a migration guide.

This development is noteworthy but not catastrophic, as everything was already functioning as intended. The real significance lies in the lessons learned about multi-agent systems through AutoGen. Four key takeaways emerged from this experience.

Firstly, conversation history serves as shared state. Each component within AutoGen is an agent capable of sending and receiving messages. The ConversableAgent, serving as the base class, assigns a name, a system message defining behavior, and configurable capabilities for inference, code execution, and human input. The underlying design principle is the utilization of the conversation history itself as the shared state repository.

This means that any agent can access previous exchanges, debug issues using existing logs, and new agents can be added without the need for schema migrations. However, the primary drawback is that the transcript expands over time, requiring agents to pay for the storage of each message in every interaction.

Secondly, the process for determining the next speaker is integral to the system's design. AutoGen supports various scaling scenarios, ranging from a simple two-agent dialogue to a group chat with a manager agent that selects the next speaker based on context. The speaker selection mechanism is not an add-on feature but rather the core of the multi-agent system.

Deciding who speaks next incurs additional inference calls, latency, and introduces potential nondeterminism, which might be valuable in certain situations but often unnecessary when a straightforward switch statement could suffice.

Thirdly, each agent in an AutoGen system can operate on different models, allowing for a cost-effective distribution of workload. A powerful, expensive model can handle complex reasoning tasks, while simpler, more affordable models manage routing, formatting, extraction, and summarization. This approach maximizes the efficiency of multi-agent budgets, as most intermediate steps in an agent workflow are relatively straightforward.

Moreover, the AutoGen inference layer handles caching, rate limiting, cost tracking, and automatic fallback across providers, ensuring system resilience even in the event of provider outages. When assessing alternative frameworks, it is essential to consider how well they manage these critical factors.

Lastly, the execution boundary is not an optional component in an agent system. AutoGen separates the reasoning and code generation capabilities of an AssistantAgent from the sandboxed execution and human input handling of a UserProxyAgent. This separation enables a clear approval gate and sandbox environment, facilitating better auditing and control over autonomous agent actions.

It also allows for dynamic adjustment of autonomy levels, starting with a highly conservative approach and gradually increasing as trusted categories are identified. This modular design ensures that agent systems are both secure and adaptable to changing requirements.