The Agent2Agent Protocol (A2A) is an open standard for communication between AI agents built on different frameworks and operated by different vendors. Using capability documents called Agent Cards and a shared task lifecycle over standard web transports, A2A lets independent agents discover one another, delegate work, and exchange results as peers.
Why A2A matters
Multi-agent systems rarely stay inside one codebase. A support agent may need to hand a task to a billing agent built by another team on a different framework, or to a vendor’s agent running outside the firewall entirely. Without a shared protocol, every such pairing needs a custom integration — bespoke endpoints, bespoke authentication, bespoke message formats — and the integration burden grows with every new pair of agents. Worse, each ad-hoc bridge tends to expose internal details, such as prompts, tools, and state, that the remote side should never need to see.
A2A addresses this the way HTTP addressed document exchange: by standardizing the conversation between parties that share nothing else. Google introduced the protocol in April 2025 and donated it to the Linux Foundation in June 2025, placing it under vendor-neutral governance — a signal that agent interoperability is treated as shared infrastructure rather than a proprietary surface.
How it works
A2A defines a small set of primitives layered on ordinary web infrastructure — JSON-RPC 2.0 over HTTPS, with Server-Sent Events for streaming updates:
- Discovery. A remote agent publishes an Agent Card, a JSON document describing its identity, skills, service endpoint, and authentication requirements. Client agents read the card to decide whether the remote agent can help with a given task.
- Task delegation. The client authenticates and submits a task, the protocol’s unit of work. Each task moves through a defined lifecycle: submitted, working, input required, completed, or failed.
- Collaboration. While a task runs, the two agents exchange messages — context, clarifying questions, intermediate updates — and long-running tasks stream status changes instead of blocking the caller.
- Artifacts. The remote agent returns results as artifacts: text, files, or structured data the client can consume directly.
Critically, the remote agent stays opaque. A2A deliberately exposes capabilities and results, not internals: the caller never sees the other agent’s model, prompts, tools, or memory.
A2A vs. MCP
The Model Context Protocol (MCP) and A2A solve adjacent but different problems. MCP standardizes the vertical connection between one agent and its resources — the tools and data sources it invokes with structured inputs and expects deterministic-shaped answers from. A2A standardizes the horizontal connection between agents: autonomous peers that hold their own state, reason about a task, and may ask questions or take time before answering. A useful shorthand is that an agent uses MCP to reach its tools and A2A to reach other agents. The protocols are complementary, and an A2A remote agent will often use MCP internally to do its own work.
In practice
Inside a single runtime, agents coordinate through native mechanisms — routing, shared state, and handoffs — and a protocol like A2A becomes relevant at the boundary, where a run must delegate to an agent it does not own. An execution layer that records every step can treat a remote A2A call like any other external invocation: checkpointed, retried on failure, and visible in the trace alongside the local steps of a multi-agent system. For how agents call external capabilities in general, see how agents use tools.