Agent2Agent (A2A) Protocol

Google announced A2A in April 2025 with a large group of technology partners. The project was later contributed to the Linux Foundation so that it could be governed in the open. The protocol builds on familiar standards: HTTP for transport, JSON-RPC 2.0 for message structure, and Server-Sent Events for streaming updates. Discovery starts with an Agent Card, a JSON document that an agent usually publishes at a well-known URL. It gives the agent's name, a description, its service endpoint, the skills it offers, the input and output types it accepts, and how clients should authenticate. A client agent reads the card to decide whether this remote agent suits the job. Work is organized around tasks. A client sends a message made of parts, which can be text, files or structured data. The remote agent can create a task that moves through defined states such as submitted, working, input-required, completed, failed or canceled. Results come back as artifacts. For work that takes minutes or hours, the client can stream progress or register a webhook for push notifications instead of holding a connection open. A2A treats remote agents as opaque. The client does not see the other agent's prompts, tools, memory or model, only what it advertises and returns. Vendors can therefore cooperate without exposing their internals. People often assume A2A and MCP compete. They answer different questions. MCP describes how an agent calls tools and reads resources, which are usually well-defined functions with structured inputs and outputs. A2A describes how an agent works with another autonomous agent that has its own reasoning and may need several exchanges to finish. A single system can use both. Another misconception is that A2A handles trust on its own. It declares how to authenticate, but organizations still have to decide which agents to trust and what to share with them.