Two protocols are shaping how AI agents interact with the world. The Model Context Protocol (MCP) standardizes how agents connect to tools and data sources — think of it as agent-to-tool communication. Google's Agent-to-Agent (A2A) protocol tackles the other half of the equation: how autonomous agents discover, negotiate with, and delegate tasks to each other.
If you're on an API team, A2A matters because it's built entirely on standards you already work with — HTTP, JSON-RPC, and Server-Sent Events (SSE). Every A2A interaction is an API call, which means your API gateway is the natural enforcement point for authentication, rate limiting, and observability on agent-to-agent traffic.
This guide covers what A2A is, how it works, where it fits alongside MCP, and what your team can do today to prepare for agent-to-agent communication at scale.
What Is the A2A Protocol?
The Agent-to-Agent protocol is an open communication standard that enables AI agents — built on different frameworks, by different organizations, running on separate infrastructure — to collaborate directly. Google introduced A2A in April 2025 and donated it to the Linux Foundation as an open-source project. Over 150 organizations now support the protocol, including Atlassian, Salesforce, SAP, PayPal, ServiceNow, Microsoft, and Amazon.
The core idea: agents should be able to work together without exposing their internal state, memory, or tools. A2A provides a structured way for agents to advertise capabilities, negotiate interactions, and coordinate on tasks — all over standard HTTP.
Core Concepts
A2A is organized around a handful of key primitives.
Agent Cards are JSON metadata documents that act as a digital business card
for an agent. Published at a well-known endpoint
(/.well-known/agent-card.json), an Agent Card declares the agent's identity,
service endpoint URL, supported capabilities, authentication requirements, and a
list of skills. Clients parse this information to determine whether an agent is
suitable for a given task and how to communicate with it securely.
Tasks are the fundamental unit of work in A2A. Each task has a unique
identifier and progresses through a defined lifecycle: submitted, working,
input-required, auth-required, completed, failed, canceled, or
rejected. Tasks can complete immediately for simple requests or run
asynchronously for complex, long-running operations. A context identifier
(contextId) can group related tasks together across multiple interactions.
Messages represent individual communication turns between a client and a
remote agent. Each message carries a role (user or agent), a unique
identifier, and one or more content parts. Messages convey instructions,
context, queries, and responses.
Parts are the content containers within messages and artifacts. A2A supports
three part types: TextPart for plain text, FilePart for binary data (inline
or URL-referenced), and DataPart for structured JSON. Parts can also carry
metadata like MIME types and filenames.
Artifacts are the tangible outputs generated by an agent during a task — a
document, image, dataset, or any other deliverable. Like messages, artifacts
consist of one or more parts and can be streamed incrementally using chunking
semantics (append and lastChunk).
Streaming happens over Server-Sent Events (SSE). A client opens a persistent HTTP connection and receives real-time updates as the task progresses — status changes, new message content, or artifact chunks. For disconnected or long-running scenarios, A2A also supports push notifications via client-provided webhooks.
Protocol Transport
All A2A communication happens over HTTP. The client sends a JSON-RPC 2.0 request as an HTTP POST to the server's endpoint. The server responds with a JSON-RPC response (or an SSE stream for streaming methods). Starting with v0.3, A2A also supports an optional gRPC binding for higher-performance deployments.
Clients include an A2A-Version header with each request to ensure protocol
compatibility. The gRPC binding's protobuf definition
(specification/grpc/a2a.proto) serves as the authoritative definition of all
protocol data objects and request/response messages.
A2A vs. MCP: When to Use Each
A2A and MCP solve different problems, and most production agentic systems will use both.
MCP is for agent-to-tool communication. It standardizes how an AI agent discovers and invokes external tools, APIs, and data sources. An MCP server exposes a set of tools — each with a name, description, and input schema — and the agent calls them like functions. MCP is vertical integration: connecting an agent to the capabilities it needs.
A2A is for agent-to-agent communication. It standardizes how autonomous agents find each other, negotiate interaction modalities, and collaborate on tasks. A2A is horizontal collaboration: enabling multiple agents to work together as peers while preserving their internal boundaries.
Here's how the two protocols differ in practice:
- Interaction model: MCP tools are stateless function calls with structured inputs and outputs. A2A tasks are stateful, potentially long-running interactions with lifecycle management.
- Discovery: MCP servers expose a tool list that clients enumerate. A2A agents publish Agent Cards with rich metadata about skills, supported content types, and authentication requirements.
- Communication pattern: MCP uses a host-client-server model where the host orchestrates tool calls. A2A uses a peer-to-peer model where agents communicate directly.
- State management: MCP interactions are typically stateless — call a tool, get a result. A2A tasks carry state across multiple turns and can require additional input mid-execution.
A Practical Example
Consider an enterprise workflow where a customer support agent needs to process a refund. With MCP, the support agent calls tools — a CRM lookup tool, an order management tool, a payment processing tool — to gather information and execute actions. Each tool call is a discrete, stateless operation.
With A2A, the support agent delegates the refund to a specialized billing agent. The billing agent operates autonomously — it has its own tools, its own logic, and its own policies. The support agent doesn't need to know how the billing agent works internally. It sends a task ("process refund for order #12345"), monitors the task status, and receives the result when it's ready.
In this scenario, the support agent uses MCP to connect to its own tools and A2A to collaborate with the billing agent. Both protocols are needed. For a deeper look at the MCP side of this equation, see Best Practices for Mapping REST APIs to MCP Tools.
How A2A Works with API Gateways
Since A2A is built on HTTP and JSON-RPC, every agent-to-agent interaction is an API call. This means your existing API gateway infrastructure applies directly.
Authentication
A2A agents declare their supported authentication schemes in their Agent Cards
using a format aligned with the
OpenAPI Specification security schemes.
The supported types include apiKey, http (Bearer tokens), oauth2,
openIdConnect, and mtls.
The authentication flow follows a three-step pattern:
- Discovery — The client reads the server's Agent Card and identifies the
required auth scheme from the
securitySchemesfield. - Credential acquisition — The client obtains credentials (OAuth tokens, API keys, etc.) through standard external flows.
- Transmission — Credentials are sent in standard HTTP headers
(
Authorization: Bearer <token>,API-Key: <value>, etc.) with every request.
Because A2A uses the same auth patterns as any REST API, your gateway's authentication policies apply directly. Zuplo's built-in policies for JWT/OpenID Connect authentication, API key authentication, and OAuth authentication can validate credentials on A2A requests before they reach your agent.
Rate Limiting
Agent-to-agent communication introduces a new traffic pattern: machines talking to machines at machine speed. Without controls, a misconfigured or runaway agent can flood your services with requests.
A gateway-level rate limiting policy lets you enforce per-agent quotas on A2A task requests. You can limit by API key, authenticated user identity, IP address, or custom attributes — the same patterns you already use for human API consumers. The difference is that agent traffic is more likely to burst, so setting appropriate rate limits early is essential.
Observability
Every A2A request flowing through your gateway generates logs, metrics, and traces. You get visibility into which agents are communicating, how often, what tasks they're creating, and whether those tasks succeed or fail. This is particularly valuable for debugging multi-agent workflows where a failure in one agent can cascade through the system.
Streaming and SSE
A2A's real-time streaming uses Server-Sent Events, and your gateway needs to handle these long-lived connections correctly. Zuplo's edge runtime, built on Web Worker technology with HTTP/2 support, handles SSE and streaming traffic natively — requests and responses flow through the gateway without buffering, so agents receive incremental task updates with minimal latency.
Security Considerations for A2A
A2A was designed with enterprise security requirements from the start. Rather than inventing proprietary security mechanisms, the protocol builds on existing standards.
Transport Security
The A2A specification requires HTTPS for all production deployments. TLS 1.3 or later is recommended with strong cipher suites. This applies to both the JSON-RPC/HTTP binding and the optional gRPC binding.
Agent Card Security
Agent Cards can contain sensitive information about your agent's capabilities and endpoint structure. If your Agent Card includes details you don't want publicly accessible, the specification recommends protecting the card endpoint with access controls. Don't include plaintext secrets in Agent Cards — instead, use auth schemes where clients obtain credentials out-of-band.
Authorization and Scope
Beyond authentication, A2A supports fine-grained authorization. Access can be controlled on a per-skill basis as advertised in the Agent Card. For example, specific OAuth scopes might grant a client agent access to invoke certain skills but not others. Your API gateway can enforce these scope checks as part of its policy pipeline.
In-Task Authentication
Sometimes an agent needs additional credentials during task execution — for
example, when accessing a secondary system on behalf of the user. A2A handles
this by transitioning the task to an auth-required state. The task status
message describes what authentication is needed, and the client can provide the
required credentials to resume the task.
Compliance
A2A's alignment with HTTP and OpenAPI standards means it integrates with existing enterprise compliance infrastructure. Audit logging, data residency policies, GDPR and HIPAA controls — all of these can be applied at the gateway layer because A2A traffic is standard HTTP traffic.
Where A2A Fits in the Zuplo Ecosystem
If you're already using Zuplo for API management, you're well-positioned for A2A.
Zuplo's MCP Server Handler already transforms your API routes into MCP tools, handling agent-to-tool traffic. A2A governance is the natural next step — applying the same gateway capabilities (authentication, rate limiting, logging, analytics) to agent-to-agent traffic.
The AI Gateway provides additional capabilities for managing AI traffic, including cost controls, semantic caching, and guardrails for prompt injection and PII leakage detection. As A2A agents increasingly interact with LLM-powered services, these controls become relevant for governing the AI layer underneath agent-to-agent communication.
And because Zuplo runs at the edge with a runtime built on Web Worker technology, it handles A2A's HTTP, SSE, and JSON-RPC traffic natively — with low-millisecond overhead and near-zero cold starts across globally distributed data centers.
Getting Started: Preparing for A2A Traffic Today
You don't need to wait for a dedicated A2A gateway product to start governing agent-to-agent traffic. Here's what your API team can do now.
1. Audit Your Agent Endpoints
If you're running AI agents that expose HTTP endpoints — whether for MCP, custom agent frameworks, or internal orchestration — those endpoints are candidates for A2A communication. Map them, understand their authentication requirements, and make sure they're behind your API gateway.
2. Apply Standard Gateway Policies
A2A is HTTP. That means your existing gateway policies already work:
- Authentication — Require OAuth tokens or API keys on all agent-facing endpoints.
- Rate limiting — Set per-agent quotas to prevent runaway traffic.
- Request validation — Validate JSON-RPC request structure before it reaches your agent.
- Logging — Capture full request/response data for debugging and compliance.
3. Publish Agent Cards
Even before you implement A2A fully, you can define Agent Cards for your agents. An Agent Card is just a JSON file at a well-known endpoint:
This gives other agents (and your own team) a machine-readable description of what your agent can do and how to authenticate with it.
4. Monitor Agent-to-Agent Traffic Patterns
Start collecting data on how your agents communicate. Track request volumes, latency distributions, error rates, and task completion rates. This baseline will help you tune rate limits, identify performance bottlenecks, and detect anomalies as agent-to-agent traffic grows.
5. Plan for Both Protocols
If you're investing in MCP for agent-to-tool communication, start thinking about A2A for agent-to-agent communication. Zuplo's MCP Gateway already manages agent-to-tool traffic — applying the same governance model to A2A traffic is a natural extension. If you're getting started with MCP, the tutorial Create an MCP Server from Your OpenAPI Spec in 5 Minutes walks through the full setup, and Connecting MCP Servers to an API Gateway covers production deployment patterns. Design your agent architecture with both protocols in mind from the start.
What's Next for A2A
The A2A protocol is evolving quickly. Version 0.3 added gRPC support, agent card signing for enhanced security, and expanded SDK coverage across Python, Go, JavaScript, Java, and .NET. Google's Interactions API (launched in beta in December 2025) maps the A2A protocol surface onto a stateful agent gateway, further simplifying deployment.
The ecosystem is growing too. Auth0 is partnering with Google Cloud to define A2A authentication specifications. Microsoft has integrated A2A into Copilot Studio. Amazon Bedrock AgentCore added native A2A support. And major enterprise platforms — SAP, Salesforce, ServiceNow — are building A2A into their agent frameworks.
For API teams, the message is clear: agent-to-agent communication is coming, and it runs on the same HTTP infrastructure you already manage. The teams that treat A2A traffic with the same governance rigor as traditional API traffic — through their API gateway — will be the ones best prepared for the multi-agent future.
Ready to govern agent traffic through your API gateway? Start with Zuplo for free or explore the MCP Gateway to see how Zuplo handles AI agent traffic today.
