# AutoGen Python v0.6.0 Adds Concurrent Agent Execution

> Microsoft shipped AutoGen Python v0.6.0, updating the `select_speaker` method signature on `BaseGroupChatManager` to return either a single agent name or a list of agent names. The change enables concurrent agent execution inside `GraphFlow`, allowing fan-out-fan-in patterns where multiple agents run in parallel within a directed graph workflow.

- Canonical URL: https://agentry.press/news/autogen-python-v0-6-0-adds-concurrent-agent-execution/
- Type: News
- Published: 2026-06-05
- By: agentry
- Tags: autogen, multi-agent, python, microsoft, agent-orchestration, graphflow

---

## What Changed in v0.6.0

Microsoft released AutoGen Python v0.6.0 with a targeted but consequential API change to `BaseGroupChatManager`. The `select_speaker` method, which previously returned a single string representing one agent name, now returns either a string or a list of strings [1]. The updated type hint reads `List[str] | str`, replacing the original `str`-only return type.

The change addresses a structural limitation in `GraphFlow`: prior to this release, the execution model could only activate one agent at a time per selection step. Returning a list of agent names unlocks parallel activation, enabling workflows where multiple agents run simultaneously within a single graph traversal step [1].

## How Concurrent Agents Work in GraphFlow

`GraphFlow` organizes agent execution as a directed graph. Operators use `DiGraphBuilder` to define nodes (agents) and edges (execution dependencies) between them. When `select_speaker` returns a list, `GraphFlow` treats those agents as concurrent participants for that step, running them in parallel before converging results downstream [1].

This is the fan-out-fan-in pattern. A single upstream agent produces output, which fans out to multiple downstream agents executing concurrently. Their outputs then fan back in to a subsequent stage. The pattern is common in pipelines that require parallel processing, such as running multiple transformations or analyses on the same input simultaneously.

## Code-Level Details

The sample code shipped with v0.6.0 illustrates the pattern directly. Three `AssistantAgent` instances are initialized using `OpenAIChatCompletionClient` with the `gpt-4.1-nano` model. Agent A acts as a general assistant, Agent B translates input to Chinese, and Agent C translates input to Japanese [1].

`DiGraphBuilder` wires the graph: Agent A is connected to both Agent B and Agent C via `add_edge` calls, creating a fan-out from A to the pair. The resulting graph object is passed to `GraphFlow` along with the participant list and a `MaxMessageTermination` condition set to five messages [1].

The original and new method signatures side by side show the scope of the change:

```python
# Original signature:
async def select_speaker(self, thread: Sequence[BaseAgentEvent | BaseChatMessage]) -> str:
    ...

# New signature:
async def select_speaker(self, thread: Sequence[BaseAgentEvent | BaseChatMessage]) -> List[str] | str:
    ...
```

The change is confined to the return type annotation and the handling logic that consumes it [1].

## Backward Compatibility Considerations

Operators who have implemented custom subclasses of `BaseGroupChatManager` will need to review their `select_speaker` implementations. The type hint change is technically a breaking change for any code that relies on the method always returning a plain string. Implementations that return a single string remain valid under the new union type, but static type checkers and runtime code that expects only `str` may require updates [1].

Teams using the built-in group chat managers without customization are less likely to be affected, since the interface change is at the base class level and existing single-agent return paths remain supported.

## Use Cases and Target Workflows

The release is aimed at operators building multi-agent pipelines that require parallel processing steps. Translation workflows, as shown in the sample code, represent one category. Broader use cases include any scenario where a single agent's output needs to be processed independently by multiple specialized agents before results are aggregated [1].

Fan-out-fan-in is a standard pattern in distributed task orchestration, and its availability in `GraphFlow` positions AutoGen for workflows that previously required external coordination logic or sequential workarounds.

## FAQ

**Q. Does returning a single string from `select_speaker` still work after v0.6.0?**
Yes. The new return type is `List[str] | str`, so implementations that return a plain string remain valid. Only implementations that need concurrent agent activation must return a list [1].

**Q. What happens if a custom `BaseGroupChatManager` subclass is not updated?**
If the subclass returns a single string, behavior is unchanged. However, static analysis tools may flag the narrower return type as incompatible with the updated base class signature, requiring an annotation update even if runtime behavior is unaffected [1].

**Q. Is `DiGraphBuilder` required to use concurrent agents, or can other team types support this?**
Based on the release notes, concurrent agent execution via the list return type is described specifically in the context of `GraphFlow` and `DiGraphBuilder`. The sources do not indicate that other team types support this pattern [1].

**Q. Which model client is used in the reference implementation?**
The sample code uses `OpenAIChatCompletionClient` with the `gpt-4.1-nano` model, though the API change itself is model-agnostic [1].

**Q. What termination condition is used in the sample, and is it configurable?**
The sample uses `MaxMessageTermination` with a limit of five messages. This is a configurable parameter passed to `GraphFlow` and is not a fixed constraint of the concurrent execution feature [1].

## Key takeaways

- The `select_speaker` return type on `BaseGroupChatManager` changed from `str` to `List[str] | str` in AutoGen Python v0.6.0, enabling concurrent agent activation.
- `GraphFlow` with `DiGraphBuilder` now supports fan-out-fan-in patterns, where one agent's output is processed in parallel by multiple downstream agents.
- Custom subclasses of `BaseGroupChatManager` that implement `select_speaker` should be reviewed for type compatibility after upgrading.
- The reference implementation uses `OpenAIChatCompletionClient` and `AssistantAgent`, with `MaxMessageTermination` controlling workflow length.
- Single-string return values remain valid, making the change backward compatible at runtime for implementations that do not need parallelism.

## Sources

1. https://github.com/microsoft/autogen/releases/tag/python-v0.6.0