Maintenance mode makes AutoGen a difficult choice for new work
Choose AutoGen today and you inherit a framework whose maintainers have stopped adding features. The current README directs new projects to Microsoft Agent Framework and encourages existing users to migrate. That changes the recommendation before you write an agent: keeping a working application running can justify AutoGen, while starting a fresh dependency on it needs a reason beyond familiarity with the name.
The package footprint alone would not put me off. Our sandbox added 35 packages occupying 38 MB, a manageable environment for exploring the Python API. The harder commitment is owning code against a community-managed framework with a published exit route. An existing team can weigh migration against its working integrations. A new team gets little benefit from taking on that decision immediately.
AgentChat gives you assistants and delegation without writing the message runtime
AutoGen's Python code lives under ./python/; our checkout contained 1,837 files and roughly 189,959 source lines. AgentChat supplies assistant and group-conversation patterns, while Core handles message delivery and agent runtimes. Extensions connect those agents to model providers and tools. For an application that already separates work between assistants, those layers give each responsibility a place to live.
The README's delegation example wraps specialist assistants in AgentTool objects so another assistant can call them. That is a concrete reason to use the framework: you can express which assistant handles which task without building the message plumbing yourself. It does not establish that several assistants answer better than one. Decide what handoff your application needs before adding more participants to its conversations.
What happened when we ran it
Our run installed AutoGen at commit 027ecf0 in 13 seconds, adding 35 packages and using 38 MB on disk. The build passed in 2 seconds. We cloned and ran it on October 14, 2026, in an unprivileged Debian container using ghcr.io/astral-sh/uv:python3.12-bookworm, with 3 CPUs, 8 GB of RAM, and no secrets. Those steps establish that the measured installation and build completed in that environment.
The test command exited with code 1 after 5 seconds. Pytest reported 0 passed, 1 failed, 1 skipped, and 96 collection/setup errors. The log tail names AutoGen Studio modules covering MCP connections, database management, and teams, but omits the exception details for those errors. It cannot tell us whether missing packages, configuration, or defects caused them. It gives no passing-suite evidence to rely on.
The separate failure was a cookiecutter template example at templates/new-package/{{cookiecutter.package_name}}/tests/test_example.py::test_example. Pytest said async functions were not natively supported. That identifies the reported failure without explaining how the template entered the run. Pip-audit reported 0 known vulnerabilities. Neither the audit nor the successful build establishes whether an agent can complete a useful task with a configured model.
Our scan found 12 CI workflow files and flagged no Dockerfile or tests directory. The same log lists nested test paths, so the directory signal cannot support a claim that AutoGen has no tests. Read that flag as a limitation of the scan. The actionable result is that the broad command we ran did not produce a green suite.
The quickstart needs a model credential, and browser tools add another runtime
The lab used Python 3.12; AutoGen's README specifies Python 3.10 or later. Its assistant example needs an OpenAI account and OPENAI_API_KEY, with model calls going through OpenAIChatCompletionClient. The code creates an assistant, awaits its result, and closes the model client. Copying the package command gets you the software. You still need an authorized model endpoint before that example can answer.
The Playwright MCP example launches a separate server through npx, adding a Node runtime to the Python application. Our 13-second install does not measure readiness of that browser workflow. The README also warns that MCP servers can execute local commands or expose sensitive information. Pick the server and its access deliberately, especially when moving a local experiment onto a machine holding application credentials.
Studio is explicitly a prototype interface
AutoGen Studio's README warning says developers must supply authentication and other deployment protections in their own applications. The visual editor is useful for trying agent workflows, but it does not relieve you of building the surrounding service. If your requirement is a browser app you can expose to colleagues immediately, this limitation is a good reason to choose something else.
The 0 known vulnerabilities in our pip-audit result cover the dependency environment we measured. They do not assess Studio access control or the permissions granted to an MCP server. Keep those decisions separate when evaluating a deployment. A team maintaining AutoGen should review the particular tools it exposes, rather than treating a clean dependency report as approval for the whole application.
Recent reports coexist with an older push and release
GitHub's API reported the last push as April 15, 2026, and 1,115 open issues and PRs. The latest release endpoint returned python-v0.7.5, published September 30, 2025. Recent discussion still exists: issue 8346, updated October 13, reports that the experimental conversation recorder fails with a bare relative filename while an explicit relative path works. That is a user report, separate from our sandbox findings.
These dates fit the README's maintenance policy more closely than a claim of abandonment. For new work, start by evaluating Microsoft Agent Framework, the documented successor. Choose LangGraph when explicit workflow state, persistence, and human intervention are your main requirements. Keep AutoGen when existing integrations justify it, and require checks around those integrations before shipping. Our 2-second build passed. The test run did not.