Feature Proposal: Native Support for Multi-Agent Group Chat (GroupChat / Dialogue Orchestration) API

[jghwwnq]

Problem Description

Currently, the Google Agent Development Kit (ADK) 2.x provides powerful APIs for single-agent execution (LlmAgent/Agent) and graph-based execution (Workflow/JoinNode). However, it lacks a native API for conversational-based multi-agent group chats (GroupChat / Dialogue Orchestration), similar to AutoGen's GroupChat and GroupChatManager.

When building collaborative applications (like digital employee platforms) where multiple agents need to work in a shared conversation space:

1. Dialogue-driven collaboration (e.g., dynamic multi-turn brainstorming, negotiation, or handoffs) is difficult to express cleanly using rigid Directed Acyclic Graphs (Workflow).
2. Developers are forced to either:
   • Build a custom database-backed state-machine on top of ADK's Runner or LlmAgent to orchestrate who speaks next and format the message stream (which is how we currently work around it).
   • Write complex custom Python async code to manually handle turn-taking, which lacks standard API support.

Proposed Feature / Behavior

We propose adding native support for a Group Chat / Dialogue Orchestrator API in ADK. This could include:

1. GroupChat Container: A class that manages a shared conversation history and a collection of participant agents.
2. GroupChatManager (or DialogueOrchestrator): An agent that decides the next speaker based on:
   • Dynamic LLM-based selection (e.g., choosing the next speaker based on chat history).
   • Preset transition rules (e.g., a state machine or allowed transition graph).
   • Standard routines (e.g., round-robin, random, manual human input).
3. Structured Event Emission: Streaming events that include metadata about the active speaker (e.g. agent_id, node_id) so that frontends can easily route streaming tokens to correct UI elements without interleaving.

User & Platform Impact

• Developer Experience: Significantly reduces boilerplate code when building multi-agent discussion groups, brainstorming channels, or collaborative task-solvers.
• Flexibility: Complements ADK's graph-based Workflow engine by offering a conversational alternative, allowing developers to choose the right paradigm (structural DAG vs. dynamic dialogue) for the task at hand.
• Enterprise Readiness: Makes it easier to build user-friendly UI/UX around multi-agent collaboration (such as enterprise digital employee group chats) with clear speaker attribution and trace streaming.

[jghwwnq]

Use Case Addendum: Parallel Workflows & Parallel Summary Workflows in Group Chat

To provide more concrete context, a major scenario where this native API is needed is Parallel Workflows (Fan-out) and Parallel Summary Workflows (Gather/Join) executed within a single group chat session:

1. Parallel Execution: A user in a group chat tasks multiple agents with different subtasks simultaneously (e.g., @AgentA write frontend code, @AgentB write backend code). These subtasks run concurrently.
2. Parallel Summary (Join): A third agent (e.g., @AgentC summarize the work) is scheduled to run only after both Agent A and Agent B have submitted their results.

Currently, representing this concurrent execution flow inside a 1D linear group chat UI is extremely challenging because:

• If parallel agents stream their reasoning traces and outputs concurrently, their WebSocket events interleave and scramble the text in a single chat stream.
• Developers have to manually compile these parallel nodes into ADK Workflows, manage temporary session states, map the results back to the chat history, and send custom metadata to help the frontend separate the streaming output into different UI cards.

A native ADK GroupChat API should support orchestrating these parallel execution blocks and natively structuring the stream metadata (e.g. grouping by parallel run/node IDs) so that frontends can easily render parallel-processing cards and summary nodes inside a conversational interface.