AutoGen GroupChat vs SelectorGroupChat: which to use

The autogen groupchat vs selectorgroupchat decision determines how your multi-agent system picks the next speaker, how much you pay per turn, and how much control you retain over the conversation loop. Both primitives live in the AutoGen ecosystem but target different versions and different ergonomic tradeoffs; choosing wrong means either fighting the framework or shipping fragile selection logic that breaks under load.

Speaker selection mechanics

In classic autogen (0.2.x), GroupChat is a stateful container that holds agents, a message list, and a speaker_selection_method. The default "auto" method asks an LLM to read the transcript and emit the next agent name. You can also use "round_robin", "manual", or pass a custom callable that receives the message list and returns an agent name.

from autogen import AssistantAgent, UserProxyAgent, GroupChat, GroupChatManager

llm_config = {"model": "gpt-4o-mini"}
researcher = AssistantAgent("researcher", llm_config=llm_config)
writer = AssistantAgent("writer", llm_config=llm_config)
user = UserProxyAgent("user", human_input_mode="NEVER")

group = GroupChat(
    agents=[user, researcher, writer],
    messages=[],
    max_round=12,
    speaker_selection_method="auto",  # or "round_robin", "manual", custom fn
)
manager = GroupChatManager(groupchat=group, llm_config=llm_config)

The newer autogen-agentchat (0.4.x) introduces SelectorGroupChat, which bakes LLM-based selection into the class. It requires a model client and a selector prompt; there is no built-in round-robin mode unless you subclass and override select_speaker.

from autogen.agentchat import SelectorGroupChat, AssistantAgent
from autogen.ext.models.openai import OpenAIChatCompletionClient

model_client = OpenAIChatCompletionClient(model="gpt-4o-mini")
researcher = AssistantAgent("researcher", model_client=model_client)
writer = AssistantAgent("writer", model_client=model_client)

group = SelectorGroupChat(
    [researcher, writer],
    model_client=model_client,
    selector_prompt="Pick the agent best suited for the next step given the chat history.",
)

The key difference: GroupChat is a swappable policy over speaker selection; SelectorGroupChat is a single policy with a narrower surface area and async-native execution.

Capabilities

GroupChat supports heterogeneous termination (max_round), custom allowed_speaker_transitions graphs, human-in-the-loop via UserProxyAgent, and dynamic agent addition mid-run. You can enforce that a reviewer only speaks after a generator, which is critical for research pipelines where order matters:

group = GroupChat(
    agents=[researcher, writer],
    messages=[],
    max_round=10,
    allowed_speaker_transitions={researcher: [writer], writer: [researcher, user]},
)

SelectorGroupChat focuses on autonomous selection. It exposes a clean async run() stream and integrates with the new agent primitives (CodeExecutorAgent, ToolAgent). It lacks native round-robin or manual override; if you need deterministic order you must subclass:

class RoundRobinSelector(SelectorGroupChat):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self._idx = 0
    async def select_speaker(self, messages):
        agent = self.agents[self._idx % len(self.agents)]
        self._idx += 1
        return agent

If you need a deterministic fallback when the LLM selector misbehaves, GroupChat with a custom function is simpler. SelectorGroupChat forces that logic into a subclass or a carefully engineered prompt.

Cost model

Both primitives incur the same base token cost for agent responses. The selector step is an extra completion. In GroupChat with speaker_selection_method="auto", the manager sends a truncated transcript to the configured model. Using gpt-4o-mini for that call keeps cost near zero: input tokens are billed at a fraction of a cent per 1K.

SelectorGroupChat always calls the provided model_client for selection. If you reuse the same client as the agents, you pay the same rate; if you point it at a smaller model, you save. There is no free local mode, so static workflows pay a tax on every turn.

# Cheap selector in SelectorGroupChat
selector_client = OpenAIChatCompletionClient(model="gpt-4o-mini")
group = SelectorGroupChat(agents, model_client=selector_client)

When metering per token across many agents, a gateway that provides per-token usage metering (such as n4n.ai) helps attribute selector calls separately from agent calls without custom instrumentation. That matters when a single research job spins up 50 sub-conversations and you need to bill internal teams.

Latency and throughput

LLM-based selection adds one round-trip per turn. On a 100-message research task with auto, you add 100 selector calls. With GroupChat set to round_robin, selection is local and adds sub-millisecond overhead. SelectorGroupChat has no local mode; you must accept the latency or build a cached selector.

A typical gpt-4o-mini selector call on a 4K-token window returns in 200–400 ms depending on region. That serializes your agent pipeline: the next agent cannot speak until the selector returns. Throughput scales with your provider’s RPM. If the selector and agents share a rate limit, you effectively halve agent RPM.

Fronting your clients with a single OpenAI-compatible endpoint that performs automatic fallback when a provider is rate-limited (as n4n.ai does) hides some tail latency, but cannot eliminate the serial dependency. For high-throughput batch jobs, GroupChat with round_robin or a hash-based custom selector wins decisively.

Ergonomics

Classic GroupChat is imperative and mutable. You append to group.messages, inspect state, and restart easily. The GroupChatManager pattern is verbose but debuggable in pdb. Config is dict-based; a typo’d model name fails silently or at runtime.

SelectorGroupChat is declarative and async-first. You construct it and await group.run(task). There is less boilerplate, but stack traces involve async generators and the new cancellation model. Engineers comfortable with asyncio will feel at home; those maintaining legacy scripts may struggle. Type hints in 0.4 are stronger, which catches errors at edit time.

Ecosystem and versioning

GroupChat is the battle-tested core of pyautogen 0.2, with hundreds of community examples, LangChain bridges, and Dockerized demos. If you hire for AutoGen skills, this is what candidates know.

SelectorGroupChat ships in autogen-agentchat 0.4, the rewritten core. It is stable but younger; third-party tools (AutoGen Studio, observational dashboards) lag. Breaking changes between 0.3 and 0.4 were substantial: message schemas, agent constructors, and model client interfaces all changed. Pin your version and isolate upgrades.

Limits and failure modes

Both share context-window limits: the selector sees a truncated history (default last 10 messages in classic, configurable in 0.4), so it can forget early constraints. GroupChat’s auto method sometimes emits invalid JSON; the manager retries but can loop silently. SelectorGroupChat expects a strict response format; a misconfigured prompt raises SelectorError and halts the run unless you wrap it.

Max rounds are your only guardrail against infinite debate. Set max_round aggressively (8–15) and use a summarizer agent to compress context before it overflows. Neither primitive automatically summarizes; you must build that.

Comparison table

Which to choose

Use classic GroupChat when:

• You need deterministic speaker order (round-robin) for reproducible pipelines.
• You must support human-in-the-loop via UserProxyAgent without custom code.
• Your team already runs pyautogen 0.2 in production and cannot absorb a 0.4 rewrite.
• You want to enforce speaker transition graphs (e.g., generator → critic → rewriter) with zero subclassing.
• Latency SLAs demand local selection at high round counts.

Use SelectorGroupChat when:

• You are building greenfield on AutoGen 0.4 and want async streaming out of the box.
• The task is open-ended and benefits from LLM judgment on who speaks next.
• You can tolerate an extra small-model call per turn and want less boilerplate.
• You need native integration with new agents like CodeExecutorAgent or ToolAgent.
• Your team is fluent in asyncio and values static type checking.

If you are shipping a research automation cluster with tight latency SLAs, GroupChat with a non-LLM selector is the only sane default. If you are prototyping an autonomous brainstorming swarm, SelectorGroupChat gets you to a working demo in 20 lines and the selector cost is negligible against agent spend.