AutoGen is in maintenance mode, and its own front page steers new users to Microsoft Agent Framework

Maintenance mode is the first thing the project tells you

AutoGen carries a caution block at the top of its own front page, and it is the most important line for anyone reading the project today. AutoGen is in maintenance mode: it will not receive new features or enhancements and is community managed going forward. The last push to the repository was 2026-04-15. New users are told to start with Microsoft Agent Framework, and existing users are encouraged to migrate using the AutoGen to Microsoft Agent Framework migration guide. The consequence is straightforward: the framework is not being extended, so if you are choosing a multi-agent layer today you are choosing between a community-run project that has stopped growing and a successor the same organization calls enterprise-ready. What maintenance mode cannot do is hand you the roadmap or the support commitment that a framework you build products on usually needs.

AgentChat resembles v0.2 without being the same thing

If you arrive from AutoGen v0.2, the framing is that AgentChat is the layer closest to what v0.2 users are familiar with. Closest is the operative word. The project routes upgrading users to a dedicated migration guide with detailed instructions on how to update code and configurations, which is a signal that the upgrade is not a version bump. AgentChat is described as a simpler but opinionated API for rapid prototyping, supporting common multi-agent patterns such as two-agent chat or group chats. What this layer cannot do is absorb an arbitrary v0.2 codebase unchanged, because opinionated means some of your earlier design choices get replaced by the framework's. A reader porting a live v0.2 system should budget for a rewrite rather than assume the pipeline keeps running after an upgrade.

The layer you choose decides how much of the orchestration you own

AutoGen is organized as a layered and extensible design in which each layer has clearly divided responsibilities and builds on the layers below, and you pick how deep to go. The Core API implements message passing, event-driven agents, and a local and distributed runtime, and it supports cross-language use for .NET and Python. The AgentChat API is a simpler but opinionated layer built on Core for rapid prototyping. The Extensions API carries first- and third-party extensions, including specific LLM client implementations such as OpenAI and AzureOpenAI and capabilities such as code execution. What the layering cannot do is let you take the convenience of AgentChat and the freedom of Core at the same time. Convenience costs you opinionation, and flexibility costs you the batteries-included patterns. Pick the layer that matches how much of the orchestration you intend to own.

Every quickstart sample is wired to an OpenAI key

The samples all call the OpenAI API, so the documented happy path starts by creating an account and exporting a key as OPENAI_API_KEY. The Hello World example builds an OpenAIChatCompletionClient, hands it to an AssistantAgent, runs a single task, and then closes the client. There is a small inconsistency worth knowing about: the prose introduces the sample as using OpenAI's GPT-4o model, while the code constructs the client with model="gpt-4.1". What the quickstart cannot do is show you a provider-neutral setup, because the client object it hands you is an OpenAI one. Swapping in a different model means constructing a different client through the Extensions API, and the samples do not walk you through that. Read the code rather than the sentence above it.

An MCP connection hands the agent a command line

The MCP example shows a web browsing assistant built on McpWorkbench and StdioServerParams, pointed at the Playwright MCP server through npx with a headless argument, after a first step of running npm install -g @playwright/mcp@latest to install the server. The project attaches an explicit warning to this pattern: only connect to trusted MCP servers, because they may execute commands in your local environment or expose sensitive information. What this integration cannot do is contain that risk for you. Wiring an MCP server into an agent means the agent's tools can reach the same machine you are on, so the security boundary is the trustworthiness of the server rather than anything the framework enforces. If you add one to a product, that boundary becomes something you have to document and police yourself.

AutoGen Studio is a prototype surface, not a deployable app

AutoGen Studio gives you a no-code GUI for building multi-agent applications, and it is the fastest way to see a workflow run. The project is direct about its limits: Studio is meant to help you rapidly prototype multi-agent workflows and demonstrate an example of end user interface, and it is not meant to be a production-ready app. The guidance is to use the AutoGen framework to build your own applications, implementing authentication, security, and the other features a deployed application needs. You start it with:

autogenstudio ui --port 8080 --appdir ./my-app

which serves on http://localhost:8080. What Studio cannot do is be the thing you ship. If a prototype built in Studio reaches users, it reaches them without the authentication and security layer the project just told you to add yourself. Treat the GUI as a sketching surface and plan the real application separately.

Python 3.10 is the floor, and the newest tag is older than main

AutoGen requires Python 3.10 or later, and the stable install pulls the AgentChat package together with the OpenAI extension extra:

pip install -U "autogen-agentchat" "autogen-ext[openai]"

AutoGen Studio installs as its own separate package rather than as part of that command. On versions, the most recent tagged Python releases are python-v0.7.5 on 2025-09-30, python-v0.7.4 on 2025-08-19, and python-v0.7.3 on 2025-08-19, while the last push to the repository was 2026-04-15. That gap is the practical detail: main carries roughly six months of commits past the newest tag, so pinning to the latest release gives you code that is not what the project currently has on its default branch. A reader on Python 3.9 has no supported path at all, and a reader who wants the newest fixes has to choose between the tag and main. The repository also separates documentation from code licensing, carrying a CC-BY-4.0 LICENSE alongside a separate LICENSE-CODE file.

Editorial conclusion

AutoGen still makes sense for an existing v0.2 or AgentChat codebase that has to keep running, since the architecture works and the community maintains it. It does not make sense as the foundation for a new multi-agent product, because the project redirects new users to Microsoft Agent Framework and has stopped adding features. Before you commit, check the Python 3.10 floor, follow the migration guide if you are on v0.2, and treat AutoGen Studio as a prototype you will replace with your own app plus authentication.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes