# A2A: Agents as Network Peers

**Track:** Interoperability, Safety & Production — AI-Native Full-Stack Development — complete (30)
**Framework / surface:** web dev (Agent2Agent Protocol)
**Level:** Advanced
**Prerequisites:** MCP: Make Your Application Usable by Agents, Multi-Agent Composition Without the Hype

**In one line:** MCP connects an agent to capabilities; A2A gives independently operated agents a protocol for discovering and collaborating with one another.

## Theory, aesthetics & inspiration

Tool calling describes an agent using a capability; it does not describe two independently operated agents finding each other and collaborating on work that outlives a single request. That interoperability layer is what Google introduced the Agent2Agent protocol for in April 2025 — donated to the Linux Foundation that June, and reaching a 1.0 specification in 2026. Its Agent Card is a machine-readable declaration of identity, skills, endpoints, and authentication requirements, enabling discovery; its tasks are stateful units of work with their own lifecycle, making collaboration explicit rather than disguised as a function call. Students should learn A2A conceptually and build only a small demonstration — the layer is young and will keep moving — because the durable lesson is the distinction itself: MCP exposes capabilities to an agent; A2A addresses peers, autonomous services that manage their own task state. Architecture improves when those roles are named. Ask of every remote system: is this a tool I invoke, or a peer I negotiate with?

**Builder question:** Is the remote system best modeled as a tool you invoke or as an autonomous peer with its own identity, skills, and task lifecycle?