A2A Protocol: Agent-to-Agent Communication and Interoperability

Most multi-agent demos wire agents together with direct HTTP calls and custom JSON payloads. This works for a 2-agent prototype. It collapses at scale because every new agent integration requires bespoke serialization, discovery logic, error handling, and auth plumbing. Adding a third agent doubles the integration surface; adding a tenth makes it unmanageable.

The core problem is four-fold. First, discovery: how does agent A know agent B exists and what it can do? Without a standard, you hard-code endpoint URLs and capability lists. Second, lifecycle: when agent A delegates a task to agent B, who tracks whether it is running, completed, or failed? Custom solutions reinvent this state machine per integration. Third, communication format: text, files, and structured data all need to flow between agents — ad-hoc JSON schemas fragment immediately across teams and vendors. Fourth, security: cross-organization agent collaboration requires standardized authentication and authorization, not per-pair API key exchanges.

Google's Agent-to-Agent (A2A) protocol — released April 2025, donated to the Linux Foundation, and reaching v1.0.0 in March 2026 — addresses all four. It defines a standard over HTTP + JSON-RPC 2.0 with Agent Cards for discovery, a task state machine for lifecycle, typed message Parts for communication, and OAuth 2.0/bearer token support for enterprise auth. Over 150 organizations (Salesforce, SAP, ServiceNow, Atlassian, Deloitte) back it.

The non-obvious insight most resources miss: A2A treats agents as opaque peers. Unlike MCP, which exposes an agent's internal tools to a caller, A2A deliberately hides internal implementation. The caller sees capabilities and outputs, never the agent's reasoning chain, tool set, or prompt. This opacity is a feature, not a limitation — it enables cross-vendor collaboration without leaking proprietary architecture. Interviewers reward candidates who articulate this distinction cleanly.