Agent2Agent — the open protocol that lets a Salesforce agent hand a task to a Google agent which queries a ServiceNow agent. How Agent Cards work, why OAuth 2.0 lives at the edge, what 150+ partners means in practice, and what shape inter-agent trust takes when no single vendor owns the network.
Imagine the international postal system. Every country has its own mail service, its own stamps, its own forms, its own internal couriers; nobody has reorganized any of that. But every country also agrees on a thin shared layer — addressing format, customs declaration, weight class, liability rules — that lets a parcel mailed in Vienna get to Osaka without the Austrian postal worker needing to speak Japanese. A2A is that thin shared layer for AI agents. Each agent keeps its own brain, its own memory, its own tools, its own model — and the protocol just standardizes the envelope, the address, and the customs form.
Technically, A2A (Agent2Agent) is an open communication protocol introduced by Google in April 2025 with 50+ launch partners, donated to the Linux Foundation in June 2025, and now governed by the Agent2Agent Project under the Linux Foundation umbrella. By April 2026, the Linux Foundation reported 150+ organizations supporting the standard, with active production deployments at AWS, Microsoft, Google, Salesforce, SAP, ServiceNow, IBM, and Cisco. The 1.0 specification shipped in late 2025; the current public spec line is in the 1.x series, and the GitHub project (a2aproject/A2A) crossed 22,000 stars by April 2026, with five official SDKs (Python, JavaScript, Java, Go, .NET) maintained under the same org.
The reason A2A exists is captured in one sentence from the spec: agents communicate as agents, not as tools. MCP, the protocol from Day 03, is for an agent to call a tool (a database, a file system, a web service). A2A is for an agent to call another autonomous agent — which has its own goals, its own state, its own context window, and may take ten minutes to respond, may request additional input mid-task, may stream partial results, may delegate to a third agent of its own. That asymmetry is the whole design.
A2A has only three top-level concepts. Memorize them and you can read the spec in an afternoon.
The Agent Card is a JSON file served at /.well-known/agent.json on the agent's domain — a deliberate echo of how OpenID Connect, OAuth, and ACME use /.well-known/ for discovery. It declares the agent's name, description, version, public endpoint URL, the modalities it supports (text, files, structured data, streaming), the skills it offers, and the authentication scheme its endpoint requires. The card is the only document a remote agent needs to start talking to it. Everything else is negotiated at runtime.
A Task is a stateful job with a lifecycle. The client agent posts an initial Message; the server agent moves the Task through a defined state machine. submitted means received but not started; working means actively running; input-required is the magic state — the server agent has paused and is asking the client for additional information (a clarification, a confirmation, a missing parameter), and the Task will not progress until the client sends a follow-up Message. completed, failed, and canceled are terminal. This state machine is what makes A2A different from a function call: functions return; tasks negotiate.
Messages are the turns inside a Task — each one carries one or more Parts, where a Part can be text, a file (with MIME type), or structured data (JSON). The dialect is multimodal by design: a part is whatever the modality declares it is, and the receiving agent decides how to render it. Final outputs are emitted as Artifacts, which are first-class outputs distinct from Messages so a client can collect deliverables (a generated PDF, a draft email, a code patch) without rummaging through chat history.
A2A's transport choices are deliberately conservative. HTTP(S) for transport. JSON-RPC 2.0 for request shape (so it slots into existing API gateways). Server-Sent Events (SSE) for streaming, with optional webhook push notifications for long-running tasks where the client cannot keep an HTTP connection open. Nothing here is exotic; the point is that you can put A2A behind an API gateway, log it like a REST API, and let your security team treat it like any other HTTP service.
Key methods in the JSON-RPC surface: tasks/send (submit), tasks/get (poll), tasks/cancel, tasks/sendSubscribe (submit + open SSE stream), tasks/pushNotification/set (register a webhook for completion). The whole interface is roughly fifteen methods. That minimalism is intentional: the spec authors wanted the protocol to be implementable by a developer in a weekend, not a quarter.
The two streaming modes matter for product. SSE works for interactive UIs where the user is watching results land in a chat. Push notifications work for batch and overnight workflows where a delegating agent fires off twenty tasks, closes the connection, and gets webhooks back over the next four hours as each completes. Both modes are first-class — neither is a retrofit.
This is the subtle part. A2A does not specify how to authenticate; it specifies where to authenticate. Auth lives at the HTTP edge, declared in the Agent Card's authentication field, and the protocol stays out of the way. The most common pattern in production deployments is OAuth 2.0 with a bearer token or, for delegation across organizations, RFC 8693 OAuth 2.0 Token Exchange — the same standard used for SAML-to-OAuth bridging in enterprise SSO.
In practice, three trust layers stack on top of each other:
TLS verifies the server's domain. OAuth 2.0 verifies the calling agent (or the user on whose behalf the calling agent is acting; on-behalf-of flows are explicitly supported). Signed Agent Cards — added in the 1.x line and now considered best practice for any production deployment — let the calling agent verify that the card it fetched at /.well-known/agent.json was actually issued by the domain owner and has not been tampered with. The signing key is published via standard JWKS, so verification is a one-line library call.
The end-to-end story: my agent needs to delegate a task to your agent. My agent fetches your Agent Card, validates its signature, sees that you require an OAuth 2.0 bearer token with a specific scope, exchanges its current token for one scoped to your audience via RFC 8693, and posts the task. Your agent verifies the bearer token, checks scope, executes the task, and streams artifacts back. No new identity system, no agent-specific PKI, no hand-rolled cryptography. Boring on purpose.
Put the pieces together. You ask the Salesforce Agentforce agent to plan a renewal campaign for the Acme account. Agentforce knows the account is also using ServiceNow for IT and SAP for finance. Here is what happens:
Agentforce fetches the ServiceNow and SAP Agent Cards, validates signatures, exchanges its user-bound token for two audience-scoped tokens via OAuth 2.0 token exchange, fires tasks/sendSubscribe at both, and streams artifacts back as each agent finishes its slice. The user sees a single coherent plan; under the hood, three separate organizations' agents collaborated, each with its own model, its own data, its own audit log. No vendor had to expose internals. That is the entire pitch — and it works precisely because the protocol surface is so deliberately small.
The A2A literature is mostly preprints — the protocol is too young for many archival venues. The papers below are the most cited or most operationally useful through April 2026. All verified on arXiv.
Stars approximate, all verified on April 25, 2026.
specification/a2a.json for the JSON Schema and docs/topics/agent-discovery.md for the well-known endpoint convention. The whole thing is ~3,000 lines including examples.tasks/sendSubscribe + SSE. The LangGraph <-> CrewAI sample shows how two different harnesses share zero internals yet finish a workflow.a2a/server/agent_executor.py shows the canonical Task state machine in ~200 lines. Worth reading even if you write the rest of your stack in another language.The protocol passed its one-year mark in April 2026, and the conversation has shifted from “is this real” to “how do we govern it.” Four positions worth tracking:
Google launched A2A in April 2025 with 50+ named partners. By April 2026, the Linux Foundation reported 150+ organizations supporting the standard, with production deployments at most of the top tier. The headline names:
Cloud and platform tier (production):
Original 50+ launch tier (2025) included:
Native A2A support inside agent harnesses (April 2026):
By April 2026, every major frontier-model platform has taken a public position on A2A. The positions are not the same.
| Platform | A2A posture | Recent moves (last 30 days) |
|---|---|---|
| Claude | Anthropic owns MCP and treats A2A as a complement — agent-to-agent calls layered on top of MCP-exposed tools. Claude Agent SDK can act as both an A2A client and server through community adapters; first-party A2A endpoints in Claude products are not yet shipped as of April 2026. | Continued focus on Skills + MCP as the primary extension model; A2A treated as “use it when you have to talk to non-Claude agents.” |
| A2A is a Google-originated protocol now governed by the Linux Foundation. Vertex AI Agent Builder and the Agent Development Kit (ADK) speak A2A natively as both client and server; Agentspace exposes Google Workspace agents over A2A by default. | Google Cloud Next 2026 (April) doubled down on the A2A stack — Workspace Studio agents, Vertex AI Agent Engine, and the Gemini Enterprise tier all default to signed Agent Cards. | |
| OpenAI — GPT-5.4 / Codex | OpenAI's stance has been MCP-first for tools, with A2A interop via community SDKs rather than first-party. The OpenAI Agents SDK can wrap any A2A endpoint, but OpenAI's own production agents (Codex, ChatGPT agents) do not yet expose A2A endpoints by default. | Codex CLI 2026.04 added an experimental flag for A2A client behavior; no first-party A2A server yet. Posture is wait-and-see. |
| OpenClaw 2.1 | Treats A2A as the right answer for cross-organization delegation but layers it on top of its hub-and-spoke architecture. Sub-agents inside OpenClaw remain via internal session spawn; cross-instance and cross-vendor delegation goes over A2A with signed cards required. | OpenClaw 2.1 (April 7) shipped first-class A2A client support in the Agent Runtime; the Gateway can now publish a per-user Agent Card so other A2A agents can address an OpenClaw user as a callable agent. |
Notice the shape: the two consumer-developer platforms (Claude, GPT-5.4) treat A2A as opt-in interop, while the two enterprise-leaning platforms (Google, OpenClaw) treat it as default infrastructure. The split is not about technology; it is about where the buyer expects agent-to-agent calls to happen. Enterprise buyers want their Salesforce agent to call their ServiceNow agent without a procurement review for every integration. Consumer-developer buyers mostly want their Claude Code to call a single tool.
Memorize this state machine. It is the entire contract between two A2A agents.
tasks/send; the server has accepted but not started. Server returns a Task ID and the initial status. Idempotency keys live here — re-posting the same Task ID is a no-op.tasks/cancel.tasks/get calls return the full transcript and artifact list.The two states most product teams underweight are input-required and canceled. The first is what makes A2A feel like a dialogue rather than an RPC; the second is what makes long-running tasks safe to retry. Build them in from day one.
/.well-known/agent.json declaring an agent's identity, endpoint URL, capabilities, supported skills, modalities, and authentication scheme. The discovery primitive of A2A.
tasks.execute scope.”tasks/send.
tasks/send + push-notification webhook instead.tasks/pushNotification/set, and the server posts to that URL on terminal state transitions. Lets long-running tasks survive client disconnects.
/.well-known/<name>. A2A reuses this for the Agent Card at /.well-known/agent.json, mirroring OpenID Connect, ACME, and OAuth.
input-required state assumes the calling agent can interrogate its user mid-task. In agent-to-agent chains three or four hops deep, what's the trust model for that question propagating back? Does the protocol implicitly require every intermediate agent to surface the question, or can it short-circuit answers based on policy?”