Architecting a Multi-Agent System with Google A2A and ADK | by Karl Weinmeister | Google Cloud – Community | Apr, 2025

How will you build AI systems with complex reasoning and distinct, specialized skills? Consider financial trading: success requires not just a smart trading strategy, but also rigorous risk management and compliance. How can an AI system excel at both predicting market moves and enforcing trading limits? If you separate these concerns into specialized AI agents, how do you ensure they understand each other’s requests and responses?

This challenge is central to designing systems like the Agentic Trading Simulator. Attempting to build a single, monolithic AI agent to handle both trading strategies and risk checks could lead to complex, tightly-coupled logic that’s difficult to maintain and evolve. The solution is to separate these concerns into specialized agents. However, without a common language, how does the strategy agent reliably ask the risk agent, “Is this trade okay?” and clearly understand the approval or rejection, along with the reasoning? Point-to-point custom integrations are brittle and also challenging to maintain.

This is where Google’s open-source Agent Development Kit (ADK) and the Agent-to-Agent (A2A) protocol come in. ADK offers the structure to build the individual trading strategy and risk management agents, while A2A provides the standardized communication rails defining exactly how they interact. Together, ADK and A2A enable the modular, collaborative architecture essential for this type of application.

This post explores the architectural concepts behind ADK and A2A using this trading simulator as an example, focusing on how these technologies enable effective multi-agent systems.

Our demo application consists of 3 modules:

1. Simulator UI: The “Conductor” acts as the user interface and orchestrator. It drives the simulation loop but delegates the core “thinking” to the specialized agents.
2. AlphaBot ADK Agent: The “Trading Strategist” receives market and portfolio information (via A2A) and determines potential trade actions based on its internal logic (an SMA crossover strategy in this demo).
3. RiskGuard ADK Agent: The “Compliance Officer” receives proposed trades from AlphaBot (via A2A) and evaluates them against predefined risk rules (position size, concentration). It sends back an approval or rejection (via A2A).

The key architectural pattern is the delegation of responsibility facilitated by standardized communication:

The Simulator doesn’t need to know how AlphaBot decides to trade, only how to send it data via A2A and interpret its response. Similarly, AlphaBot doesn’t need to know the specifics of RiskGuard’s rules, only how to propose a trade via A2A and understand the approval status returned.

Please note that this application is intended for educational and demonstration purposes only. It does not constitute financial, investment, legal, or trading advice.

While A2A defines how agents talk to each other, Google’s Agent Development Kit (ADK) provides the essential toolkit for building what they say and how they decide. ADK structures the internal logic of AlphaBot and RiskGuard, enabling them to process information, manage their state, use tools (like calling each other via A2A), and ultimately fulfill their specialized roles within the trading system. It promotes a modular and maintainable approach compared to writing simple monolithic scripts.

The key ADK constructs supporting AlphaBot and RiskGuard are visualized in this diagram, followed by detailed explanation of each:

• Business logic (BaseAgent): The “brain” of each agent resides within a custom agent that implements the BaseAgent base class. This is where Alphabot’s trading strategy logic lives — analyzing prices and deciding potential actions. For RiskGuard, this is where the risk rule evaluation happens. ADK encourages separating this core reasoning from the surrounding communication and execution boilerplate.
• Receiving Input and Context (InvocationContext): How does an agent get the data it needs for its specific task? The InvocationContext is passed into the agent’s run method. It carries the crucial inputs — for AlphaBot, this includes the market data and portfolio state sent by the Simulator UI (via A2A); for RiskGuard, it’s the trade proposal sent by AlphaBot (via A2A).
• Interacting with External Capabilities (BaseTool): Agents rarely work in isolation. They need to call APIs, query databases, or, in our case, talk to other agents. ADK provides a standardized way for an agent to define and invoke these external capabilities using BaseTool. This is precisely how AlphaBot communicates with RiskGuard. We define an A2ARiskCheckTool. AlphaBot’s logic invokes this tool, which encapsulates the details of making the A2A JSON-RPC call to RiskGuard.
• Communicating Results and Actions (Event): Once an agent decides something (like AlphaBot proposing a trade or RiskGuard approving/rejecting it), how does it signal this back? Agents yield Event objects. These events contain the agent’s output (text, structured data, tool results) and can also signal actions like state updates. The Runner processes these events.
• Orchestration and State Management (Runner, SessionService): The Runner orchestrates the agent’s lifecycle — receiving input, calling the agent’s run logic, handling yielded events, invoking tools when requested, and managing the overall flow. For stateful agents like AlphaBot, the SessionService provides the mechanism to store and retrieve state across multiple invocations within the same session. ADK offers implementations like InMemorySessionService (used in our demo), allowing AlphaBot to maintain its trading posture between market updates. RiskGuard, in this demo, is largely stateless, but could use session state if needed (e.g., tracking recent trade velocities).

While ADK structures the agent, A2A defines how agents talk to each other. This standardized protocol based on JSON-RPC over HTTP allows agents built with different frameworks or by different teams to collaborate effectively. Our demo utilizes several core A2A concepts. The sequence diagram below visualizes these A2A concepts in action:

A2A Server: The Agent’s Front Door

To participate in the A2A ecosystem, an agent needs to be hosted within a server that understands the protocol. This server acts as the agent’s public-facing endpoint, listening for standard A2A requests. In our demo, both AlphaBot and RiskGuard are started within an A2AServer instance. This server receives incoming HTTP POST requests, validates if they conform to the A2A JSON-RPC structure, identifies the requested A2A method (like tasks/send), and routes the request parameters to the underlying agent logic (managed by ADK’s Runner via our TaskManager classes).

A2A Client: Initiating the Conversation

Any service needing to interact with an A2A agent acts as an A2A client. The client is responsible for constructing a valid A2A request (typically a JSON-RPC payload) and sending it via HTTP POST to the target agent’s A2A server endpoint. In the simulator, the UI itself acts as an A2A client when it sends market data to AlphaBot using a helper A2AClient class. AlphaBot also acts as an A2A client within its A2ARiskCheckTool when it makes an httpx call to send the proposed trade details to the RiskGuard A2A server.

Agent Card: Discovery and Capabilities

How does a client know where an agent lives and what it can do? The A2A protocol specifies a standard Agent Card. This card contains essential metadata: the agent’s name, description, its A2A endpoint URL, supported features (like streaming), defined skills, and default data formats. Our A2AServer automatically serves the AgentCard defined in each agent’s startup script. While this demo uses configured URLs, a more dynamic system could fetch the Agent Card first to discover how and where to communicate with another agent.

Task: The Unit of Work

The core interactions in A2A revolve around Tasks. A client initiates a task using methods like tasks/send (for request-response) or tasks/sendSubscribe (for streaming updates). The Simulator sends a task to AlphaBot (“Given this market data, decide on a trade”), and AlphaBot sends a sub-task to RiskGuard (“Check if this proposed trade is compliant”). The parameters for these tasks, including the input data and metadata like risk limits, are packaged according to the A2A specification with the TaskSendParams structure.

Message & Parts: Structuring the Data

Data within an A2A task is exchanged using Message objects, which contain one or more Part objects. A2A defines standard part types like TextPart, FilePart, and DataPart. Our demo heavily relies on DataPart to send structured JSON payloads. The market state, portfolio details, trade proposals, and risk parameters are all exchanged using DataPart.

Artifact: Returning Structured Results

When a task completes, how does the agent return potentially complex results? A2A uses the Artifact object. Artifacts are attached to the A2A Task result and can contain various data Parts. In our demo, RiskGuard packages its structured decision into a DataPart within an Artifact. AlphaBot’s A2ARiskCheckTool is designed to look for this named artifact in RiskGuard’s response and extract the decision data.

Want to see the ADK + A2A architecture in action? You can run the Agentic Trading Simulator yourself either locally or deploy it to Google Cloud Run. Start with cloning the Agentic Trading repository and following the Getting Started section in the project’s README.md file. There are two deployment options available:

Running Locally: The simplest way to run the demo on your machine is using the provided deploy_local.sh script.

This script automatically starts the RiskGuard agent, the AlphaBot agent, and the Simulator UI web server using their default local configurations. Once the script indicates the services are running, access the Simulator UI in your browser.

Deploying to Google Cloud Run: To deploy the services to the cloud, the repository includes a script (deploy_cloud_run.sh) that automates the process using Google Cloud Build and Cloud Run.

This script will build container images for each service, push them to Google Artifact Registry, and deploy them as publicly accessible Cloud Run services. It automatically configures the necessary service URLs so the agents and UI can communicate. The script will output the final URL for the Simulator UI once deployment is complete. Note: This makes the demo publicly accessible; review security implications for non-demo use.

In this blog post, we illustrated the core concepts of building collaborative agent systems using the Google Agent Development Kit (ADK) and the Agent-to-Agent (A2A) protocol. The demo application provided a foundation upon which more complex and sophisticated systems can be built. The combination of structured agent development with ADK and standardized communication via A2A paves the way for the next generation of intelligent, distributed AI applications.

To keep the momentum going, you can clone the Agentic Trading demo repository and try it yourself. Consider enhancing the system by adding new agents (like one for sentiment analysis) and integrating them using A2A, or explore more advanced ADK features such as streaming and state management. You could also leverage richer A2A capabilities like dynamic agent discovery via Agent Cards or asynchronous task handling for longer processes. For scaling to production, investigate managed platforms like Vertex AI Agent Engine. Feel free to connect on LinkedIn, X, and Bluesky to continue the discussion!