Using Google's Agent Development Kit and Agent2Agent



Table of contents

What is the Agent2Agent protocol?

Enhance Workflow Productivity: By standardizing the methods for task delegation, context sharing, and information exchange between agents, allowing for more seamless automation.
Reduce Integration Overhead: By providing a common communication backbone and interface definition, significantly lowering the engineering effort and costs associated with connecting diverse agent systems.
Accelerate Compound Innovation: By making it technically simpler for developers to build novel applications that compose or chain the specialized capabilities of various agents through these standardized interfaces.

Key design principles of the Agent2Agent protocol

Embracing Agentic Capabilities: This isn't just about simple request-response interactions. The protocol is fundamentally designed acknowledging that AI agents possess agency – the ability to reason, plan, operate autonomously, and make decisions to achieve goals. A2A aims to support these sophisticated capabilities, allowing agents to engage in complex, multi-step collaborations, not just basic data exchange.
Building on Existing Standards: Agent2Agent leverages established, widely adopted web and internet standards – such as HTTP, RESTful principles, and security patterns like OAuth – wherever possible. While specific standards referenced may evolve, the core principle is to build upon existing, proven technologies. This approach accelerates development, improves interoperability with existing infrastructure, and makes it easier for developers already familiar with these standards to adopt and implement the Agent2Agent protocol.
Ensuring Security by Default: When you have autonomous agents potentially acting on behalf of users or systems, security cannot be an afterthought. Agent2Agent incorporates security considerations right into its core design. This means defining mechanisms for authentication, authorization, and secure data exchange from the outset, ensuring that agent interactions are trustworthy and protected against misuse.
Supporting Long-Running Tasks: Real-world work often isn't instantaneous. An agent might be tasked with something complex that takes significant time – think planning an entire vacation, generating a detailed report, or processing a large dataset. The Agent2Agent protocol is explicitly designed to handle these asynchronous, long-running operations, managing the communication and state tracking required for tasks that might span minutes, hours, or even longer.
Being Modality Agnostic: Collaboration shouldn't be restricted by the type of information being handled. Whether agents need to exchange text, images, structured data, voice commands, or other forms of information (modalities), the protocol aims to be flexible. Agent2Agent is designed to facilitate interactions involving diverse data types, ensuring it can support a wide range of applications and agent capabilities without being tied to a single mode of communication.

Core components of the Agent2Agent protocol



Agent Card: This is essentially an agent's digital identity and capability statement. Imagine a standardized business card or a manifest file for an AI agent.The Agent Card contains crucial metadata, likely including:
Identification: Who the agent is.
Capabilities: What tasks the agent can perform or what services it offers.
Endpoints: How other agents can communicate with it (e.g., API addresses).
Requirements: Any necessary information for interaction, potentially including security protocols or data formats it expects. The primary function of the Agent Card is discovery – allowing potential clients (other agents or systems) to find agents and understand their basic offerings and how to connect.


A2A Server: This component typically runs alongside the agent that is providing a service or capability (often referred to as the 'remote agent' in an interaction). Its main responsibilities are:
Listening: It exposes an endpoint that listens for incoming requests formatted according to the Agent2Agent protocol specification.
Processing: It receives valid Agent2Agent requests, interprets them, and interfaces with the actual underlying AI agent logic to execute the requested task.
Managing: It handles the lifecycle of the task, which is particularly important for the long-running operations mentioned in the design principles.
Responding: It sends back responses, status updates, or final results to the requesting client, again using the standardized Agent2Agent format. Essentially, the A2A Server acts as the host and execution handler for an agent's capabilities within the A2A framework.
A2A Client: This is the component that initiates the interaction. It could be another AI agent, an application, or a user-facing interface that needs to leverage the capabilities of a remote agent. The Agent2Agent Client's role involves:
Discovery (using Agent Cards): Finding the appropriate agent and understanding how to interact with it.
Request Formulation: Constructing a request message that adheres to the Agent2Agent protocol's standards, specifying the desired task and providing necessary input data.
Communication: Sending the request to the target agent's A2A Server endpoint.
Response Handling: Receiving and processing the response (or updates) from the A2A Server. The A2A Client is the initiator and consumer of services within an agent2agent interaction.

Facilitating communication and task management

Task Initiation: It typically begins with the A2A Client. Let's say one agent (acting as the Client) needs another agent's (the remote agent's) specialized skill – perhaps summarizing a document or analyzing an image. Having discovered the remote agent and its capabilities (likely via its Agent Card), the Client constructs a task request. This isn't just a casual message; it's a carefully formatted request adhering to the A2A protocol's specifications. This standardized request clearly outlines the desired action and includes any necessary input data (like the document to be summarized).
Transmission and Processing: The Client then sends this protocol-compliant request to the designated endpoint of the remote agent's A2A Server. When the Server receives the request, its first job is often to validate it – ensuring it follows the Agent2Agent rules. Once validated, the Server interprets the request and invokes the underlying logic of its associated AI agent, passing along the task details and input data. This kicks off the actual work.
Managing the Interaction (Especially for Longer Tasks): Here's where the design principle for handling long-running tasks becomes crucial. If the requested task takes more than a few moments, the A2A Server might not just sit silently. The protocol allows for mechanisms where the Server can acknowledge receipt of the task immediately and then potentially provide periodic status updates back to the A2A Client ("Processing started," "50% complete," etc.). This prevents the Client from being stuck waiting in the dark and allows for more dynamic, real-time monitoring of progress.
Completion and Response Delivery: Once the remote agent completes the assigned task, the A2A Server takes the result (or any errors encountered), packages it into a standardized response format defined by the Agent2Agent protocol, and sends it back to the originating A2A Client.
Receiving and Utilizing Results: The A2A Client receives this structured response. Because it's formatted according to the Agent2Agent standard, the Client knows exactly how to parse it, extract the relevant information (the summary, the analysis results, etc.), and then use it for its own purposes, perhaps presenting it to a user or feeding it into the next step of a larger workflow.

Real-world applications and future of Agent2Agent

Send a standardized request to a specialized flight-search agent (running its own A2A Server), providing your criteria.
Simultaneously or sequentially, query a hotel-booking agent (another A2A Server) for availability and pricing, perhaps even using potential flight times from the first agent as input.
Reach out to a local events and recommendations agent (yet another A2A Server) to find concerts, tours, or restaurant suggestions matching your interests for those dates.

Multi-Agent System Focus: Agent Development Kit is explicitly designed for building applications composed of multiple specialized agents, facilitating complex coordination and delegation between them.
Flexibility in Models & Tools: It allows developers to choose their preferred LLMs (Gemini, models via Vertex AI Model Garden, or many others through LiteLLM integration) and equip agents with a wide array of tools – from pre-built functionalities like Search to third-party libraries (LangChain, LlamaIndex) and even using other agents as tools.
Rich Interaction: Agent Development Kit supports advanced interaction models, including unique bidirectional audio and video streaming capabilities for more natural, human-like conversations.
Full Lifecycle Support: Beyond just building, ADK provides flexible orchestration options, an integrated local development experience (CLI and Web UI), built-in evaluation frameworks for assessing agent performance, and streamlined paths for deployment (containerized or optimized for Google Cloud's Vertex AI).

Tutorial: Building a multi-agent system

Setting up our toolkit

google-adk: This is the star of the show – Google's Agent Development Kit. It provides the core framework for defining our agents, their tools, managing interactions (facilitating the kind of agent collaboration we've discussed), and orchestrating the overall system.
litellm: To showcase ADK's flexibility, we'll use litellm. This library acts as a bridge, allowing our ADK agents to potentially use a wide variety of Large Language Models, not just those from Google (think OpenAI, Anthropic, etc.).
weave: As agent systems become more complex, understanding what's happening inside is crucial. We'll integrate W&B Weave to add observability, helping us track, visualize, and debug our agent's behavior and decision-making process.
pyowm: Let's give our agent a practical skill! This library provides a convenient way to connect to the OpenWeatherMap API and fetch real-time weather data.
newsapi-python: To add another dimension, we'll use this library to fetch current news headlines on specific topics via the NewsAPI.

What we'll build

Managing conversational pleasantries via specialized greeting and farewell sub-agents.
Fetching and reporting real-time weather conditions using the pyowm library and an external API.
Retrieving the latest news headlines for a user-provided topic using newsapi-python.
Implementing safety checks:
An input guardrail to block requests containing a specific keyword.
A tool-use guardrail preventing the weather tool from being used for a specific city (e.g., "Paris").

import os
import warnings
import logging
import asyncio
from typing import Optional, Dict, Any
import weave

# External API Clients
import pyowm
from newsapi import NewsApiClient

# ADK Components
from google.adk.agents import Agent
from google.adk.models.lite_llm import LiteLlm  # For potential multi-model use
from google.adk.sessions import InMemorySessionService
from google.adk.runners import Runner
from google.adk.tools.tool_context import ToolContext
from google.adk.tools.base_tool import BaseTool
from google.adk.agents.callback_context import CallbackContext
from google.adk.models.llm_request import LlmRequest
from google.adk.models.llm_response import LlmResponse

# Google Generative AI types
from google.genai import types as google_types
from dotenv import load_dotenv

# Load environment variables
load_dotenv()

# --- Configuration ---
warnings.filterwarnings("ignore")
logging.basicConfig(level=logging.INFO)


weave.init("Google-Agent2Agent")

# --- Define Model Constants ---
MODEL_GEMINI_2_0_FLASH = "gemini-2.0-flash"

Define the tools

In ADK, Tools are the building blocks that give agents concrete capabilities beyond just text generation. They are typically regular Python functions that perform specific actions, like calling an API, querying a database, or performing calculations.

# Greeting and Farewell Tools
@weave.op()  # Add weave decorator
def say_hello(name: str = "there") -> str:
    """Provides a simple greeting."""
    logging.info(f"Tool 'say_hello' executed with name: {name}")
    return f"Hello, {name}!"


@weave.op()  # Add weave decorator
def say_goodbye() -> str:
    """Provides a simple farewell message."""
    logging.info("Tool 'say_goodbye' executed.")
    return "Goodbye! Have a great day."

Adding real-world capabilities: Weather and news tools

Real-Time Weather: We'll define a get_real_weather function. This tool will use the pyowm library to connect to the OpenWeatherMap API, fetching the current weather conditions for a city specified by the user. Importantly, this tool will also interact with the agent's memory (session state via ToolContext) to potentially use or remember user preferences, like their preferred temperature unit (Celsius or Fahrenheit).
Latest News Headlines: Next, we'll add a get_latest_news function. This tool leverages the newsapi-python library to query the NewsAPI for recent headlines based on a topic the user provides.

@weave.op()  # Add weave decorator
def get_real_weather(city: str, tool_context: ToolContext) -> dict:
    """Retrieves the current real weather report for a specified city using OpenWeatherMap."""
    logging.info(f"Attempting to get real weather for city: '{city}'")

    owm_api_key = os.environ.get("OWM_API_KEY")

    try:
        # Initialize PyOWM
        owm = pyowm.OWM(owm_api_key)
        mgr = owm.weather_manager()

        # Get Weather Observation
        logging.info(f"Querying OpenWeatherMap API for city: {city}")
        observation = mgr.weather_at_place(city)
        w = observation.weather
        if w is None:
            # This case might be rare if NotFoundError is caught, but good to check
            logging.error(f"OWM observation for '{city}' did not contain weather data.")
            raise ValueError(f"Weather data not available in OWM response for {city}")
        # Extract Temperature (Kelvin)
        temp_data = w.temperature("kelvin")
        if not temp_data or "temp" not in temp_data:
            logging.error(f"Could not find 'temp' in OWM temperature data: {temp_data}")
            raise ValueError("Temperature data missing 'temp' key in OWM response.")
        temp_k = temp_data["temp"]  # Direct access after check
        logging.debug(f"Temperature (Kelvin): {temp_k}")

        # Read unit preference from state
        preferred_unit = tool_context.state.get(
            "user_preference_temperature_unit", "Celsius"
        )
        # Convert temperature
        if preferred_unit == "Fahrenheit":
            temp_c = temp_k - 273.15
            temp_value = (temp_c * 9 / 5) + 32
            temp_unit = "°F"
        else:  # Default to Celsius
            temp_value = temp_k - 273.15
            temp_unit = "°C"
        logging.debug(f"Converted temperature: {temp_value:.1f}{temp_unit}")

        # Extract other details
        status = w.detailed_status
        humidity = w.humidity
        wind_speed = w.wind().get("speed", "N/A")
        # Format Report
        report = (
            f"The current weather in {city.capitalize()} is '{status}' "
            f"with a temperature of {temp_value:.1f}{temp_unit}. "
            f"Humidity is {humidity}%, and wind speed is {wind_speed} m/s."
        )

        result = {"status": "success", "report": report}
        # Update last checked city in state
        tool_context.state["last_city_checked_stateful"] = city.capitalize()
        logging.info(f"Updated state 'last_city_checked_stateful': {city.capitalize()}")
        return result

@weave.op()
def get_latest_news(topic: str) -> dict:
    """Fetches the latest 5-10 news headlines for a given topic using NewsAPI."""
    logging.info(f"Tool 'get_latest_news' called for topic: {topic}")

    news_api_key = os.environ.get("NEWS_API_KEY")
    try:
        newsapi = NewsApiClient(api_key=news_api_key)

        # Fetch news articles related to the topic, sorted by published date (latest first)
        # Using 'everything' endpoint for broader search on a topic
        articles_data = newsapi.get_everything(
            q=topic, language="en", sort_by="publishedAt", page_size=10
        )  # Get up to 10 articles

        if articles_data["status"] != "ok":
            raise Exception(
                f"NewsAPI returned status: {articles_data.get('code', 'unknown')} - {articles_data.get('message', 'No message')}"
            )

        articles = articles_data["articles"]

        if not articles:
            summary = f"I couldn't find any recent news articles about '{topic}'."
            logging.warning(f"No news articles found for topic: {topic}")
            return {
                "status": "success",
                "news_summary": summary,
            }  # Success, but no articles

        # Format the top 5-10 headlines
        num_headlines = min(len(articles), 10)  # Show up to 10
        headlines_list = []
        for i, article in enumerate(articles[:num_headlines]):
            title = article.get("title", "No Title")
            source = article.get("source", {}).get("name", "Unknown Source")
            headlines_list.append(f"{i+1}. {title} ({source})")

        summary = (
            f"Here are the latest {num_headlines} headlines I found about '{topic}':\n"
            + "\n".join(headlines_list)
        )
        result = {"status": "success", "news_summary": summary}
        logging.info(f"Fetched {num_headlines} news headlines for topic: {topic}")
        return result

Implementing safety: Input guardrails with before_model_callback

Inspect: Examine the entire request package destined for the LLM.
Modify: Carefully alter parts of the request if needed (e.g., adding context, filtering content).
Block: Completely stop the request from reaching the LLM if it violates predefined rules, and instead return a specific response directly to the user.

Filtering out sensitive data (PII) or inappropriate language from user prompts.
Implementing keyword-based blocking for off-topic or policy-violating requests.
Dynamically adding timely information (like today's date or info from session state) to the prompt context just before the LLM sees it.

If the request is acceptable, your function returns None. Agent Development Kit sees this and proceeds to call the LLM as normal.
If the request needs to be blocked, your function constructs and returns an LlmResponse object. This object contains the message you want the user to receive instead. ADK intercepts this response and sends it back immediately, effectively canceling the LLM call for that turn.

Define a Python function, let's call it block_keyword_guardrail, designed as a before_model_callback. Its simple job will be to check if the user's latest input contains the word "BLOCK" (ignoring case).
Modify the definition of our main root agent to tell Agent Development Kit it should execute this block_keyword_guardrail function before any call to its primary LLM.
Set up the ADK Runner to use this newly configured agent.
Perform test interactions, sending some normal requests and one containing the "BLOCK" keyword, to verify that the guardrail correctly intercepts the problematic request while allowing others through.

Adding alayer: Tool Usage guardrails with before_tool_callback

Argument validation & sanitization: Check if the arguments provided by the LLM make sense. Are they the right type? Within allowed ranges? Do they need cleaning up before being passed to the tool?
Resource/policy enforcement: Prevent specific tool executions based on the arguments. For example, blocking API calls for certain parameters to manage costs, blocking access based on user permissions stored in state, or, as in our upcoming example, preventing queries for specific restricted entities (like a particular city).
Dynamic argument modification: You could use information from the ToolContext (like session state) to adjust or add arguments just before the tool runs.

If you want to allow the tool to run (potentially with modified arguments you've adjusted directly within the args dictionary), your function should return None. ADK will then proceed to execute the original tool function.
If you want to block the tool call entirely and substitute a different result, your function should return a dictionary. ADK intercepts this dictionary and treats it as the actual result of the tool call for this turn, completely skipping the execution of the original tool function. This returned dictionary should ideally match the expected structure of the tool's output (e.g., providing a custom error message in the same format the tool would use).

Define a Python function, block_paris_tool_guardrail, as our before_tool_callback. It will specifically check if the tool being called is our weather tool (get_real_weather) and if the city argument provided by the LLM is "Paris" (case-insensitive).
If it detects this specific scenario, the callback will return a custom error dictionary, effectively blocking the actual call to the OpenWeatherMap API.
Update the root agent definition one last time, configuring it to use both the before_model_callback (for input keyword blocking) and this new before_tool_callback (for blocking the Paris weather check).
Set up the ADK Runner associated with this final, doubly-guarded agent configuration.
Run test interactions, requesting weather for allowed cities and then specifically for "Paris", to demonstrate the tool guardrail preventing the restricted call while allowing others.

# Model Guardrail
def block_keyword_guardrail(
    callback_context: CallbackContext, llm_request: LlmRequest
) -> Optional[LlmResponse]:
    """Inspects user input for 'BLOCK', blocks if found."""
    agent_name = callback_context.agent_name
    logging.debug(f"Callback 'block_keyword_guardrail' running for agent: {agent_name}")
    last_user_message_text = ""
    if llm_request.contents:
        for content in reversed(llm_request.contents):
            if content.role == "user" and content.parts:
                if isinstance(content.parts[0], google_types.Part) and hasattr(
                    content.parts[0], "text"
                ):
                    last_user_message_text = content.parts[0].text or ""
                    break
    keyword_to_block = "BLOCK"
    if keyword_to_block in last_user_message_text.upper():
        logging.warning(f"Keyword '{keyword_to_block}' found. Blocking LLM call.")
        callback_context.state["guardrail_block_keyword_triggered"] = True
        logging.info("Set state 'guardrail_block_keyword_triggered': True")
        return LlmResponse(
            content=google_types.Content(
                role="model",
                parts=[
                    google_types.Part(
                        text="I cannot process this request (blocked keyword)."
                    )
                ],
            )
        )
    else:
        logging.debug(f"Keyword not found. Allowing LLM call for {agent_name}.")
        return None


# Tool Guardrail
def block_paris_tool_guardrail(
    tool: BaseTool, args: Dict[str, Any], tool_context: ToolContext
) -> Optional[Dict]:
    """Blocks 'get_real_weather' tool execution for 'Paris'."""
    tool_name = tool.name
    agent_name = tool_context.agent_name
    logging.debug(
        f"Callback 'block_paris_tool_guardrail' running for tool '{tool_name}' in agent '{agent_name}'"
    )
    logging.debug(f"Inspecting tool args: {args}")

    # *** UPDATED target_tool_name ***
    target_tool_name = "get_real_weather"
    blocked_city = "paris"

    if tool_name == target_tool_name:
        city_argument = args.get("city", "")
        if city_argument and city_argument.lower() == blocked_city:
            logging.warning(
                f"Blocked city '{city_argument}' detected for tool '{tool_name}'. Blocking execution."
            )
            tool_context.state["guardrail_tool_block_triggered"] = True
            logging.info("Set state 'guardrail_tool_block_triggered': True")
            return {  # Return error dictionary, skipping the actual tool
                "status": "error",
                "error_message": f"Policy restriction: Weather checks for '{city_argument.capitalize()}' are disabled by a tool guardrail.",
            }
        else:
            logging.debug(f"City '{city_argument}' is allowed for tool '{tool_name}'.")
    else:
        logging.debug(f"Tool '{tool_name}' not targeted by Paris guardrail. Allowing.")

    logging.debug(f"Allowing tool '{tool_name}' to proceed.")
    return None  # Allow tool execution

Defining the Agents

name: A unique string that identifies this agent within your application (e.g., "greeting_agent", "news_fetcher"). This is helpful for organization, logging, and debugging.
model: This parameter specifies the "brain" of the agent – the LLM that will power its reasoning and responses. Here you'll typically provide a model identifier string (like our constant MODEL_GEMINI_2_0_FLASH) or use the LiteLlm wrapper (if you want to leverage models from other providers like OpenAI or Anthropic.
description: This is a concise, high-level summary of the agent's main purpose or capability. As we'll see when setting up our agent team, this description plays a crucial role in enabling delegation, as other agents use it to understand what this agent specializes in and when to pass tasks to it.
instruction: Consider this the detailed operational manual for the agent's LLM. It's where you provide specific guidance on its persona, goals, conversational style, constraints, and – critically – clear instructions on when and how it should employ the Tools listed in its configuration. Effective prompting here is vital for reliable tool usage and overall agent behavior.
tools: This is simply a Python list containing the actual tool functions (like say_hello, get_real_weather, get_latest_news) that this specific agent is authorized and equipped to use.

greeting_agent = Agent(
    model=MODEL_GEMINI_2_0_FLASH,
    name="greeting_agent",
    instruction="Greet the user friendly.",
    description="Handles simple greetings and hellos.",
    tools=[say_hello],
)
farewell_agent = Agent(
    model=MODEL_GEMINI_2_0_FLASH,
    name="farewell_agent",
    instruction="Provide a polite goodbye.",
    description="Handles simple farewells and goodbyes.",
    tools=[say_goodbye],
)


news_agent = Agent(
    model=MODEL_GEMINI_2_0_FLASH,  # Can use a different model if desired
    name="news_agent",
    instruction="You are a News Reporter agent. Your goal is to fetch and present the latest news headlines on a specific topic requested by the user. Use the 'get_latest_news' tool. Clearly state the topic and present the headlines returned by the tool. If the tool returns an error or no news, inform the user politely.",
    description="Fetches and presents the latest 5-10 news headlines for a given topic using the 'get_latest_news' tool.",
    tools=[get_latest_news],
)


root_agent = Agent(
    name="weather_news_assistant",
    model=MODEL_GEMINI_2_0_FLASH,  # Orchestration model
    description="Main assistant: Handles real weather requests, delegates news requests, greetings, and farewells. Includes safety guardrails.",
    instruction=(
                "You are the main Assistant coordinating a team. Your primary responsibilities are providing real-time weather and delegating other tasks.\n"
                "1.  **Weather:** If the user asks for weather in a specific city, use the 'get_real_weather' tool yourself. The tool respects temperature unit preferences stored in state.\n"
                "2.  **News:** If the user asks for news on a specific topic (e.g., 'latest news on AI', 'updates on electric vehicles'), delegate the request to the 'news_agent'.\n"
                "3.  **Greetings:** If the user offers a simple greeting ('Hi', 'Hello'), delegate to the 'greeting_agent'.\n"
                "4.  **Farewells:** If the user says goodbye ('Bye', 'Thanks bye'), delegate to the 'farewell_agent'.\n"
                "Analyze the user's query and delegate or handle it appropriately. If unsure, ask for clarification. Only use tools or delegate as described."
            ),
            tools=[get_real_weather],  # Root agent handles weather directly
            sub_agents=[greeting_agent, farewell_agent, news_agent],
            output_key="last_assistant_response",
            before_model_callback=block_keyword_guardrail,
            before_tool_callback=block_paris_tool_guardrail,
        )

adk web

Notice how the agent delegates to the greeting agent in the first message and fetches the real time weather in the second message.



Also notice how the agent fetches the real time news

Weave for monitoring the agents

We can see the exact prompt and the communication exchange between different agents in our Weave dashboard.





Bridging worlds: Connecting our ADK agent via Agent2Agent

Agent systems built using different frameworks (like ADK on the left, another framework on the right) can communicate with each other using the A2A protocol for inter-agent collaboration, while potentially using other protocols like MCP (Model Context Protocol) to interact with their specific tools and APIs.

A2A vs. MCP: A Quick Distinction

MCP generally focuses on connecting agents to tools, APIs, and resources in a structured way. ADK itself supports MCP, allowing agents built with it to leverage a wide range of tools.
A2A specifically targets agent-to-agent collaboration. It enables dynamic, often multi-modal communication between different agent systems without them needing to share internal details like memory, resources, or specific tool implementations.

Opaque Execution: If our Weather Bot exposes its service via A2A, a calling agent only needs to know what skill to ask for (e.g., get_weather) and the expected input/output format via the Agent Card. It doesn't need to know we used ADK, PyOWM, or have internal sub-agents. A2A hides the internal complexity.
Async First: Our get_latest_news tool might take time. A2A's asynchronous design (polling, SSE, Push Notifications) means our Weather Bot could handle longer operations without blocking the caller, providing status updates (TaskStatusUpdateEvent) if needed via streaming.
Modality Agnostic: While we used text, A2A's Part object allows defining support for other data types (application/json, image/png, etc.) via the Agent Card, enabling richer interactions.
Enterprise Ready & Simple: Using HTTP/JSON-RPC and standard authentication practices (like passing tokens in headers, declared via the Agent Card) makes A2A suitable for business use while leveraging familiar tech.

Basic info: name: "ADK Weather & News Bot", description, url (the A2A endpoint).
Authentication: Specifying the required scheme (e.g., schemes: ["OAuth2"]).
Capabilities: Like streaming: true if it supports SSE for news updates.
Skills: An array describing what it can do:
Skill 1: id: "get_weather", name: "Get Current Weather", description: "Retrieves real-time weather for a city.", tags: ["weather", "real-time"], examples: ["weather in london"], inputModes: ["text/plain"], outputModes: ["text/plain"]
Skill 2: id: "get_news", name: "Get Latest News", description: "Fetches recent news headlines for a topic.", tags: ["news", "headlines"], examples: ["news about AI"], inputModes: ["text/plain"], outputModes: ["text/plain"]

Request (tasks/send): The Client constructs a JSON-RPC request targeting our A2A server's URL (via HTTP POST). The method is "tasks/send". The params include a unique task id and a message object (role: "user") containing parts (e.g., a TextPart with the query).
Processing: Our A2A server wrapper receives this, validates the request/auth, extracts details.
Internal ADK Execution: The wrapper triggers our internal ADK Weather Bot logic (passing the query). The ADK agent runs its flow (state, guardrails, tools).
Response (Task Object): The ADK agent returns the result. Our A2A wrapper formats this into an A2A Task object (with the original id, sessionId, status: "completed", and an artifacts array containing the weather report in an Artifact with a TextPart). This Task object is sent back as the JSON-RPC result.

Our Bot as Server: Wrapped with an A2A server layer, our ADK Weather Bot can serve requests from any A2A-compliant client, whether built with LangGraph, Crew.AI, Microsoft Autogen, etc.
Our Bot as Client: Our ADK agent could call other agents via A2A. If asked for flight prices, it could act as an A2A Client, discover a flight agent's Agent Card, send an A2A tasks/send request, and process the A2A Task response. This demonstrates direct collaboration between our ADK agent and agents built using different technologies.

Conclusion