Breaking Agent Silos: AgentCore Runtime Now Supports the A2A Protocol

AgentCore Runtime Gains A2A Support

Amazon Bedrock AgentCore Runtime now implements the Agent‑to‑Agent (A2A) protocol, providing a standardized communication layer that lets agents built with Strands, OpenAI SDK, LangGraph, Google ADK, Claude SDK, or other frameworks exchange context, capabilities, and reasoning results without custom middleware.

Core Components of a Multi‑Agent System

Memory : short‑term memory for dialogue context and long‑term memory for persisting insights.

Tool Integration : agents can invoke tools via MCP servers.

Identity : secure authentication and permission management, allowing agents to act on behalf of users.

Safety : real‑time harmful‑content detection and hallucination prevention.

A2A Request Lifecycle

The lifecycle consists of five roles:

User : initiates a request either manually or via an automated service.

A2A Client : represents the user, discovers remote agents, and forwards tasks.

A2A Server : an HTTP endpoint that receives JSON‑RPC 2.0 or Server‑Sent Events requests, processes them, and returns results.

Agent Card : a JSON metadata file (served at /.well-known/agent-card.json) that advertises an agent’s identity, capabilities, endpoint, and authentication requirements.

Task Object : a unique identifier and lifecycle description for each work item, supporting long‑running, multi‑round interactions.

Result : the output generated after task completion, which may be text, JSON, images, audio, or other multimodal data.

Monitoring & Incident‑Response Use Case

A three‑agent “center‑radiating” architecture demonstrates the protocol:

Host Agent (Google ADK): routes user queries, discovers capabilities, and orchestrates workflows.

Monitoring Agent (Strands SDK): scans CloudWatch logs, metrics, and dashboards, identifies anomalies, and reports findings.

Ops Agent (OpenAI SDK): searches external knowledge bases (via Tavily API) and generates remediation steps.

The end‑to‑end workflow includes greeting, capability discovery, listing logs/dashboards, error analysis of a specific log group, and finally fault‑resolution suggestions, with concrete numbers (e.g., 153 log groups found, 9 errors and 18 warnings detected).

Implementation Steps

Deploy a simple A2A server on AgentCore Runtime to understand agent deployment, authentication, and invocation.

Build the monitoring system by configuring each specialized agent with memory, Cognito‑based identity, gateway, and observability modules.

Enable A2A communication channels for dynamic discovery and inter‑agent calls.

Observe the system via the provided demo video.

All code and deployment scripts are available in the GitHub repository:

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

Run the deployment script: uv run deploy.py Configure the frontend:

cd frontend
npm install
chmod +x ./setup-env.sh
./setup-env.sh
npm run dev

Security Mechanisms

AgentCore Runtime supports two authentication methods for A2A communication:

OAuth 2.0 : clients obtain a JWT from an external authorization server; the token is sent with every request for identity verification and access control.

Amazon IAM : clients assume an IAM role; requests are signed with SigV4, enabling fine‑grained policy enforcement without external tokens.

Supported Features and Operational Controls

Stateless HTTP server on port 9000 using JSON‑RPC.

Authenticated Agent Card at /.well-known/agent-card.json.

Inbound authentication via OAuth 2.0 or SigV4.

Outbound authorization using IAM roles and AgentCore Identity.

VPC connectivity and PrivateLink for private network traffic.

Lifecycle management with idleRuntimeSessionTimeout and maxLifetime parameters.

Conclusion

The A2A protocol in Amazon Bedrock AgentCore Runtime provides a robust foundation for building highly extensible, interoperable multi‑agent systems. By abstracting away framework‑specific details, it enables enterprises to compose agents across different models, runtimes, and cloud or edge deployments, turning complex integration work into a standardized, reusable workflow.