What is AutoGen?
Updated on
AutoGen is Microsoft's maintenance-mode framework for conversational agents and event-driven multi-agent applications; new Microsoft projects are directed to Microsoft Agent Framework 1.0.
Quick Facts
| Full Name | Microsoft AutoGen |
|---|---|
| Created | Developed by Microsoft Research, currently one of the most starred Multi-Agent frameworks on Github |
| Specification | Official Specification |
How It Works
Identify the package lineage before changing code
Microsoft AutoGen 0.4+ uses autogen-agentchat, autogen-core, and autogen-ext. AG2 1.x is an independently governed, actively developed framework installed as ag2 and imported with import ag2. The classic autogen package and ConversableAgent API now live in AG2 Classic maintenance mode. Similar names do not imply compatible state, message, tool, or orchestration APIs.
Choose maintain, migrate, or retire from evidence
A working AutoGen service does not require an emergency rewrite, but maintenance mode removes the expectation of feature growth. Inventory package versions, model clients, Team or Core usage, persisted state, code executors, observability hooks, and external side effects. Compare the cost of pinning and isolating the current system with migration to Microsoft Agent Framework, LangGraph, AG2 1.x, or a smaller custom loop.
Migration preserves behavior, not just imports
Microsoft's migration guide maps model clients, messages, tools, sessions, Team patterns, workflows, and telemetry separately. Re-run task, safety, cancellation, restart, duplicate-delivery, and cost tests against the target. Checkpoints do not prove that a payment, message, deployment, or database write committed exactly once; retain business idempotency keys, effect records, authorization, and reconciliation outside the framework.
Key Characteristics
- Maintenance lifecycle: the Microsoft repository accepts maintenance work rather than new framework features
- Layered APIs: AgentChat provides high-level teams while Core exposes an event-driven runtime
- Extension boundary: provider clients, MCP integrations, and code executors live in `autogen-ext`
- Separate successor: Microsoft Agent Framework 1.0 is the recommended Microsoft path for new projects
- Separate community line: AG2 1.x and AG2 Classic have different packages, APIs, and governance
- Application responsibility: authorization, isolation, budgets, and side-effect recovery remain external controls
Common Use Cases
- Maintaining an existing version-pinned AgentChat or Core deployment
- Planning a measured migration from AutoGen to Microsoft Agent Framework
- Extracting domain tools and state contracts from an inherited AutoGen system
- Replaying representative traces against a replacement runtime
- Keeping a legacy service isolated while security and dependency patches remain available
Example
Loading code...Frequently Asked Questions
Is Microsoft AutoGen still actively developed?
It is maintained rather than actively extended. The Microsoft repository says AutoGen receives no new features or enhancements and is community managed. Existing systems can remain pinned while support risk is acceptable, but Microsoft recommends Agent Framework 1.0 for new projects.
Are Microsoft AutoGen, AG2, and AG2 Classic the same project?
No. Microsoft AutoGen uses the `autogen-agentchat`, `autogen-core`, and `autogen-ext` packages. Active AG2 1.x uses the `ag2` distribution and import. AG2 Classic publishes the legacy `autogen` package in maintenance mode. Their owners, APIs, and migration paths are distinct.
How is AutoGen different from Microsoft Agent Framework 1.0?
AutoGen pairs an event-driven Core with high-level AgentChat teams. Agent Framework 1.0 centers agents and typed graph workflows, adds stable Python and .NET APIs, and is Microsoft's successor path. Migration maps clients, messages, tools, sessions, state, orchestration, and telemetry rather than renaming imports.
Should an existing AutoGen service migrate immediately?
Not automatically. First inventory dependency support, security exposure, persisted state, provider requirements, and business side effects. A version-pinned service may remain viable, but every team should test a migration target and document the cost of staying, moving, and rolling back.
Does AutoGen make code execution or tool use safe?
No. Executors and MCP integrations are capability adapters, not authorization boundaries. Treat generated code, peer messages, and tool results as untrusted; isolate execution, remove ambient credentials, enforce object authorization, limit network and resources, and reconcile uncertain external writes.