AutoGen v0.4: Actor Model and Agent Framework

Most agent frameworks are synchronous. One agent produces, another consumes, and the whole thing lives in a call stack. When one call fails, the stack fails with it. Concurrency gets bolted on afterward, and distributing the system across machines means rewriting it.

AutoGen v0.4 answers with the actor model. Each agent is an actor with a private inbox, and messages are the only way actors interact. The runtime separates delivery from handling, so a failure stays inside one actor, concurrency comes for free, and going distributed is just a change of transport.

Actors

An actor is a unit of private state with an inbox and a handler. Nothing outside it touches that state directly. The three pieces:

• State, private to the actor.
• Inbox, a queue of pending messages.
• Handler, receive(message) -> effects, where an effect is one of: reply, send to another actor, spawn a new actor, update state, or stop self.

Two actors cannot share memory. They can only send each other messages.

Three API layers in AutoGen v0.4

1. Core. The low-level actor framework: AgentRuntime, Agent, Message, Topic. Async message exchange, event-driven. A topic is a named channel that agents subscribe to, so one message can reach every subscriber instead of a single recipient.
2. AgentChat. The task-driven high-level API, which replaces v0.2's ConversableAgent. It gives you AssistantAgent, UserProxyAgent, RoundRobinGroupChat, and SelectorGroupChat.
3. Extensions. Integrations for OpenAI, Anthropic, Azure, tools, and memory.

Why decoupling matters

In the v0.2 model, agent_a.chat(agent_b) blocks agent_a until agent_b returns. In v0.4, send(agent_b, msg) drops the message in agent_b's inbox and returns immediately. The runtime delivers it later. That one change has three consequences:

• Fault isolation. If agent B crashes, agent A keeps going. The runtime catches the failure in B's handler and decides what happens next: log it, retry, or dead-letter the message.
• Natural concurrency. Many messages can be in flight at once, and actors work through their inboxes concurrently.
• Distribution-ready. An inbox plus a transport is the same abstraction whether the actor lives in-process or on another host.

Topologies

• RoundRobinGroupChat. Agents take turns in a fixed rotation.
• SelectorGroupChat. A selector agent reads the conversation context and picks who goes next.
• Magentic-One. A reference multi-agent team for web browsing, code execution, and file handling, built on AgentChat.

Observability

OpenTelemetry support is built in. Every message emits a span, and tool calls carry gen_ai.* attributes per the 2026 OTel GenAI semantic conventions (Lesson 23).

Status: maintenance mode

As of early 2026, AutoGen v0.7.x was stable for research and prototyping, and Microsoft had moved active development to the Microsoft Agent Framework (public preview Oct 1 2025, with 1.0 GA targeted for the end of Q1 2026). That target date has since passed, so check the Agent Framework repo for its current release status before choosing it. AutoGen patterns port forward cleanly. The actor model is the part that lasts.

code/main.py is a stdlib actor runtime, built from these pieces:

• Message: a typed payload with sender, recipient, topic, and body, plus a numeric mid. Here topic is a plain string tag that tells a handler what kind of message it got ("review", "start"); it does not do publish-subscribe routing the way AutoGen Core topics do.
• Actor: an abstract class with receive(message, runtime).
• Runtime: an event loop with a shared queue, delivery, and failure isolation. A handler that raises is caught, and the message is parked in a basic dead_letters list with the error text.
• A two-actor demo. ChecklistAgent sends three code snippets to ReviewerAgent, which flags eval( and bare except: and replies with a result for each. The checklist actor then folds the three results into one verdict.

Run it:

python3 code/main.py

The trace shows messages being delivered, a simulated failure (a crash_me message that makes the reviewer raise) that does not stop the remaining reviews, and the checklist actor reaching its verdict (False here, since two snippets are flagged). The demo already has the dead-letter list; Exercise 1 extends it.

Where each option fits:

• AutoGen v0.4/v0.7 (maintenance): stable for research, prototyping, and multi-agent patterns.
• Microsoft Agent Framework (public preview as of early 2026): the forward path. Same actor-model ideas, refreshed API.
• LangGraph swarm topology (Lesson 13): a similar pattern, built on shared-tool handoffs.
• Custom actor runtime: the right call when you need a specific transport such as NATS, RabbitMQ, or gRPC.

outputs/skill-actor-runtime.md generates a minimal actor runtime plus a team template (RoundRobin or Selector) for a given multi-agent task.

1. Extend the demo's dead_letters list into a real dead-letter queue. When a handler raises, park the failing message with enough context (attempt count, timestamp) for human inspection or a bounded retry. How often does the DLQ get hit in your toy?
2. Implement SelectorGroupChat: a selector actor picks who processes the next message based on conversation state.
3. Add distributed transport. Swap the in-process queue for a JSON-over-HTTP server so actors can run in separate processes.
4. Wire an OTel span per message (or a no-op stand-in) and emit gen_ai.agent.name and gen_ai.operation.name per Lesson 23.
5. Read AutoGen v0.4's architecture post, then port your toy to the real autogen_core API. What did you skip that matters in production?

• AutoGen v0.4, Microsoft Research: the redesign post
• LangGraph overview: graph-shaped alternative
• OpenTelemetry GenAI semantic conventions: spans AutoGen emits by default