Introducing agent-to-agent protocol assist in Amazon Bedrock AgentCore Runtime

We not too long ago introduced the assist for Agent-to-Agent (A2A) protocol on Amazon Bedrock AgentCore Runtime. With this addition, brokers can uncover friends, share capabilities, and coordinate actions throughout platforms utilizing standardized communication.

Amazon Bedrock AgentCore Runtime gives a safe, serverless atmosphere designed for deploying AI brokers and instruments. It really works with any framework and mannequin, helps real-time and long-running workloads, and helps session isolation with built-in authentication. With assist for MCP, and now the A2A protocol, Bedrock AgentCore Runtime permits seamless communication between brokers. Brokers constructed utilizing completely different frameworks, Strands Agents, OpenAI Agents SDK, LangGraph, Google ADK, or Claude Agents SDK, can share context, capabilities, and reasoning in a standard, verifiable format.

On this put up, we show how you should utilize the A2A protocol for AI brokers constructed with completely different frameworks to collaborate seamlessly. You’ll discover ways to deploy A2A servers on AgentCore Runtime, configure agent discovery and authentication, and construct a real-world multi-agent system for incident response. We’ll cowl the whole A2A request lifecycle, from agent card discovery to process delegation, exhibiting how standardized protocols remove the complexity of multi-agent coordination.

Understanding multi-agent methods

Constructing efficient agentic methods requires a number of foundational elements. These embody reminiscence, each short-term for sustaining dialog context and long-term for retaining insights throughout classes; instruments that brokers can entry both natively or via MCP servers; identification for safer authentication and permission administration, permitting brokers to behave on behalf of customers or autonomously entry sources; and guardrails to detect dangerous content material, assist forestall hallucinations, and ensure responses align with insurance policies and factual accuracy.

Whereas MCP connects a single agent to its instruments and knowledge, A2A lets a number of brokers coordinate with each other. For instance, a retail stock agent may use MCP to question product databases, then use A2A to speak with exterior provider brokers to put orders.

The A2A protocol brings advantages to multi-agent methods via seamless interoperability throughout numerous boundaries. Brokers constructed with completely different frameworks like Strands or OpenAI, powered by numerous LLMs reminiscent of Anthropic Claude, GPT-4, or Llama, and hosted on completely different methods together with AWS or edge gadgets can talk and coordinate effortlessly with out requiring advanced translation layers. This interoperability is complemented by unfastened coupling and modularity, the place every agent operates as an unbiased unit that may be developed, examined, deployed, and even upgraded with out disrupting your complete system. New specialised brokers can be part of the atmosphere seamlessly, and the failure of 1 agent stays remoted as a consequence of well-defined interplay boundaries, serving to forestall cascading failures throughout the system. The protocol additionally helps dynamic agent discovery and orchestration. Brokers promote their capabilities via standardized schemas whereas orchestrator brokers can uncover and invoke specialised brokers primarily based on real-time process necessities.

A2A request lifecycle on Amazon Bedrock AgentCore Runtime

The A2A protocol defines a structured request lifecycle with particular elements that work collectively to coordinate multi-agent communication. Listed below are the important thing parts:

• Consumer: Initiates requests via the Consumer Agent, both as a human operator or automated service defining targets that require multi-agent help.
• A2A Consumer (Consumer Agent): Acts on behalf of the consumer, initiating communication utilizing the A2A protocol to find and request duties from distant brokers.
• A2A Server (Distant Agent): Exposes HTTP endpoints implementing the A2A protocol to obtain requests, course of duties, and return outcomes. Totally different brokers can serve this position, dealing with each synchronous and asynchronous interactions utilizing JSON-RPC 2.0 over HTTP/S or Server-Despatched Occasions.
• Agent Card: A JSON metadata file that every agent publishes to promote its identification, capabilities, endpoints, and authentication necessities. This permits the dynamic discovery characteristic, the place brokers question what their peer brokers can do earlier than delegating duties.
• Process Object: Represents every unit of labor flowing via the system with a singular ID and lifecycle. As brokers coordinate, duties could also be long-running, contain a number of turns, and span a number of brokers working collectively.
• Artifact: The output produced when a process completes, which may embody structured textual content, JSON, photographs, audio, or different multimodal content material. Brokers change these artifacts as they collaborate to meet the consumer’s unique request.

Multi-agent use case: Monitoring and incident response

To show the facility of multi-agent methods utilizing A2A on Amazon Bedrock AgentCore Runtime, we’ll stroll via an enterprise monitoring and incident response answer. This real-world use-case showcases how specialised brokers constructed with completely different frameworks coordinate seamlessly to deal with advanced operational challenges via the A2A protocol.

The monitoring and incident response answer implements a hub-and-spoke structure with three specialised brokers, every utilizing Amazon Bedrock AgentCore options – modular constructing blocks that present core capabilities like AgentCore Reminiscence for context-aware responses, AgentCore Identification utilizing Amazon Cognito for safer authentication for brokers and what motion every agent can carry out, AgentCore Gateway for safer and centralized entry to instruments, and observability to hint, debug, and monitor AI brokers’ efficiency. View the structure and demonstration video under for reference:

The multi-agent system comprises the next elements:

1. Host agent (Google ADK): Acts because the clever routing layer and coordination hub for the agent interactions. Demonstrates the cross-system interoperability utilizing A2A. This agent runs on Amazon Bedrock AgentCore Runtime utilizing Google’s Agent Development Kit, but communicates seamlessly with brokers hosted on AWS via the standardized A2A protocol. Key duties of the host agent embody:
   • Dynamic agent discovery: Fetches Identification Supplier (IDP) configuration from AWS Methods Supervisor Parameter Retailer for every distant agent, enabling safer authentication throughout the multi-agent system
   • Functionality consciousness: Retrieves agent playing cards from every A2A server to grasp accessible expertise and endpoints
   • Clever routing: Analyzes consumer queries and routes them to the suitable specialist agent primarily based on capabilities
   • Multi-agent coordination: Orchestrates advanced workflows requiring a number of brokers
2. Monitoring agent (Strands Brokers SDK): Serves because the operational intelligence layer, repeatedly analyzing CloudWatch logs, metrics, dashboards, and alarms throughout AWS companies. This agent focuses on figuring out anomalies, monitoring error patterns, and surfacing actionable insights from huge quantities of telemetry knowledge. When uncommon patterns emerge, the monitoring Agent initiates conversations with different specialised brokers to coordinate response actions.Key duties of the monitoring agent embody:
   • CloudWatch integration:
     • Lists and analyzes CloudWatch dashboards
     • Fetches logs for particular AWS companies (Lambda, ECS, EC2)
     • Screens alarms and alert states
     • Analyzes log teams for patterns and errors
   • Cross-account entry: Helps monitoring throughout a number of AWS accounts
3. Operational agent (OpenAI SDK): Supplies remediation methods and exterior data integration. When the monitoring agent detects a important concern, it communicates straight with the operational agent via A2A, offering context about the issue and requesting particular remediation actions. Key duties of the operational agent embody:
   • Internet search: Makes use of Tavily API to seek for AWS finest practices, troubleshooting guides, and options
   • Remediation methods: Proposes options primarily based on detected points

Implementing the multi-agent monitoring answer

Now that we’ve explored how these three specialised brokers collaborate to deal with AWS incidents, let’s stroll via the right way to construct and deploy this multi-agent system utilizing Amazon Bedrock AgentCore Runtime.

The implementation follows a progressive method:

1. Begin with the inspiration – We’ll deploy a easy A2A server to grasp the core mechanics of agent deployment, authentication, and invocation on AgentCore Runtime
2. Construct the monitoring system – Utilizing the identical deployment patterns, we’ll assemble every specialised agent (Monitoring, Operational, and Host) with their particular instruments and capabilities
3. Join the brokers – Configure A2A communication channels between brokers, enabling them to find and invoke one another via standardized protocols
4. Observe the system in motion – Watch the demo video exhibiting real-time incident detection, cross-agent coordination, and automatic response

All code examples, full agent implementations, and deployment scripts for this multi-agent monitoring system can be found in our GitHub repository.

Getting began with A2A on AgentCore Runtime

To grasp the basics of deploying A2A servers on Amazon Bedrock AgentCore Runtime, together with step-by-step directions for creating, testing, deploying, and invoking brokers, confer with the A2A Protocol Help documentation. This information covers:

• Creating and configuring A2A servers with any framework (Strands, OpenAI SDK, LangGraph)
• Native testing and validation
• Deployment utilizing the AgentCore CLI
• Authentication setup (OAuth 2.0 and AWS IAM)
• Agent Card retrieval and discovery
• Consumer implementation for invoking deployed brokers

When you’re acquainted with these fundamentals, you possibly can apply the identical patterns to construct every part of the multi-agent monitoring system.

View the complete instance on this GitHub sample. For this put up, we’ll concentrate on this use case implementation.

Conditions

To deploy the multi-agent monitoring system implementation, comply with the prerequisite steps:

1. AWS account: You want an lively AWS account with applicable permissions
2. AWS CLI: Set up and configure AWS CLI along with your credentials
3. Set up uv.
4. Supported Areas: This answer is at the moment examined and supported within the following AWS Regions.

Word: To deploy in different Areas, you’ll must replace the DynamoDB prefix listing mappings in cloudformation/vpc-stack.yaml. See the VPC Stack documentation for particulars.

Deployment steps

This information walks you thru deploying a multi-agent system on AWS utilizing infrastructure-as-code. The simplest option to deploy this answer is utilizing our automated deployment script:

Step 1: Clone the repository

git clone https://github.com/awslabs/amazon-bedrock-agentcore-samples.git
cd 02-use-cases/A2A-multi-agent-incident-response

Step 2: Run the deployment script

This deployment script will confirm that the AWS CLI is put in and configured, verify if the AWS credentials are legitimate, verify that the Area is about to us-west-2, interactively gather the required parameters, generate distinctive S3 bucket names and robotically deploy all stacks within the appropriate order. The approximate deployment time is 10-Quarter-hour.

Step 3: Present the runtime CLI parameters

Subsequent, present the parameters used at deployment. Press enter for every of the choices to make use of the default Amazon Bedrock mannequin ID and the CloudFormation stack names for every of the brokers.

API keys: You’ll want the next API keys (the deployment script will immediate for these):

Upon getting configured the data, begin the deployment course of and monitor it under within the AWS Console and terminal respectively.

Step 4: Present the runtime CLI parameters

Run the frontend utilizing following instructions. This units up and runs the React frontend UI that enables customers to work together with the multi-agent incident response system for monitoring AWS infrastructure, querying CloudWatch metrics and logs, and looking for remediation methods via the coordinated A2A brokers.

cd frontend
npm set up

chmod +x ./setup-env.sh
./setup-env.sh

npm run dev

This deployment creates a multi-agent A2A system with three specialised AI brokers operating on Amazon Bedrock AgentCore Runtime and orchestrated utilizing the A2A protocol. The Cognito stack provisions OAuth 2.0-based machine-to-machine authentication by making a Cognito consumer pool with 4 distinct consumer functions (WebSearch, Monitoring, Gateway, and Host Agent shoppers).

The monitoring agent (constructed with the Strands SDK) connects to CloudWatch metrics and logs via an AgentCore Gateway utilizing a Smithy mannequin definition, with customized semantic reminiscence methods for incident monitoring.

The operations agent (constructed with OpenAI Brokers SDK) interfaces with Tavily API for remediation analysis and the host agent (constructed with Google ADK) acts because the coordinator utilizing HTTP protocol to delegate duties to the 2 specialised A2A brokers.

Finish-to-end incident response workflow

On this part, we’ll stroll via an end-to-end workflow the place the host agent manages conversations, will get the necessities from the consumer, and selects the perfect agent to route the request to (monitoring or operations agent). The monitoring and operations agent expose their agent playing cards that’s utilized by the host agent for orchestration. On this instance, we’ll check with easy error evaluation from numerous log teams and seek for remediation methods.

The workflow contains the next steps:

1. Preliminary greeting: The consumer sends a greeting message asking “Hello! How are you?” to the host agent. The host agent processes the request. The host agent responds again to the consumer with a pleasant greeting saying “I’m doing nicely, thanks!”
2. Capabilities question: The consumer asks the host agent “What are your capabilities?” to grasp what the agent can do. The host agent explains to the consumer that it’s an orchestration agent designed for AWS monitoring and operations primarily based on the distant agent connections that it has entry to.
3. Record log teams and dashboards: The consumer requests the host agent to listing the log teams and dashboards of their AWS account. The host agent acknowledges this can be a monitoring process and executes the transfer_to_agent device to delegate the work. The request is transferred from the host agent to the monitoring agent for specialised dealing with. The monitoring agent makes use of the Agent-to-Agent (A2A) Json RPC Transport protocol to speak. The monitoring agent retrieves the data and returns outcomes exhibiting 0 dashboards and 153 log teams discovered within the account. The host agent receives the outcomes from the monitoring agent and shows the dashboards and log teams data to the consumer.
4. Analyze particular log group: The consumer requests the host agent to search for errors in a selected log group at path /aws/bedrock-agentcore/runtimes/hostadk-<runtimeId>-DEFAULT. The host agent determines this requires monitoring experience and executes the transfer_to_agent device. The request is transferred to the monitoring agent with directions to investigate the required log group for errors. The monitoring agent analyzes the log group and discovers 9 errors and 18 warnings, particularly figuring out OTLP Export Failures. The host agent receives the evaluation outcomes and shows an in depth error evaluation report back to the consumer.
5. Debug and repair suggestions: The consumer asks the host agent to debug the errors and supply a report on the fixes wanted. The request is transferred to the operations agent to seek for options associated to OTLP export failures. The operations agent makes use of A2A JsonRPC Transport to aim the search and performs net search to offer an answer.

Safety with A2A on Amazon Bedrock AgentCore Runtime

Amazon Bedrock AgentCore Runtime helps two authentication strategies for securing A2A communication:

OAuth 2.0 authentication: The A2A consumer authenticates with an exterior authorization server to acquire a JSON Internet Token (JWT), which is then included with all requests to the A2A server. This token-based method permits safe, standardized authentication utilizing both machine-to-machine (M2M) credentials or consumer federation, permitting the A2A server to confirm the consumer’s identification and implement entry controls primarily based on the token’s claims.

AWS IAM authentication: The A2A consumer assumes an IAM position with permissions to invoke the A2A server’s agent. This method leverages AWS SigV4 request signing and IAM insurance policies to manage entry, assuaging the necessity for exterior token administration whereas offering fine-grained permissions.

What’s supported in Amazon Bedrock AgentCore Runtime with A2A

Amazon Bedrock AgentCore Runtime gives complete assist for A2A communication. View a number of the capabilities supported:

• Stateless server: Amazon Bedrock AgentCore Runtime can host A2A servers that expose an HTTP interface, operating a stateless HTTP server on port 9000 and supporting JSON-RPC messaging. The runtime acts as a clear proxy, passing JSON-RPC requests and responses unchanged to protect protocol constancy.
• Authenticated agent playing cards: Helps authenticated agent card at /.well-known/agent-card.json containing its capabilities & expertise permitting different brokers to find it robotically.
• Authentication with safe inbound auth: Amazon Bedrock AgentCore Runtime helps safe authentication by way of AWS SigV4 and OAuth 2.0, ensuring the agent-to-agent communication is allowed and safe. The A2A server authenticates each incoming request utilizing the credentials offered within the HTTP headers, leveraging Amazon Bedrock AgentCore Identification.
• Authorization with safe outbound auth: Amazon Bedrock AgentCore Runtime permits safe outbound authorization via each IAM execution roles and AgentCore Identification. Every agent assumes an outlined IAM execution position, granting it the required permissions to entry AWS sources extra securely. For interactions with exterior companies, brokers can use Amazon Bedrock AgentCore Identification, which gives managed OAuth 2.0 assist for third-party identification suppliers reminiscent of Google, GitHub, Slack, and extra.
• VPC connectivity: You possibly can configure Amazon Bedrock AgentCore Runtime to connect with sources in your Amazon Digital Personal Cloud (VPC). By configuring VPC connectivity, you allow safe entry to personal sources reminiscent of databases, inner APIs, and companies inside your VPC.
• Leverage AWS PrivateLink: Amazon Bedrock AgentCore permits safe, personal connections between your Digital Personal Cloud (VPC) and AgentCore companies utilizing AWS PrivateLink. By creating interface VPC endpoints, you possibly can maintain A2A server communication inside your VPC with out traversing the general public web.
• Lifecycle administration: Amazon Bedrock AgentCore Runtime allows you to configure lifecycle guidelines to handle useful resource utilization with idleRuntimeSessionTimeout and maxLifetime. Idle or long-running classes are robotically terminated for environment friendly useful resource utilization and to keep up system efficiency.

Conclusion

The Agent-to-Agent protocol assist in Amazon Bedrock AgentCore Runtime gives the assist for constructing scalable, interoperable multi-agent methods. By offering standardized communication between AI brokers, no matter their underlying framework, mannequin, or internet hosting infrastructure, organizations can compose subtle agentic options with the A2A protocol. The AWS monitoring and incident response instance demonstrates the sensible energy of this method: a Google ADK-based orchestrator coordinating with Strands and OpenAI SDK brokers, all deployed on AgentCore Runtime, working collectively to detect points, seek for options, and advocate fixes. This degree of interoperability would historically require in depth customized integration work, however A2A makes it simple via standardized protocols.As AI methods proceed to evolve from single-purpose instruments to collaborative environments, protocols like A2A and MCP grow to be important constructing blocks. They create a future the place brokers might be found, composed, and orchestrated dynamically, enabling organizations to construct as soon as and combine anyplace.

In regards to the authors

Madhur Prashant is an Utilized Generative AI Architect at Amazon Internet Companies. He’s passionate concerning the intersection of human pondering and Agentic AI. His pursuits lie in generative AI, cognitive science and particularly constructing options which are useful and innocent, and most of all optimum for purchasers. Outdoors of labor, he loves doing yoga, mountaineering, spending time along with his twin and enjoying the guitar.

Eashan Kaushik is a Specialist Options Architect AI/ML at Amazon Internet Companies. He’s pushed by creating cutting-edge generative AI options whereas prioritizing a customer-centric method to his work. Earlier than this position, he obtained an MS in Pc Science from NYU Tandon Faculty of Engineering. Outdoors of labor, he enjoys sports activities, lifting, and operating marathons.

Sriharsha M S is a Principal Gen AI specialist answer architect within the Strategic Specialist crew at Amazon Internet Companies. He works with strategic AWS prospects who’re profiting from AI/ML to unravel advanced enterprise issues. He gives technical steering and design recommendation to foundational mannequin science and agentic AI functions at scale. His experience spans utility {hardware} accelerators, structure, huge knowledge, analytics and machine studying.

Jeffrey Burke is an Utilized Generative AI Options Architect at Amazon Internet Companies (AWS), the place he focuses on designing and implementing cutting-edge generative AI options for enterprise prospects. With a ardour for instructing advanced applied sciences, he focuses on translating subtle AI ideas into sensible, scalable options that drive enterprise worth. He has a MS in Knowledge Science and BS in Chemical Engineering.

Shreyas Subramanian is a Principal Knowledge Scientist and helps prospects by utilizing Generative AI to unravel their enterprise challenges utilizing the AWS platform. Shreyas has a background in giant scale optimization and Deep Studying, and he’s a researcher finding out the usage of Machine Studying and Reinforcement Studying for accelerating studying and optimization duties. Shreyas can also be an Amazon best-selling e-book writer with a number of analysis papers and patents to his title.

Andy Palmer is a Director of Know-how for AWS Strategic Accounts. His groups present Specialist Options Structure expertise throughout quite a few speciality area areas, together with AIML, generative AI, knowledge and analytics, safety, community, and open supply software program. Andy and his crew have been on the forefront of guiding our most superior prospects via their generative AI journeys and serving to to search out methods to use these new instruments to each present drawback areas and web new improvements and product experiences.

Sayee Kulkarni is a Software program Growth Engineer on the AWS Bedrock AgentCore service. Her crew is accountable for constructing and sustaining the AgentCore Runtime platform, a foundational part that allows prospects to leverage agentic AI capabilities. She is pushed by delivering tangible buyer worth, and this customer-centric focus motivates her work. Sayee performed a key position in designing and launching Agent-to-Agent (A2A) capabilities for AgentCore, empowering prospects to construct subtle multi-agent methods that autonomously collaborate to unravel advanced enterprise challenges.