Agent Teams in Google ADK 2.0

Google Agent Development Kit (ADK) 2.0 introduces Collaborative Agent Teams to handle complex tasks that cannot be modeled as strict, deterministic workflows. These are ideal for iterative processes involving several substantial sub-tasks.

If you're building multi-agent systems, Agent Teams allow you to build a self-managing coordinator agent that automatically delegates tasks to a team of specialized subagents with specific roles and modes of operation.

The Core Concept: Coordinators and Subagents

When dealing with a massive task, relying on a single monolithic Language Model is inefficient. Instead, ADK 2.0 uses a Coordinator and Subagent architecture:

1. Coordinator (Parent Agent): Analyzes the user's request, determines what needs to be done, and delegates sub-tasks to specialized subagents.
2. Subagents: Execute their specific tasks and automatically return their results back to the parent coordinator.

This creates a completely self-managing system.

Travel Planner Architecture

Here is a high-level visual representation of the Travel Planner coordinator managing its three specialized subagents. Notice how each agent is equipped with specific tools to accomplish its role:

Execution Flow

Once the architecture is defined, here is how the execution flows between the user, the coordinator, and the subagents:

Operating Modes

To make the system predictable and reliable, ADK 2.0 introduces Operating Modes. You assign these modes strictly to your subagents to limit their scope and dictate their behavior:

Feature \ Mode	chat (Default)	task	single_turn
Human in the Loop	Full interaction	For clarification only	Disallowed
User interaction	User chats freely with agent	Agent asks questions as needed	No user interaction
Control flow	Agent controls until manual handoff	Agent controls until task complete	Returns immediately after task
Parallel execution	Not supported	Not supported	Multiple tasks can run in parallel
Return to parent	Manual (via transfer)	Automatic (via complete_task)	Automatic (with result)

How It Works: The Travel Planner

Based on the sequence diagram above, here is exactly how the execution flows between the different agents in the team:

1. Coordinator Agent (travel_planner)

The root agent acts as the manager. When the user asks to "Plan a trip to Paris", the coordinator analyzes the prompt and decides how to split the work. You simply pass the weather, flight, and itinerary agents into its sub_agents list.

• Auto-Injected Routing Tools: ADK automatically injects routing tools into the coordinator. Under the hood, it is given tools like request_task_weather_checker, request_task_flight_booker, and request_task_itinerary_agent. The coordinator uses these tools to delegate work to the subagents.

2. Subagent: Single-Turn Mode (weather_checker)

The coordinator delegates the weather check. Since weather_checker is in single_turn mode, it operates entirely in the background.

• It uses its geocode_address and get_weather tools to fetch the data.
• Because checking the weather is a straightforward API call, it doesn't need to bother the user with questions. It completes its work and returns the data immediately to the coordinator.

3. Subagent: Task Mode (flight_booker)

Next, the coordinator delegates flight booking. Booking a flight is complex and requires specific data (defined by strict input_schema and output_schema).

• Because it is in task mode, the agent takes control and is allowed to pause and ask the user clarifying questions (e.g., "Do you prefer a window or aisle seat?").
• Once it gets the necessary information, it uses the book_flight tool and automatically returns the confirmation back to the coordinator.

4. Subagent: Chat Mode (itinerary_agent)

Finally, the coordinator delegates the itinerary planning. Brainstorming an itinerary is highly collaborative, so this agent uses chat mode for full human-in-the-loop interaction.

• It uses tools like search_local_attractions and chats back and forth with the user.
• Control remains with this agent until the user is completely satisfied, at which point the agent manually calls complete_task() to hand control back to the parent coordinator.

Under the Hood: Transfers & Context

How your agent transfers control depends on where you use it:

• Workflow Graph: If you use a task agent inside a traditional Workflow Graph (Sequential or Parallel), the system advances to the next node in the graph once the task is done.
• LlmAgent Transfer: If transferring from an LlmAgent using a request_task tool, the subagent does its job, calls complete_task, and control bounces right back to the originating parent agent.

Context Isolation: If you run multiple task or single-turn agents in parallel, they are completely isolated in their own session branches. They cannot see what their peer agents are doing, keeping context windows clean and cheap. Once all parallel branches finish, the parent agent gathers their independent results and decides how to proceed.

Limitations

• Task mode agents MUST be leaf agents: In the ADK 2.0 Alpha release, a Task agent cannot have its own subagents. Hierarchies must be kept clean: Coordinator at the top, task and single-turn agents at the bottom doing the work.