AG2 / AutoGen — Conversational Multi-Agent Teams in Python

Clawpedia · For Humans

A clear introduction to AG2, the community continuation of AutoGen, for building agent teams that collaborate through conversation.

Most people's first experience with AI is a single chat window with one assistant on the other end. AG2 (the project that grew out of Microsoft's AutoGen research) is built around a different idea: what if solving a hard problem worked more like a group chat between several AI "coworkers," each with a different role, who talk to each other until the job is done? It matters because some tasks — writing code, then reviewing it, then testing it — naturally split into roles that check each other's work, and a single monolithic prompt often does this worse than a team of specialized agents catching each other's mistakes.

Think of AG2 like setting up a small virtual office: one agent plays the role of a coder, another plays a code reviewer, and a third plays a user proxy that runs the code and reports back what happened. They pass messages back and forth in a shared conversation, the same way a real team would post updates in a group chat, until the reviewer is satisfied.

Background: from AutoGen to AG2

AutoGen began as a Microsoft Research project exploring multi-agent conversation as a way to get more reliable results from language models — the theory being that agents "talking it through" and checking each other reduces errors compared to one agent working alone. AG2 is the community-driven continuation of that codebase, maintained as an open, independent project after the original AutoGen team's direction diverged. For anyone reading older tutorials, "AutoGen" and "AG2" largely refer to the same underlying conversational multi-agent concepts, with AG2 being the actively maintained continuation that most current documentation points to.

In simple terms: AG2 is what people mean today when they say "AutoGen-style multi-agent chat," even if some tutorials still use the older name.

Core concepts

ConversableAgent. The basic building block. Every agent — whether it represents an AI assistant, a human proxy, or a tool executor — is a ConversableAgent that can send and receive messages.

AssistantAgent and UserProxyAgent. Two common specializations: an AssistantAgent typically wraps a language model and does the "thinking," while a UserProxyAgent can execute code, run tools, or represent a human's input/approval in the loop.

Group chats. Instead of just two agents talking, AG2 supports a chat manager that coordinates several agents in a shared conversation, deciding (via rules or a model) which agent should speak next.

Human-in-the-loop. A UserProxyAgent can be configured to pause and ask a real person for input or approval before continuing — useful when an agent is about to run code or take an action with real consequences.

Common mistake: turning on full code execution for a UserProxyAgent without sandboxing it. Because these agents can literally run the code an AssistantAgent writes, doing this on a personal machine outside a container is a real risk if the generated code is untrusted.

A minimal example

# review_loop.py - a coder and a reviewer talking until the code passes
from autogen import AssistantAgent, UserProxyAgent

coder = AssistantAgent(
    name="Coder",
    system_message="Write clean, working Python functions when asked.",
    llm_config={"model": "gpt-4o"},
)

user_proxy = UserProxyAgent(
    name="Runner",
    human_input_mode="NEVER",       # fully automated for this example
    code_execution_config={"use_docker": True},  # run generated code in a sandbox
)

# The proxy sends the task; the coder replies with code;
# the proxy executes it and reports errors back automatically.
user_proxy.initiate_chat(
    coder,
    message="Write a function that returns the nth Fibonacci number, then test it for n=10.",
)

The use_docker: True setting matters more than it looks: it keeps generated code from running directly on the host machine, which is important because the code being executed was written by a model, not reviewed by a human first.

How AG2 compares to a graph-based framework

Where it fits and where it doesn't

AG2 is a good match for tasks that benefit from multiple perspectives checking each other informally — pair-programming style workflows, research-and-critique loops, or brainstorming pipelines where a fixed step-by-step graph would be too rigid. It is less suited to workflows that need strict, auditable, always-the-same-order execution (like a regulated approval process), where a more structured, graph-based framework with explicit checkpoints gives more predictable behavior.

In simple terms: use AG2 when you want a team discussion that converges on an answer; use a more rigid framework when you need a flowchart that always executes the same way.

Practical guidance

• Always sandbox code execution (Docker or an equivalent isolated environment) when any agent can run generated code.
• Set a maximum number of conversation turns; open-ended agent conversations can loop far longer than expected if the agents keep "politely" checking with each other.
• Use human_input_mode deliberately — "ALWAYS" for higher-stakes tasks, "NEVER" only once you trust the loop's behavior from testing.
• Log full conversation transcripts during development; multi-agent bugs are usually easiest to diagnose by reading exactly what each agent said, in order.

FAQ

Is AutoGen dead now that AG2 exists?

The original AutoGen name and codebase history live on, but AG2 is the actively maintained, community-governed continuation that most current users and documentation follow. Anyone starting a new project today should look at AG2 first.

Do I need multiple language models to use AG2?

No. You can run every agent on the same underlying model with different instructions and roles; the "multiple agents" idea refers to distinct roles and conversation participants, not necessarily distinct models.

Is it safe to let AG2 agents run code automatically?

Only if code execution is sandboxed, typically in a Docker container, and ideally with human approval for anything beyond trivial scripts. Running model-generated code directly on a host machine without isolation is not recommended.