Leveraging Agent-to-Agent (A2A) with Strands part 1

As our generative AI landscape evolves ever faster with each passing day, I hear of more and more releases whether it be new Large Language Models, orchestration frameworks to run them like our very own strands-sdk, protocols to standardize how they interact with tools using Model Context Protocol (MCP), or interaction among agents using Agent-to-Agent (A2A). In this post, I will dive into building out a CLI tool leveraging A2A and strands agent to help us perform unit conversions.

The strands-agents SDK is a release that I was particularly excited about. AWS has given developers a really strong middle ground with which to build and facilitate their agentic applications and workflows. Strands sits right in the middle of bare bones converseAPI calls, and fully managed Bedrock Agents. Building with the converseAPI being the most flexible. but also the most work required to add integrations like memory and tools into. Bedrock Agents on the other hand facilitates memory, session management, and more, but is less flexible. Strands, as an orchestration framework sits right in between, giving developers flexibility while offloading a large portion of the boiler plate coding.

Once we have chosen how to build and orchestrate our agents, how do we allow them to communicate? Enter A2A. The A2A protocol seeks to standardize LLM agent interaction by exposing agent capabilities from the agent server to a client, and allowing that client to choose what agent is best to use, much like passing tools to an LLM, as you might now perform using MCP. The customizations possible with A2A, and MCP are seemingly endless.

Now that I have reviewed the two main elements of our A2A - strands agent project, let's step through the code and finally run the agent.

First let's get an idea of how our application will flow:

Looking at our diagram, you can see that we will need to build our client, the server, an agent executor and our agent.

For this example, you will need to install the following dependencies:

Our A2A client will also be where I put the logic to interact with our agent from the command line.

This is where I will define our strands agent and what model, tools, etc that it has.

This code defines our agent's skills, and runs the server application.

The agent executor is responsible for receiving and extracting the context from the request and passing it to the agent.

Now that the necessary files have been created, I can run the agent server and interactive client to test the functionality.

When you start the client, you'll see initialization output like:

Once both server and client are running, you can interact with the agent:

The agent will respond with the correct mathematical conversion outputs:

In this blog post, I've shown you how to create an interactive client that uses A2A to send requests to a strands agent that can perform mathematical conversions. For next steps, I will be writing part two, showing how to swap out the interactive client for a routing agent, that can then decide which of the sub agents to call based on a task using A2A!