Maintenance mode makes AutoGen an existing-system choice
AutoGen lets developers assemble agents that exchange typed messages, call model clients and tools, and hand work to other agents. The Python stack is layered: Core handles messaging and local or distributed runtimes, AgentChat supplies higher-level conversation patterns, and Extensions connects providers and tools. The repository also contains .NET code, AutoGen Studio, and a benchmarking package. That range once made it a broad place to begin agent experiments.
The decision changed when Microsoft placed the project in maintenance mode. The README says it will receive fixes, security patches, and documentation changes, but no new features or enhancements. New users are directed to Microsoft Agent Framework, described there as the supported successor. Existing AutoGen users get migration documentation, which is useful, but the message is unambiguous: adopting AutoGen in 2026 means accepting a legacy path from day one.
The 3-layer Python API still covers serious agent work
Core, AgentChat, and Extensions address different levels of control. Core is for event-driven agents, message passing, and distributed execution. AgentChat provides opinionated teams and common conversational patterns. Extensions includes model clients and capabilities such as code execution. A team maintaining a deployed system can therefore stay near the convenience layer or replace parts with lower-level runtime code without leaving the project.
The quick start uses Python 3.10 or later and installs autogen-agentchat with the OpenAI extension. Its example exports an OpenAI API key and calls a current model through OpenAIChatCompletionClient. That is a small first program, but real cost and reliability depend on the provider, chosen model, tool calls, retry policy, and message history. Our sandbox did not call a model, so it says nothing about answer quality or token use.
What happened when we ran it
Our sandbox installed commit 027ecf0 in 24 seconds. It added 33 packages and occupied 36 MB, then completed the build in 10 seconds. The checkout contained 1,837 files, roughly 189,959 lines of source, and 48.3 MB before installation. Pip-audit reported 0 known vulnerabilities in the installed Python dependencies.
The test step failed after 16 seconds with exit code 1. Pytest reported 0 passed, 1 failed, 1 skipped, and 96 collection or setup errors out of 97. The log tail names failures across MCP workbench and client tests, Python code execution, Studio data models, database management, and team management. It does not show a shared exception or enough detail to assign one cause, so we cannot claim a missing system package explains the run.
Twelve CI workflow files were present, while our scan found no Dockerfile and no top-level tests directory. The Python packages do contain tests under their own package paths, as the failure list demonstrates. The useful conclusion is limited but important: install and build worked in the fresh Debian container, while the broad test command did not reach a trustworthy passing baseline.
Studio on port 8080 is a prototype, not an application shell
AutoGen Studio offers a visual way to compose and run teams, and the README starts it on localhost port 8080. Microsoft also warns that Studio is intended for rapid prototypes and demonstrations. It is not presented as a production-ready app, and teams are told to build authentication, security, and other deployment controls themselves. That warning should rule out putting the default UI on a public route.
Code execution and MCP integrations deserve the same caution. The README's MCP example installs the Playwright MCP server through npm and gives it to an agent as a workbench. A nearby warning says only trusted MCP servers should be connected because they may execute commands locally or expose sensitive information. Treat tool permissions, network access, filesystem mounts, and secrets as application design, not framework defaults.
Recent issue activity cannot reverse Microsoft's support decision
GitHub showed 60,645 stars, 1,004 combined open issues and pull requests, and a last push on April 15, 2026. Open issues were still being updated in August 2026, including proposals and security examples, so people continue to use and discuss the code. The combined count is not a defect total, and activity from users does not amount to a promise of new framework development.
The latest GitHub release was Python v0.7.5, published September 30, 2025. Its notes include model-client fixes, MCP failure handling, security warnings around code execution, and support for then-new provider options. Those are relevant fixes for pinned installations. They do not outweigh the current README, which tells new adopters to choose the successor.
Existing users should migrate package by package
A current AutoGen deployment may still be expensive to replace. Agent definitions, message types, team behavior, provider adapters, memory, MCP tools, and Studio workflows can all create migration work. The practical response is to inventory which of those layers the application actually uses, add focused tests around them, and compare the successor on those exact paths. Our run's 96 setup or collection errors make targeted verification more useful than assuming the whole checkout is healthy.
AutoGen remains readable, licensed for code use under MIT, and supported by detailed documentation. It is still the wrong default for a new agent system because its own maintainer has made that call. Keep a stable version where migration risk is higher than short-term maintenance risk, but do not build fresh architecture around an API family Microsoft has already superseded.