Integrating every AI agent with every other agent creates an exponential matrix of API calls, custom authentication, and brittle endpoints. This NxM problem results in an unscalable ecosystem where agents cannot easily share context or negotiate complex tasks (more on the NxM problem here). Platform engineers face a massive integration burden when attempting to link specialized intelligent agents built by different organizations.
The Agent2Agent (A2A) protocol is an open standard designed to solve this interoperability crisis. It enables different AI agents from different companies to communicate seamlessly across distributed networks. It establishes a common semantic layer, allowing an autonomous agent to discover another agent, request an action, and receive structured data without relying on hardcoded, proprietary glue code.
What is the Agent2Agent (A2A) protocol?
The A2A protocol is an open-source communication protocol introduced by Google that enables autonomous AI agents to discover each other’s capabilities, negotiate tasks, and exchange data in a secure, standardized way.
A standard for agent-to-agent communication
The protocol establishes a common language for AI agent collaboration. It replaces proprietary, one-off integrations with a standardized exchange mechanism. This framework allows a specialized semantic agent in one system to securely transmit data and interact with an intelligent agent in another.
Without a standard, developers must write custom handlers for every agent interaction. The A2A protocol solves this by defining an exact specification for how agents format messages, structure their inputs, and interpret responses. This creates a reliable programmatic channel where software entities can establish trust and verify capabilities autonomously.
From Google project to Linux Foundation standard
The A2A protocol was launched by Google Cloud at Google Cloud Next in April 2025 before being donated to the Linux Foundation in June 2025. This transition to an open governance model is critical for enterprise adoption, ensuring vendor-neutrality, preventing corporate lock-in, and building trust among organizations deploying large-scale AI networks.
A decentralized protocol requires widespread community support to function effectively. The Linux Foundation backing signals that A2A is a community-driven standard rather than a proprietary walled garden. Enterprise architects can deploy systems based on A2A, knowing the specification will evolve through open consensus. We can already see this in action, with more than 150 organizations supporting the standard, deep integration with major cloud platforms, and enterprise production by its one-year mark.
Why does A2A matter for developers?
For platform engineers and developers, the A2A protocol drastically reduces integration overhead. It allows teams to build powerful composite AI systems by combining best-in-class agents from various providers. Developers can orchestrate a decentralized digital network where specialized agents handle specific domains.
Relying on an open standard future-proofs applications against a highly fragmented agent landscape. Developers can focus on building intelligent autonomous behavior rather than rewriting API interaction layers every time an agent provider changes its underlying schema. Implementing A2A creates an efficient foundation for scaling multi-agent architectures in production environments.
A2A vs MCP: Horizontal vs vertical integration
The A2A protocol enables horizontal communication between distinct, autonomous AI agents, while the Model Context Protocol (MCP) governs vertical integration between a single agent and its underlying tools.
A2A for horizontal peer-to-peer collaboration
The A2A protocol facilitates interactions between separate entities that possess different specializations. It operates horizontally across a network, like two department specialists collaborating on a cross-functional project.
For example, a travel agent AI might use A2A to communicate with a secure payment agent AI. The travel agent doesn’t know how to process a credit card. It uses A2A to negotiate the transaction, delegate the work, and receive a confirmation message from the payment agent.
MCP for vertical agent-to-tool integration
MCP handles how a specific large language model (LLM) or agent interacts with local datasets, external APIs, and discrete tools. It acts as the standard for connecting an AI model to its immediate environment. An agent uses MCP to read a local database, execute a Python script, or call a traditional REST endpoint. It connects the intelligence layer directly to the data layer.
How A2A and MCP create a complete system
A complete multi-agent architecture relies on both protocols working in tandem. A2A handles the delegation across the network, while MCP executes the specific actions required to complete the task.
| Feature | A2A | MCP |
| Purpose | Horizontal collaboration between distinct agents | Vertical integration between an agent and its tools/data |
| Communication path | Agent to agent (peer-to-peer) | Agent to tool/agent to data source |
| Key components | Tasks, messages, agent cards | Servers, clients, resources, prompts, tools |
| Primary use case | Delegating complex workflows across a multi-agent network | Giving an LLM secure access to local files or specific APIs |
Consider a complex enterprise booking scenario. A primary orchestrator agent interacts with the user. It uses the A2A protocol to task a specialized flight booking agent with finding and reserving seats, as the orchestrator agent doesn’t know how to book flights. The flight booking agent receives the A2A message, interprets the schema, and then uses MCP to securely authenticate and call the airline’s reservation API. This combination provides both horizontal delegation and vertical execution within a single unified transaction.
The core architecture and building blocks of A2A
The A2A protocol architecture relies on a client-server model built atop standard web transport layers, using a specific JSON-RPC data schema to define tasks and messages.
The client-server model: Initiating vs remote agents
A2A interactions require two primary roles to manage the flow of data. The client agent initiates the request and delegates a specific task. The server agent exposes capabilities, processes the incoming request, and performs the requested work.
A critical architectural concept in this model is the “opaque agent.” The client agent doesn’t need to know the server agent’s internal logic, prompting strategy, or underlying model infrastructure. It only interacts with the standardized public endpoint. This separation of concerns allows developers to swap out the server agent’s internal components without breaking the client agent’s integration.
| Role | Primary function | Visibility and concerns |
| Client agent | Initiates requests and delegates specific tasks | Only interacts with the standardized public endpoint; entirely unaware of remote logic |
| Server agent | Exposes skills, processes requests, and performs work | Operates as an opaque agent, hiding its internal models and prompting strategy from the client |
The transport layer: HTTP, JSON-RPC 2.0, and SSE
The A2A protocol utilizes battle-tested web standards rather than introducing proprietary technology. It relies on standard HTTP for stateless request and response interactions. For the messaging format, A2A implements JSON-RPC 2.0. This provides a lightweight, standardized JSON structure for defining remote procedure calls and structuring payloads.
To handle asynchronous operations, A2A implements Server-Sent Events (SSE). SSE streams real-time updates from the server back to the client. This unidirectional stream is vital for long-running autonomous tasks and dynamic user experience negotiation. It ensures the client receives instantaneous feedback on task progress without relying on aggressive, resource-heavy HTTP polling.
The data model: Tasks, messages, parts, and artifacts
The protocol specification defines specific objects to standardize the data exchange:
- A task is the central unit of work within the A2A model. Every task operates on a strict lifecycle, transitioning through defined states such as submitted, working, completed, or failed. The full state set also includes input-required and auth-required (interrupted states awaiting client action) and canceled, rejected, and unknown (terminal states).
- A message represents an individual communication exchange within a specific task. Complex tasks often require multiple messages to clarify parameters or stream progress updates.
Within these messages, data payloads are structured as parts and artifacts:
- A part might contain raw text or simple structured JSON.
- An artifact references larger files, images, or specialized data objects generated during the interaction.
This modular data schema allows agents to handle varied data types efficiently.
| Data component | Description | Typical content |
| Task | The central unit of work with a strict lifecycle state (e.g. submitted, completed) | Overarching task parameters and state tracking |
| Message | An individual communication exchange within a broader task | Status updates, feedback loops, or parameter clarifications |
| Part | A basic modular payload component embedded within a message | Raw text or simple structured JSON data |
| Artifact | A specialized data object generated during the agent interaction | Larger files, generated images, or complex datasets |
How the A2A communication lifecycle actually works
The A2A communication lifecycle progresses through three distinct phases:
- Discovering capabilities via an agent card
- Establishing secure authorization
- Executing the task via JSON-RPC
Step 1: Capability discovery via agent cards
An A2A interaction begins with discovery. The client agent must understand what the server agent can actually do before it can delegate a task. It achieves this by fetching a standard agent card from a well-known location on the server: https://{server_domain}/.well-known/agent-card.json, following the RFC 8615 well-known URI convention. (Older drafts of the spec used agent.json, so you may still encounter that filename in the wild, but agent-card.json is the current canonical name.)
This JSON document acts as a precise machine-readable manifesto. It outlines the agent’s name, description, service URL, version, provider information, protocol-level capabilities (such as streaming and push notifications), authentication requirements, and a list of skills the agent advertises. Unlike traditional RPC contracts, A2A skills describe what the agent does in natural-language terms, including descriptions, tags, and examples, rather than declaring strict parameter schemas. Clients send messages that the agent interprets.
Here is a formatted JSON code block example of an agent-card.json file for a hypothetical weather report agent (served at https://weather-ops.example.com/.well-known/agent-card.json):
{
“name”: “Global Weather Agent”,
“description”: “Provides real-time meteorological data and forecasts.”,
“url”: “https://weather-ops.example.com/a2a”,
“version”: “1.0.0”,
“provider”: {
“organization”: “Weather Ops Inc.”,
“url”: “https://weather-ops.example.com”
},
“capabilities”: {
“streaming”: true,
“pushNotifications”: false,
“stateTransitionHistory”: false
},
“defaultInputModes”: [“text/plain”, “application/json”],
“defaultOutputModes”: [“application/json”],
“securitySchemes”: {
“bearerAuth”: {
“type”: “http”,
“scheme”: “bearer”
}
},
“security”: [{ “bearerAuth”: [] }],
“skills”: [
{
“id”: “get_weather”,
“name”: “Get Current Weather”,
“description”: “Retrieve current weather conditions for a specific location.”,
“tags”: [“weather”, “forecast”],
“examples”: [
“What’s the weather in London, UK?”,
“Get current conditions for Tokyo in metric units”
],
“inputModes”: [“text/plain”, “application/json”],
“outputModes”: [“application/json”]
}
]
}
Step 2: Authentication and authorization
The A2A protocol features a security-first design that assumes zero trust between distributed agents. Before any task negotiation occurs, the network connection must be verified. The specification supports multiple layers of security to validate access and protect endpoints.
For transport-level security, A2A relies on mutual TLS (mTLS) to encrypt the channel and verify the cryptographic identity of both endpoints. For user-delegated authority, it implements OAuth 2.0. This allows an agent to act on behalf of a human user with strictly defined scopes. For simpler internal architectures, basic API keys provide baseline authorization.
Security is not an afterthought; it is a mandatory gateway for every valid A2A transaction. Establishing strict API key security best practices ensures malicious actors can’t hijack the multi-agent system.
Read more about AI agent auth and zero trust here.
Step 3: Task creation and execution
Once authenticated, the client constructs a Message containing one or more Parts and sends it to the server using the message/send or message/stream JSON-RPC method. The message references the relevant skill (such as get_weather) and includes the user’s request in natural language or as structured data.
The server agent acknowledges the task creation and begins execution. Since AI processing often involves high latency, the server uses SSE to stream status updates. This keeps the client informed as the task transitions from submitted to working.
During this execution phase, the protocol allows for user experience negotiation. If the server agent requires additional input, such as a user needing to complete a multi-factor authentication prompt, it can stream back UI components for the client application to render. Once the operation finishes, the server transmits a final message containing the success state and the requested data artifact.
How to implement a basic A2A interaction (with code examples)
Implementing a basic A2A interaction requires setting up a server agent to expose its skills via an agent-card.json file at the /.well-known/ path, and building a client agent to parse that file and send messages via A2A’s JSON-RPC methods.
Setting up the server agent
A server agent must expose itself over HTTP and handle incoming JSON-RPC requests. The server initializes its identity, registers one or more skills it advertises, and binds a local execution function to each skill.
Using a conceptual Python A2A library, developers can define the interaction parameters explicitly. The framework automatically generates and serves the agent card at /.well-known/agent-card.json based on these registered skills.
Here is the conceptual Python code to configure a server agent:
from a2a_framework import AgentServer, Skill
# Initialize the server agent
weather_agent = AgentServer(
name=”Global Weather Agent”,
description=”Provides real-time meteorological data and forecasts.”,
url=”https://weather-ops.example.com/a2a”,
version=”1.0.0″
)
# Define the execution logic
def fetch_weather_data(message):
# Parse the incoming A2A Message, extract the location from its Parts,
# then retrieve data from a meteorological API
return {“temperature”: 22, “condition”: “Sunny”}
# Register a skill the agent advertises
weather_agent.register_skill(
skill=Skill(
id=”get_weather”,
name=”Get Current Weather”,
description=”Retrieve current weather conditions for a specific location.”,
tags=[“weather”, “forecast”],
examples=[“What’s the weather in London, UK?”]
),
handler=fetch_weather_data
)
# Start the server on port 8080
# The Agent Card is served automatically at /.well-known/agent-card.json
weather_agent.serve(port=8080)
Creating the client agent
The client agent initiates the interaction across the network. It first fetches the remote server’s agent card to verify the endpoint is compliant and that the target skill is advertised.
After successful discovery, the client constructs an A2A Message containing one or more Parts (text, structured data, or files) and sends it via the message/send or message/stream JSON-RPC method. It then listens to the SSE stream for real-time progress updates.
Here is the conceptual Python code to configure the client agent:
from a2a_framework import AgentClient, Message, TextPart
# Instantiate client and discover skills
client = AgentClient(target_url=”https://weather-ops.example.com”)
client.discover() # fetches /.well-known/agent-card.json
# Send a message to the agent (A2A is message-based, not RPC-style)
message = Message(
role=”user”,
parts=[TextPart(text=”What’s the current weather in London, UK in metric units?”)]
)
task = client.send_message(message=message)
# Listen for updates and final completion via SSE
for event in task.stream_events():
if event.status == “working”:
print(“Task is executing…”)
elif event.status == “completed”:
print(“Task completed successfully.”)
result = event.get_result()
Handling artifacts and results
When the server completes the required work, it sends a final JSON-RPC response containing the artifact. This artifact holds the structured data the client originally requested.
The client parses this response to extract the specific values. A successful JSON-RPC payload contains the task ID, a status object whose state is completed, and an artifacts array. Each artifact contains one or more Parts, typically a DataPart for structured JSON, a TextPart for prose, or a FilePart for binary content:
{
“jsonrpc”: “2.0”,
“id”: “req-001”,
“result”: {
“id”: “task_98765”,
“status”: { “state”: “completed” },
“artifacts”: [
{
“artifactId”: “weather-result-001”,
“name”: “weather_data”,
“parts”: [
{
“kind”: “data”,
“data”: {
“temperature”: 22,
“condition”: “Sunny”,
“location”: “London, UK”
}
}
]
}
]
}
}
The client application interprets this structured schema and routes the data to the next logical step in its workflow. It processes the temperature and condition data programmatically, without needing to understand how the remote server derived it.
Limitations and architectural considerations of A2A
While the A2A protocol standardizes agent communication, its point-to-point design creates severe scalability challenges and complex network topologies if deployed without centralized governance.
The point-to-point scalability dilemma
The A2A protocol functions fundamentally as a point-to-point standard. In a small deployment, direct communication between two isolated agents is highly efficient. In an enterprise system running hundreds of specialized AI agents, this approach breaks down quickly.
Directly connecting every agent to every other agent leads to a tightly coupled, highly brittle architecture. Managing certificates, enforcing rate limits, and tracing failures across thousands of independent peer-to-peer connections becomes an operational nightmare. This contrasts sharply with message bus architectures, where traffic flows through predictable, centralized channels. A pure A2A implementation without network-level control creates a fragmented system that is difficult to secure and audit.
| Network architecture | Flow characteristics | Enterprise scalability and security |
| Pure point-to-point | Direct, isolated peer-to-peer connections between all agents | Breaks down quickly; managing certificates and tracing failures is highly complex |
| API gateway/message bus | Traffic routes dynamically through predictable, centralized channels | Highly scalable; enables centralized authentication, auditing, and rate limiting |
The role of orchestrators and API gateways
To mitigate this point-to-point complexity, platform engineers must deploy an orchestrator agent or a dedicated API gateway as a central control plane.
An API gateway sits as an intermediary within the agent network, intercepting A2A traffic to manage discovery, enforce authentication, and route requests dynamically. Instead of 100 agents maintaining individual mTLS certificates for each peer, the gateway handles transport layer security centrally.
Tyk provides the necessary observability to track AI processing costs, prevent shadow AI usage, and implement strict rate limits across the entire multi-agent system. Utilizing API orchestration patterns transforms a chaotic network of A2A endpoints into a secure, governed enterprise platform.
Frequently asked questions
What is an A2A agent card?
An A2A agent card is a standardized JSON document hosted by a server agent to declare its identity and capabilities. It operates as a machine-readable manifesto that allows client agents to discover what skills the server advertises, how to authenticate, and what input and output formats are supported. The file is served at /.well-known/agent-card.json on the agent’s domain, following the RFC 8615 well-known URI convention.
Is the A2A protocol ready for production?
The A2A protocol is actively transitioning into enterprise production environments following its move to the Linux Foundation. The core specification is stable and relies on mature web standards like HTTP and JSON-RPC. Organizations deploying it today must implement an API gateway to manage scaling, security, and observability across the resulting network traffic.
How does A2A handle security between agents?
The A2A protocol handles security by enforcing transport layer encryption and explicit authorization for every programmatic transaction. It utilizes mutual TLS (mTLS) to encrypt the communication channel and verify the identity of both the client and server endpoints. For task-level authorization, it supports OAuth 2.0 to ensure agents only access data and execute commands within their strictly permitted scope.
Can A2A be used without MCP?
The A2A protocol operates entirely independently of the Model Context Protocol (MCP). A2A focuses strictly on network-level communication and task delegation between separate, autonomous agents. While the two protocols are complementary in complex architectures, an agent can use A2A to communicate with peers while relying on traditional internal logic instead of MCP to execute tasks.
What programming languages support the A2A protocol?
The A2A protocol is language-agnostic because it relies entirely on standard HTTP and JSON payloads. Developers can implement A2A clients and servers in any programming language capable of parsing JSON and making network requests, including Python, Go, TypeScript, and Rust. Official and community-driven SDKs continue to emerge to abstract the boilerplate code across these enterprise languages.
Does A2A replace traditional APIs?
The A2A protocol does not replace traditional APIs. Rather, it builds a semantic orchestration layer on top of them. It provides a standardized wrapper that helps AI models dynamically discover and negotiate the use of underlying endpoints. Traditional REST, GraphQL, and gRPC interfaces remain the foundational data layer that these intelligent agents ultimately interact with.
Conclusion
The A2A protocol serves as the open-source standard for solving AI agent interoperability. By operating under the Linux Foundation, it provides a vendor-neutral framework for secure, horizontal communication across distributed networks.
The specification works exceptionally well alongside MCP. A2A handles the horizontal agent-to-agent collaboration, while MCP governs the vertical agent-to-tool integration. Because A2A builds on practical web standards like HTTP, JSON-RPC, and SSE, it easily integrates into modern technology stacks. However, its point-to-point nature requires strict architectural governance. Large-scale enterprise deployments demand API gateways to manage routing, enforce security policies, and prevent chaotic network topologies.
As multi-agent systems become the default architecture for enterprise AI, mastering open standards like the A2A protocol is a critical engineering requirement. Building the next generation of intelligent, composite applications requires abandoning proprietary integration models in favor of transparent, standardized exchange.
Explore how Tyk can help you manage, secure, and orchestrate your A2A-based agent communications at scale. Learn about Tyk AI Studio or speak to the Tyk team to find out more.