Microsoft AutoGen AgentChat and Event-Driven Agent Framework

OpenSourcesAI verdict

Microsoft has archived AutoGen and no longer maintains it, which means no bug fixes, security fixes, new features or support. Microsoft advises against production use and says new users should start with Microsoft Agent Framework, its named successor. The AutoGen code remains available for reference, and its design covers explicit agent messaging, team coordination, termination conditions, human intervention, code execution and distributed runtimes. Its current architecture is substantially different from the widely copied AutoGen 0.2 examples, so version discipline is mandatory. AgentChat is the practical starting point for most applications; Core is appropriate when teams need custom event-driven or distributed behavior. Multi-agent systems still require evidence that added agents improve outcomes enough to justify their cost and complexity.

Best for

Python developers maintaining existing AutoGen systems while they migrate, and researchers studying team-based or distributed agent patterns. New projects should start with Microsoft Agent Framework.

Why use it

AutoGen is archived, so consider it only when maintaining an existing project while you plan a migration. It offers structured conversations, selectable team patterns, state management, cancellation, human handoffs, and extensible model or tool integrations. It offers more control over agent communication than a simple autonomous loop.

AgentChat, Core, Studio, and Extensions

AgentChat is the higher-level API for conversational agents and teams. Core provides lower-level event-driven messages, runtimes, subscriptions, and distributed patterns. Extensions package provider clients, code executors, MCP support, and other integrations, while Studio offers a web interface for prototyping.

Choose one layer intentionally. Most product teams should begin with AgentChat and drop to Core only when custom routing, distributed runtimes, or message-level control justify the extra scaffolding.

Single agents and tool loops

AssistantAgent can call tools, stream events, maintain state, and perform multiple tool iterations. Current documentation notes that many workflows no longer need a single-agent group chat merely to repeat tool calls.

Set tool schemas, iteration limits, timeouts, and output contracts explicitly. A capable model can still loop, select the wrong tool, or produce unsafe arguments unless the application validates every side effect.

Teams and conversation control

AutoGen supports several team structures with different speaker-selection and handoff behavior. Round-robin and selector teams share conversation context differently from Swarm handoffs or Magentic-One orchestration, while GraphFlow introduces explicit directed execution and remains experimental.

Start with a single agent and move to a team only after the simpler design proves inadequate. Every participant increases message volume, latency, context growth, debugging difficulty, and the number of paths that can produce a side effect.

Termination, cancellation, state, and human feedback

Termination conditions are stateful and can stop runs by message count, text, token usage, timeout, handoff, source, function result, external signal, or custom logic. External termination allows a graceful stop after the current turn, while cancellation can abort immediately and may leave state inconsistent.

Human feedback can be provided during a run through a user proxy or after a team stops and its state is persisted. Applications should distinguish pause, stop, cancel, reset, and resume behavior rather than treating them as interchangeable.

Code execution and distributed runtimes

AutoGen extensions include command-line code executors and distributed runtime implementations. Model-generated code should run in an isolated container or stronger sandbox with restricted credentials, mounts, network access, CPU, memory, and execution time.

Core can support scalable message-driven agent systems, but distributed execution adds delivery semantics, state ownership, retries, observability, and version compatibility requirements that are not solved by the agent abstraction itself.

Migration and version discipline

The current AutoGen package structure and APIs differ substantially from AutoGen 0.2 examples found across blogs and repositories. Official documentation provides migration guidance and separates AgentChat, Core, Extensions, and Studio packages.

Pin package versions, use examples from the matching documentation version, and test serialized state and custom components during upgrades. Avoid mixing old pyautogen imports with current APIs without an explicit migration plan.

Key features

• AgentChat API for AssistantAgent, tools, streaming, memory, state, and application-facing single-agent workflows.
• Team presets including round-robin, selector, swarm handoffs, Magentic-One, and experimental graph-based execution.
• Stateful termination conditions for message count, text, token usage, timeout, handoff, external stop, and custom logic.
• Core event-driven runtime for routed agents, typed messages, custom workflows, and distributed agent systems.
• Extensions for model providers, MCP workbenches, Docker code execution, distributed runtimes, and external services.
• AutoGen Studio for visual prototyping, with production application code and deployment remaining separate concerns.

Common AI use cases

• Build a tool-using assistant with streaming and bounded iterations.
• Coordinate reviewer, planner, executor, or specialist agents in a team.
• Implement swarm-style handoffs or explicit directed agent workflows.
• Pause an agent workflow for human feedback and resume from persisted state.
• Run model-generated code in an isolated executor.
• Build event-driven or distributed agent systems using Core.

Business use cases

• Research and analysis workflows with specialist agents.
• Software-engineering assistants that execute code in controlled environments.
• Operations workflows requiring human escalation or approval.
• Customer-support or knowledge systems with tool access.
• Agent experimentation requiring detailed message and runtime inspection.

How AI builders can use it

• Build a single AgentChat agent with the minimum tools and a strict stop condition.
• Add tracing, token accounting, tool validation, and reproducible evaluation tasks.
• Introduce a team only when a measured failure requires role separation or handoff.
• Persist and restore state before adding asynchronous human feedback.
• Run code and risky tools in an isolated execution service.
• Pin current packages and migrate older examples deliberately.

Who should use it

• Existing AutoGen users maintaining a project while they plan a migration to Microsoft Agent Framework. New projects should not start here.
• Researchers comparing multi-agent patterns and termination behavior.
• Teams prepared to own the security of an unmaintained dependency until they migrate.

Who should not use it

• New projects: Microsoft says new users should start with Microsoft Agent Framework.
• Simple tasks that a direct model call or deterministic workflow can solve.
• Teams relying primarily on AutoGen 0.2 examples without migration capacity.
• Applications that cannot isolate code execution and powerful tools.
• Projects without cost, latency, state, and conversation observability.

Evaluation checklist

• Should the application use AgentChat, Core, Studio, or an extension package?
• Can one agent solve the task before a team is introduced?
• Which termination, cancellation, pause, and reset semantics are required?
• How are team state and human feedback persisted safely?
• Which tools or code executors can cause side effects?
• Are examples and package versions aligned with current documentation?
• What measurable quality gain must a multi-agent design deliver?

Security and admin notes

• Run model-generated code in a restricted container or sandbox, never directly on a privileged host.
• Validate and authorize tool arguments independently of model output.
• Treat agent messages, web content, files, and MCP results as prompt-injection inputs.
• Set termination and token limits to prevent unbounded conversations.
• Protect persisted team state because it may contain sensitive prompts and tool results.
• Redact secrets from traces and isolate distributed runtime credentials.

Pricing notes

AutoGen code is MIT licensed. Model APIs, code-execution infrastructure, storage, observability, and deployment platforms have separate costs. AutoGen Studio is a prototyping interface rather than a managed production service guarantee.

Tradeoffs

AutoGen offers unusually rich control over agent communication and runtime behavior, but its flexibility creates a large design surface. Teams, distributed runtimes, and code execution can amplify operational and security risk. Its strongest use is a carefully bounded agent system with explicit termination, state, tool, and evaluation contracts.

Recommended workflow

• For a new project, start with Microsoft Agent Framework. For an existing AutoGen project, follow Microsoft's migration guide, and until then pin the last AgentChat packages and use the matching documentation.
• Prove a single-agent baseline.
• Add explicit termination and tool validation.
• Introduce teams only for measured needs.
• Persist and test state transitions.
• Isolate, observe, evaluate, and pin before production.

Pros

• Clear separation between high-level AgentChat and low-level Core.
• Multiple team and handoff patterns with explicit termination controls.
• Strong state, streaming, human-feedback, and extension capabilities.
• Code-execution and MCP integrations are available through extensions.
• MIT-licensed and backed by official migration documentation.

Cons

• Archived and no longer maintained, so vulnerabilities may stay unfixed. Current APIs differ significantly from common legacy examples.
• Multi-agent designs can become expensive and difficult to debug.
• Code execution and distributed runtimes require serious isolation and operations.
• Some advanced team patterns are experimental.
• The framework does not provide production governance automatically.

Alternatives

• Microsoft Agent Framework is the successor Microsoft names, and Microsoft says new users should start there. CrewAI may be better for an opinionated role-and-task multi-agent model.
• LangGraph may be better for explicit durable graph orchestration.
• Haystack may be better when RAG pipeline evaluation is the primary concern.
• Direct SDKs may be better for a single bounded tool-using assistant.

FAQ