A2A — Agent-to-Agent Protocol

What is A2A?

A2A (Agent-to-Agent) is an open protocol for AI agents to discover, authenticate with, and communicate with each other. A site that hosts an agent publishes an Agent Card — a JSON manifest at /.well-known/agent.json — that declares the agent's identity, capabilities, skills, and the URL where other agents can reach it. The protocol was introduced by Google in April 2025 and donated to the Linux Foundation later that year as part of an industry push for an open agent interoperability layer.

A2A sits in a different layer than MCP. MCP defines how an agent calls a tool; A2A defines how an agent calls another agent. The two compose: an MCP server exposes tools to a single agent; an A2A endpoint exposes a whole agent to the wider agent network.

Why A2A matters

The agent ecosystem in 2025-2026 is converging on a multi-agent pattern: a user-facing agent (Claude, ChatGPT, Gemini) coordinates with specialist agents hosted by other services. The booking agent on a travel site is one specialist; the refund agent on an e-commerce site is another. The user-facing agent needs a way to discover those specialists, learn what they can do, and call them — without per-vendor SDK integration.

A2A is the protocol for that discovery and routing layer. An Agent Card tells the calling agent:

Who you are — name, description, version, vendor.
What you can do — a list of named skills, each with its own description.
How to reach you — the URL of your agent endpoint and supported transport (HTTP, SSE, WebSocket).
How to authenticate — the auth scheme, including OAuth flows or API key handoff.

Without A2A, an agent that finds your site has no path from "this site exists" to "this site can help me with refunds via this exact endpoint and this exact auth." A2A is the bridge.

How A2A works

There are two pieces: the Agent Card (discovery) and the A2A endpoint (execution).

1. The Agent Card is a static JSON file at /.well-known/agent.json. Other agents fetch it the same way they fetch any well-known file. A minimal valid Agent Card:

{
  "name": "Acme Support Agent",
  "description": "Handles customer inquiries, refunds, and order status.",
  "version": "1.0.0",
  "url": "https://acme.example.com/agent",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "process-refund",
      "name": "Process Refund",
      "description": "Issue a refund for a given order ID."
    },
    {
      "id": "order-status",
      "name": "Order Status",
      "description": "Look up the status of an order by order ID."
    }
  ]
}

2. The A2A endpoint at the URL declared in the card accepts requests for those skills. The protocol uses JSON-RPC-style messaging over HTTP (with optional SSE for streaming) and supports a structured message format with text, file, and structured-data parts.

The calling agent reads the card, picks a matching skill, authenticates as needed, and POSTs a message to the endpoint. The receiving agent processes it and responds — possibly with streaming if the card declared streaming support.

A2A vs other agent-interop protocols

Protocol	Purpose	Transport	What it exposes
A2A	Agent calls another agent	HTTP/SSE	A whole agent with named skills
MCP	Agent calls a tool	JSON-RPC over HTTP/SSE	Discrete tools on a server
OpenAPI	Agent calls a REST API	HTTP	API endpoints with schemas
SKILL.md	Tells agent how to use a service	Static Markdown	Prose playbook for an HTTP service
WebMCP	Agent calls a website through the browser	Browser API	Annotated HTML forms

A2A is the only one of these where the callee is itself an agent, not a tool or a static API. The difference matters: A2A endpoints can reason, plan, and delegate further. They're peers, not functions.

Agent Card fields

The full Agent Card spec includes:

name — human-readable agent name. Required.
description — what the agent does, in prose. Required.
url — where the A2A endpoint lives. Required.
version — agent version string. Recommended.
provider — vendor info: organization name, URL.
capabilities — feature flags: streaming, pushNotifications, stateTransitionHistory.
skills — array of skill objects with id, name, description, and optional inputModes / outputModes.
authentication — auth scheme details: type (bearer, oauth2, apiKey), and scheme-specific fields.
defaultInputModes / defaultOutputModes — supported content types for skill calls (text, file, data).

AgentGrade's A2A check validates that the card exists, parses as JSON, and contains at least name and url. Richer cards score the same on the binary check but signal to consuming agents that the service is well-integrated.

Who's using A2A

A2A launched with backing from Google and a coalition of partners. Public adopters and integrators in 2025-2026 include:

Google — the original author; A2A is integrated into Vertex AI Agent Builder.
Linux Foundation — A2A was donated to the LF to ensure neutral governance.
Atlassian — published Agent Cards for Jira and Confluence agents.
Box, MongoDB, PayPal, SAP, ServiceNow, Workday — early ecosystem partners listed at launch.

The adoption pattern mirrors OpenAPI's early years: a Google-led specification adopted by enterprise SaaS first, with broader uptake following as multi-agent orchestration moves from research demos to production.

How to add A2A to your service

Decide if you have an agent to expose. A2A is for agents, not static APIs. If your service is a REST API, ship OpenAPI; if it's an MCP tool server, ship MCP. If you have a service that plans, reasons, or holds conversation state, A2A is the right layer.
Author the Agent Card at /.well-known/agent.json. Start with the minimal fields (name, description, url, skills). Add capabilities and authentication as you implement them.
Stand up the A2A endpoint at the URL in the card. The Python SDK at github.com/google/A2A is the reference implementation; JavaScript and other ports exist.
Implement at least one skill. Don't ship an Agent Card listing skills you haven't built — agents that call you and get errors will deprioritize you.
Test with a caller. Use a generic A2A client to verify the card parses and the endpoint responds to a real message.
Link from llms.txt or SKILL.md so non-A2A-native discovery paths find your card.

Common errors scanners flag

No Agent Card — /.well-known/agent.json returns 404. AgentGrade's A2A check is informational; this is not a score penalty, but a missed opportunity for services that do host an agent.
Card returns HTML, not JSON — Single-Page App catch-all routes return the homepage HTML for every path. Serve raw JSON from a static file or framework route that bypasses the SPA fallback.
Missing name or url — the spec's minimum required fields. Cards without these are not callable.
url points to a 404 — the card declares an endpoint that doesn't exist.
Skills array empty or missing — the card validates but there's nothing for an agent to call.
CORS blocks the fetch — agents that read the card from a browser context need Access-Control-Allow-Origin: * or a permissive policy.

FAQ

Is A2A a replacement for MCP?

No. They solve different problems. MCP is for an agent calling a tool; A2A is for an agent calling another agent. A site that hosts a tool server publishes MCP; a site that hosts a whole agent publishes A2A. Some sites do both.

Do I need A2A if I have OpenAPI?

Only if your service is an agent (reasons, plans, holds state across turns). REST APIs ship OpenAPI; agents ship A2A. The two coexist — an A2A agent often calls REST APIs documented in OpenAPI as part of its implementation.

Is A2A required for AgentGrade scoring?

A2A is an informational check, not a scored one. AgentGrade flags the presence of an Agent Card but does not penalize its absence for sites that aren't agents. Static-content sites should not publish empty Agent Cards.

What happens if my Agent Card lies about capabilities?

The card declares what the agent claims; the calling agent will eventually find out via failed requests. As with any declared-vs-verified signal, lying degrades trust over time. AgentGrade's check is currently presence-only and does not probe declared skills.

Can I publish multiple Agent Cards?

The spec is one card per origin. Services that host multiple distinct agents typically split them onto subdomains.

What's the relationship between A2A and Google's Vertex AI Agent Builder?

Vertex AI Agent Builder is Google's hosted agent runtime; it produces and consumes A2A. A2A itself is the open protocol, donated to the Linux Foundation, that Vertex and any other agent runtime can speak.

How do agents discover Agent Cards?

The same way they discover any well-known file: a direct fetch of /.well-known/agent.json, or following a link from /llms.txt. Agent indexes and directories are starting to crawl Agent Cards the way search engines crawl sitemaps.

Does A2A support payment?

The spec includes capability declarations but payment is delegated to the underlying auth scheme. Sites that combine A2A with x402 typically declare the payment requirement in the skill description and gate the endpoint with a 402 challenge.

Spec maturity

Open standard, early adoption. A2A is governed by the Linux Foundation. The Python SDK is the reference implementation. Early adopters are enterprise SaaS; broader adoption is following as multi-agent orchestration moves into production.

Learn more

A2A Protocol Specification — official docs
A2A GitHub repository — reference implementations
MCP — companion protocol for tool calls
Agent Readiness — how A2A fits into the broader picture

agentgrade