The A2A Protocol v0.3/v1.0 Implementation Guide

#Foreword

The Agent-to-Agent (A2A) Protocol is no longer a Google specification. As of the Linux Foundation press release on April 9, 2026^[1][2], A2A is governed by an eight-seat Technical Steering Committee with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow^[3][4][5]. Version 1.0 shipped on March 12, 2026^[3][6], and the project crossed 22,000 GitHub stars and 150 supporting organizations at its one-year mark^[1][7]. Every major hyperscaler now ships native A2A integration — Vertex AI Agent Engine, Azure AI Foundry with Copilot Studio, and Amazon Bedrock AgentCore Runtime^[1][8][9].

This paper synthesizes 40 primary sources into one canonical reference. The spec layer comes from a2a-protocol.org pages covering v0.2.6, v0.3.0, and latest^{[10][11][12][13]} alongside eight a2aproject GitHub repositories^[1]. The institutional layer comes from the June 2025 Linux Foundation launch press release^[14], the April 2026 one-year milestone^[1], and the GOVERNANCE.md plus Extension Governance documents^[4][15].

Hyperscaler integrations are documented in the official Google Cloud blog posts on v0.3 and v1.0^{[16][17][18][19][20][21][22][23]}.

The identity layer comes from the canonical issue threads (#1497, #1672, #1742, discussion #1752)^{[24][25][26][27]} and from pull requests #1322 (signing examples) and #1696 (identity verification guidance)^[28][29]. SDK detail draws from the Java SDK source^[30] and Python SDK API documentation^[31].

The cryptographic foundation is IETF RFC 7515 (JWS)^[32], and 17 tier-1 secondary publications (InfoWorld coverage^[33][34], VentureBeat^[35]) provide the analyst layer.

No other public source has assembled the spec details, identity-layer proposals, SDK release timelines, hyperscaler integration patterns, and honest production gaps in one place. Read this when deciding whether to ship A2A in 2026, when comparing it to MCP, and when scoping an implementation.

#Executive Summary

A2A v1.0 is the production-stable horizontal coordination layer of the agent stack^[3][36]. MCP is the vertical tool-access layer^[35]. The two-protocol model — vertical (MCP, agent ↔ tool) plus horizontal (A2A, agent ↔ agent) — is now the reference architecture for enterprise multi-agent deployments, and is implemented natively by Google's Agent Development Kit (ADK)^[16][20], Salesforce's Agentforce 3^[37], ServiceNow's AI Agent Fabric in the Zurich release^[38], and the Linux Foundation's AAIF governance umbrella^[35].

The spec defines six core operations — Send Message, Stream Message, Get Task, List Tasks, Cancel Task, Get Agent Card^[12] — exposed over three transport bindings: JSONRPC (default), gRPC, and HTTP+JSON^[10][13]. Agent Cards are JSON metadata served at the well-known URL /.well-known/agent-card.json^[31] containing required fields (name, description, url, version, capabilities, defaultInputModes, defaultOutputModes, skills)^[10] and an optional signatures array of AgentCardSignature records that follow the RFC 7515 JSON Web Signature format^[12][32]. v1.0 elevated a2a.proto from a gRPC-specific schema to the universal normative source of truth, leverages RFC 8785 JSON Canonicalization for signing, removes deprecated implicit/password OAuth flows, and adds the Device Code flow (RFC 8628) and PKCE-required Authorization Code flow^[36].

Security schemes are composable via security requirement objects expressed as OR-of-ANDs — for example, [{"oauth": ["read"]}, {"api-key": [], "mtls": []}] means "OAuth read scope OR (API Key AND mTLS)"^[10]. The supported schemes are OAuth 2.0, OpenID Connect, mTLS, API Key, and HTTP Auth^[10][28], with mTLS support added explicitly to security scheme declarations in v1.0^[36].

The identity story is partially solved and partially still in proposal form. Signed Agent Cards launched in v0.3 (July 2025) and shipped as a production feature in v1.0^[1][16], but the signature is over the Card itself — not over individual requests. The per-request signing gap is addressed by the x-agent-trust extension proposal (Issue #1742, April 2026)^[24], the verifiedIdentity field proposal (Issue #1672)^[25], and Discussion #1752^[26]. As of this writing the TSC has not adopted a cross-check composition contract that mandates verifiers cross-check per-request signatures against Agent Card JWKS, though the proposals reference RFC 9421 HTTP Signatures and propose Ed25519 signing of canonicalized request bodies with kid, nonce, and timestamp^[24].

Five production-ready SDKs ship as of April 2026: Python (pip install a2a-sdk), JavaScript (npm install @a2a-js/sdk), Java (Maven), Go (go get github.com/a2aproject/a2a-go), and .NET (NuGet A2A)^[1]. The reference implementation github.com/a2aproject/A2A carries 22,000+ stars and 140 contributors^[1], with v1.0.0 released 2026-03-12^[3][39]. A2A is not yet seamlessly plug-and-play across every framework — LangGraph and AutoGen lack native A2A as of April 2026, while CrewAI 1.10.1+ ships native support — but the major hyperscalers and enterprise platforms have all converged.

#Part I: The Specification — What v0.3 and v1.0 Actually Define

A2A is, at the wire level, a JSON-RPC 2.0 protocol over HTTP with optional gRPC and HTTP+JSON transport bindings^[10]. The single authoritative normative definition lives in spec/a2a.proto^[12] — a Protocol Buffers schema that the JSON Schema (compliant with JSON Schema 2020-12) is auto-generated from^[13]. v1.0 was the release that elevated this proto file from "gRPC-specific" to "universal source of truth"^[36], which matters because previously the JSON-RPC binding had drifted from the gRPC binding in non-trivial ways.

The Agent Card is the protocol's discovery primitive. It is a JSON document served by the agent server, by default at /.well-known/agent-card.json^[31] (the Python SDK's create_agent_card_routes() helper exposes this convention; the v0.3 path was /.well-known/agent.json and is supported via the enable_v0_3_compat: bool = False parameter for backward compatibility^[31]). The required fields are name, description, url, version, capabilities, defaultInputModes, defaultOutputModes, and skills^[10]. The protocolVersion field has a default of "0.3.0" in v0.3 and "1.0" in v1.0; v0.2.6 used "0.2.5"^[10][11]. The capabilities object is itself a structured record — a published example shows streaming: true, pushNotifications: true, stateTransitionHistory: false^[11].

Three transport bindings are supported. preferredTransport defaults to "JSONRPC"; legal values include "JSONRPC", "GRPC", and "HTTP+JSON"^[10]. An agent advertising multiple transports populates the additionalInterfaces array — each AgentInterface record contains a protocolBinding (open string, supports the three named values) and a protocolVersion such as "0.3" or "1.0"^[13]. The supported_interfaces field carries proto field ID 3 and is REQUIRED^[13]. Per-AgentInterface protocol versioning is what allows backward compatibility — a single agent can advertise itself as 1.0 over JSONRPC and 0.3 over the legacy gRPC endpoint without ambiguity^[36].

Six core operations make up the protocol surface^[12]:

• Send Message — submit a message to start or continue a task
• Stream Message — submit a message and receive Server-Sent Events updates
• Get Task — fetch task state by task ID
• List Tasks — paginated task listing (cursor-based pagination since v1.0^[36])
• Cancel Task — request task cancellation
• Get Agent Card — fetch the Card programmatically (typically used to fetch authenticated extended Cards)

Tasks have a defined lifecycle: submitted → working → input-required → completed | failed | canceled^[12]. The protocol supports three interaction modes — synchronous request/response for fast operations, Server-Sent Events for streaming output, and async webhook push notifications for long-running work^[35]. v1.0 removed compound IDs (tasks/{id}) in favor of simple UUIDs, which simplifies registry and federation patterns^[36].

The security scheme model deserves careful reading. securitySchemes follows the OpenAPI 3.0 Security Scheme Object^[10], and each Card carries a security requirement expressed as a list of "AND" maps — the list itself is OR'd. The canonical example [{"oauth": ["read"]}, {"api-key": [], "mtls": []}] reads as: an authenticated client must satisfy either (a) the OAuth scheme with the read scope, or (b) both API Key AND mTLS^[10]. Five primary scheme types are defined: OAuth 2.0 (Authorization Code with PKCE, Device Code per RFC 8628, Client Credentials), OpenID Connect (with openIdConnectUrl like https://accounts.google.com/.well-known/openid-configuration)^[11], mTLS, API Key, and HTTP Auth^[10][28]. v1.0 explicitly added mTLS to the security scheme declarations^[36] and removed the deprecated implicit and password OAuth flows^[36].

Multi-tenancy is native to the gRPC transport via the tenant field in proto definitions^[13][36]; the JSONRPC binding has multi-tenancy support but the wire-level conventions are less mature. Cursor-based pagination, also new in v1.0^[36], makes scalable task listing feasible across multi-tenant deployments without expensive offset queries.

Two enforcement primitives are worth highlighting. The server returns ExtensionSupportRequiredError if a required extension is not declared by the client^[12] — this is the wire-level affordance that makes the Extension Governance framework^[15] enforceable: an agent that depends on x-agent-trust can refuse to serve a client that hasn't negotiated the extension. The supportsAuthenticatedExtendedCard boolean^[10] and capabilities.extendedAgentCard: true flag^[40] let agents publish a public Card with a redacted skill list while maintaining a richer authenticated Card, with documented "Card Replacement" guidance: clients SHOULD replace cached public Cards after fetching the authenticated extended Card^[40].

Two pull requests deserve specific reference for implementers reading this paper. PR #1303 (OAuth Updates) modernized the OAuth flows in v1.0^[36]. PR #1401 (Backward Compatibility Strategy) defined how v0.3 servers and v1.0 clients negotiate via the per-AgentInterface protocolVersion mechanism^[36]. Both are part of the v1.0 specification and are the primary diffs an existing v0.3 implementation needs to read before upgrading.

The spec is, deliberately, a transport-and-discovery layer and not a payload schema. A2A standardizes the envelope — message format, task lifecycle, transport binding, security scheme — but lets the agents themselves negotiate payload semantics. This is both a strength (no payload-level coupling between vendors) and the source of the "schema standardization gap" we cover in Part VII.

#Quotable Findings — Part I: The Specification

1. Per the A2A v1.0 announcement^[3], v1.0 is "the first stable, production-ready version of the open standard for communication between AI agents" and is "guided by a technical steering committee with representatives from eight major technology companies" — AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow.
2. Per the A2A latest specification^[12], the protocol defines six core operations — Send Message, Stream Message, Get Task, List Tasks, Cancel Task, Get Agent Card — with spec/a2a.proto as the single authoritative normative definition.
3. Per the A2A v0.3.0 specification^[10], the canonical security requirement object example [{"oauth": ["read"]}, {"api-key": [], "mtls": []}] reads as OR-of-ANDs — either the OAuth read scope, or both API Key and mTLS.
4. Per the "What's New in v1.0" page^[36], v1.0 elevates a2a.proto from gRPC-specific to universal normative source of truth, leverages RFC 8785 (JSON Canonicalization) and RFC 7515 (JWS), removes deprecated implicit and password OAuth flows, and adds the Device Code flow (RFC 8628) and PKCE-required Authorization Code flow.
5. Per the A2A Protocol latest definitions^[13], the AgentCard message in proto carries field IDs 1–14 with supported_interfaces = 3 REQUIRED and signatures = 13 for AgentCardSignature records, and the JSON Schema is JSON Schema 2020-12 compliant and auto-generated from protocol buffer definitions.
6. Per the v0.2.6 specification^[11], an A2A Server MUST make an Agent Card available, and the documented openIdConnectUrl example is https://accounts.google.com/.well-known/openid-configuration with example OAuth scopes ["openid", "profile", "email"].

#Part II: The Identity Layer — JWS Signatures, verifiedIdentity, and the x-agent-trust Gap

The single most consequential primitive A2A added between v0.2.6 and v1.0 is the signed Agent Card. Without it, an agent claiming to be the Salesforce Agentforce Marketing Agent could be impersonated by anyone hosting an Agent Card with the same name. With it, the consumer can cryptographically verify that the Card was issued by a specific issuer and has not been tampered with^[30] — which is the foundation of cross-organizational agent collaboration in 2026.

The mechanism is AgentCardSignature, defined in section 4.4.7 of the specification^[40] and carried in the signatures array (proto field ID 13^[13]) of the Agent Card. The signature follows the JSON format of an RFC 7515 JSON Web Signature^[12][32] with three fields: protected (REQUIRED, base64url-encoded JSON containing the protected header), signature (REQUIRED, base64url-encoded), and header (OPTIONAL, an unprotected JWS header object)^[12]. Per RFC 7515, at least one of protected and header MUST be present per signature, and protected MUST contain BASE64URL(UTF8(JWS Protected Header))^[32]. Standard JWS header parameters apply: alg identifies the signing algorithm, kid identifies the key, jku/jwk carry key references, and x5u/x5c/x5t/x5t#S256 cover X.509 chains^[32].

The signing process documented in PR #1322^[28] is five steps: Agent Card Canonicalization (using RFC 8785 JSON Canonicalization, leveraged formally in v1.0^[36]), JWS construction with the protected header, base64url encoding of the canonicalized payload, signature generation with the private key, and assembly of the signature record. Verification is a six-step workflow: fetch the Card, identify the signature record, fetch the public key (typically via JWKS endpoint identified by jku or kid), recanonicalize the Card minus its signatures, verify the signature against the canonicalized payload, and then check trust-policy constraints (issuer allowlist, expiry, revocation)^[28]. Multi-signature support is documented in the same PR — an Agent Card can carry signatures from multiple issuers, allowing for federation patterns where a vendor signs the Card and a downstream tenant counter-signs it.

Three security schemes are documented as recommended in PR #1322^[28] with explicit deployment-pattern guidance: OpenID Connect is recommended for enterprise SSO scenarios; API Keys are recommended for machine-to-machine integrations; and OAuth 2.0 Authorization Code Flow is recommended for user-delegated scenarios. The PR is the canonical reading for implementers — it shows the exact JWS structure, the canonicalization rule (the optional keyword distinguishes explicitly-set vs omitted fields^[40]), and the JWKS publishing pattern.

The Java SDK exposes this directly. The AgentCard Java record carries an optional signatures parameter^[30], and the docstring is the canonical engineering statement: "Signatures provide cryptographic proof that the agent card was issued by a trusted authority and has not been tampered with"^[30]. The Python SDK's create_agent_card_routes() defaults the Card to /.well-known/agent-card.json and supports the v0.3 path via enable_v0_3_compat: bool = False^[31] for backward compatibility — production deployments serve both during a migration window.

This is the part of the identity story that is solved. The part that is not yet solved — and which the next 12 months of A2A engineering work will be concentrated on — is per-request signing. The Card-level signature proves that the agent's published metadata is authentic. It does not prove that any individual request to the agent came from a particular signed caller. For most enterprise threat models (a malicious downstream client impersonating a verified agent in a delegation chain), Card-level signing is necessary but not sufficient.

Three issue threads in the a2aproject GitHub track this gap. Issue #1742 (April 12, 2026, author razashariff^[24]) proposes the x-agent-trust extension, decomposed into two parts: an Agent Card extension carrying the slowly-changing static identity (signing algorithm and JWKS endpoint) and a per-request Agent-Signature header carrying an ECDSA signature over a canonical string with a SHA-256 hash of the request body. The proposed composition contract states that an A2A-conformant verifier MUST cross-check the per-request signature against key material declared in the Agent Card. The proposal references RFC 9421 HTTP Signatures and recommends Ed25519 with kid, nonce, and timestamp parameters in the protected header. A reference implementation pattern is the APS gateway endpoint at /api/v1/public/trust/:agentId for the static profile.

Issue #1672 (March 22, 2026, author haroldmalikfrimpong-ops^[25]) takes a different cut at the same problem. It proposes an optional verifiedIdentity field with agentId, certificate, issuer, and verificationEndpoint — for example, getagentid.dev as issuer and /api/v1/agents/verify as the verification endpoint. The proposal discusses pluggable identity providers (AgentID, APS, AIM), X3DH key agreement plus Double Ratchet for forward secrecy, and Ed25519 (identity) plus X25519 (encryption) on the Agent Card. Discussion #1752^[26] proposes a richer trust extension structure with two sub-objects: identity (method, fingerprint, verifiedAt) and behavior (evidenceUrl, constraintHash, complianceRate, actionCount, lastVerified). The discussion documents three byte-identical conformance vectors in CI tests using JCS (RFC 8785) plus SHA-256 plus Ed25519, validated to produce matching signatures across Nobulex (TypeScript) and AgentLedger (Python) implementations. Issue #1497 (February 18, 2026, author thebenignhacker^[27]) proposes a three-level verification framework — self-asserted, domain-verified, organization-verified — and maps these to APS passport grades 0–3 (bare keypair → runtime + verified human principal). The proposal also covers revocation endpoints (sub-3-second propagation), delegation-chain security, and message signing.

PR #1696 (March 28, 2026, author FransDevelopment^[29]) is the closest the project has come to merging identity verification guidance into the canonical docs. It adds a "Verifying Agent Identity" section to agent-discovery.md, formally references both JWS (RFC 7515) and JSON canonicalization (RFC 8785), defines a four-tier attestation model (Grade 0 bare keypair, Grade 1 issuer countersigned, Grade 2 runtime-bound, Grade 3 runtime + verified human principal), and proposes an aps.txt convention analogous to robots.txt but cryptographically signed.

As of this writing, the TSC has not adopted any of these as canonical^[24]. The pattern an implementer should expect to ship in 2026 is: sign the Card today using the documented PR #1322 mechanism, publish keys via JWKS at a stable endpoint, and structure your codebase so that adding per-request signing later is a transport-layer middleware change rather than a protocol-layer rewrite. Most production deployments today rely on the Card signature plus standard transport-layer authentication (mTLS, OAuth bearer tokens) — which is honest because that is what the v1.0 spec actually defines.

#Quotable Findings — Part II: The Identity Layer

1. Per A2A specification.md commit 629190ae^[40], section 4.4.7 defines AgentCardSignature and section 4.6 documents Extensions, with the rule that Extension URI versioning requires a new URI for breaking changes and that clients SHOULD replace cached public Agent Cards after fetching the authenticated extended Card.
2. Per Issue #1742 (April 12, 2026)^[24], the proposed x-agent-trust extension decomposes Agent Card identity (static, slowly-changing JWKS endpoint) from per-request x-agent-request-sig (body hash + nonce + timestamp + kid) and proposes a composition contract requiring A2A verifiers to cross-check both — referencing RFC 9421 HTTP Signatures.
3. Per PR #1322^[28], the documented signing workflow is 5 steps (canonicalization → JWS construction → base64url encoding → signature → assembly) and the verification workflow is 6 steps; three documented security schemes are OpenID Connect (enterprise SSO), API Keys (M2M), and OAuth 2.0 Authorization Code Flow (user-delegated).
4. Per Discussion #1752^[26], three byte-identical conformance vectors in CI tests using JCS (RFC 8785) plus SHA-256 plus Ed25519 produced matching signatures across Nobulex (TypeScript) and AgentLedger (Python) implementations — the reference path to cross-language signature interoperability.
5. Per Issue #1497^[27], a three-level verification framework (self-asserted, domain-verified, organization-verified) maps to APS passport grades 0–3, with revocation endpoints supporting sub-3-second propagation.
6. Per PR #1696^[29], the four-tier attestation model is Grade 0 (bare keypair), Grade 1 (issuer countersigned), Grade 2 (runtime-bound), Grade 3 (runtime + verified human principal) — this is the closest the docs have come to a canonical attestation taxonomy.
7. Per the AgentCard.java source^[30], the Java SDK's docstring is the canonical engineering statement: "Signatures provide cryptographic proof that the agent card was issued by a trusted authority and has not been tampered with."

#Part III: Reference Implementations — The Five Production SDKs

The Linux Foundation's April 9, 2026 announcement called out five production-ready SDKs: Python, JavaScript, Java, Go, and .NET^[1]. Each lives under the a2aproject GitHub organization (1,321 followers, 10 public repos^[41]) and ships under the Apache 2.0 license^[21]. The reference implementation github.com/a2aproject/A2A carried 23,557 stars, 2,379 forks, 140 contributors, 249 open issues, and v1.0.0 (released 2026-03-12) at the time of dossier capture^[21]. The top-10 contributors include holtskinner, kthota-g, amye, madankumarpichamuthu, pstephengoogle, zeroasterisk, darrelmiller (Microsoft), and didier-durand^[21] — a meaningful cross-vendor distribution that confirms the Linux Foundation governance is technical, not nominal.

The five SDK repositories at the time of dossier capture^[41]:

• A2A (the spec + cross-cutting documentation): 22,999 stars, primary language Shell, last updated 2026-04-02
• a2a-python: 1,801 stars, primary Python, last updated 2026-04-03
• a2a-samples: 1,466 stars, primary Jupyter Notebook, last updated 2026-04-01
• a2a-js: 509 stars, primary TypeScript, last updated 2026-04-02 (separate repo card lists 521 stars, 134 forks, 40 contributors, 19 releases, latest v0.3.13 on 2026-03-16^[42])
• a2a-inspector: 385 stars, validation tools for A2A agents
• a2a-java: 380 stars, primary Java

Installation patterns are documented on the project README^[21]: pip install a2a-sdk for Python, go get github.com/a2aproject/a2a-go for Go, npm install @a2a-js/sdk for JavaScript, Maven coordinates for Java, and dotnet add package A2A for .NET. The A2A landing page lists DeepLearning.AI's "A2A: The Agent2Agent Protocol" short course, the project Tutorials and Samples, and the SDK Reference as the canonical learning resources^[1].

Microsoft's adoption deserves a section of its own because the .NET trajectory is the most documented A2A migration in public. The initial .NET SDK preview was announced July 31, 2025 by Sergey Menshykh on the Microsoft Foundry Blog^[42]. That release shipped two NuGet packages: A2A (core) and A2A.AspNetCore (ASP.NET Core integration), exposing a single-line server pattern: app.MapA2A(taskManager, "/agent")^[42]. The three core methods were Attach(), ProcessMessageAsync(), and GetAgentCardAsync(). InfoWorld's contemporaneous walkthrough^[43] covered the same SDK from the practitioner side — agent capability discovery, direct messaging, task-based interactions, streaming — and made the explicit guidance: Agent Cards "shouldn't contain secrets," and OAuth is recommended for access control.

The April 28, 2026 follow-up post by Menshykh^[41] — "A2A v1 Is Here: Cross-Platform Agent Communication in Microsoft Agent Framework for .NET" — documented the v0.3-to-v1 migration in concrete API terms^[41]. The pattern in v0.3 was a single MapA2A(...) call; in v1 the registration is split: AddA2AServer() registers the server, and either MapA2AHttpJson or MapA2AJsonRpc performs the path mapping. A MapWellKnownAgentCard(card) call exposes the Agent Card at the well-known endpoint, and A2AClientOptions.PreferredBindings lets clients select transport. The default binding preference flipped: HTTP+JSON is preferred in v1, JSON-RPC is the fallback, the inverse of the v0.3 default. The post also notes the calibration that matters for upgrade decisions: "While the A2A protocol itself has reached v1 (stable), the A2A SDK and the Agent Framework packages that implement it are still in preview"^[41] — the spec is stable, the .NET implementation is preview-stable.

The Microsoft Semantic Kernel integration arrived in two waves. The first sample (April 17, 2025^[44]) by Evan Mattson was a SemanticKernelTravelManager pattern with CurrencyExchangeAgent and ActivityPlannerAgent peers — produced before a packaged A2A library existed, requiring Python 3.10+, the uv package manager, and OpenAI credentials, running on port 10020. The July 21, 2025 guest blog by Kinfey Lo^[45] formalized the architectural pattern: Host Agent + A2A + Semantic Kernel + Remote Agents, with the explicit MCP-A2A separation — MCP for tools, A2A for agents — and forward-looking integration plans for Azure AI Foundry native A2A and Copilot Studio compatibility, both of which shipped by April 2026^[1].

Google's ADK is the most actively-released SDK in the ecosystem. ADK Python v1.30.0 shipped April 13, 2026 at 23:16 UTC^[46] with native Gemma 4 support, A2A artifact streaming via interceptor (commit e63d991, allowing agents to pass live artifacts — files, data objects, structured outputs — in A2A events), and Auth Provider integration for agent registries. The same release patched a credential leakage vulnerability in the Agent Registry. ADK has shipped 30 point releases in 2026 alone^[46]; the framework supports Python, Go, Java, and TypeScript with a shared web development UI. ADK's v1.29.0 (April 9) added auth scheme support for MCP toolsets in the Agent Registry; v1.30.0 generalized this to a uniform Auth Provider pattern. The architectural framing in Google Cloud's "Building Distributed AI Agents" post^[19] gives the canonical ADK A2A code example: A2AFastAPIApplication wraps ADK agents, the Agent Card is served at /.well-known/agent.json with the RPC endpoint at /rpc, and the RemoteA2aAgent class is what one ADK agent uses to call another. LoopAgent and SequentialAgent are the documented orchestration patterns; production auth recommendation is mTLS, OIDC, or API keys.

Finally, the validation tooling. a2a-inspector (385 stars^[41]) is the official validation suite — it ships in the same org and is the reference an implementer should run against any new server. The project also references a Technology Compatibility Kit released by the community^[16], which is the test harness Microsoft, Google, and other contributors use to validate cross-SDK interoperability. For new implementations, the inspector + TCK is the production-readiness checklist.

#Quotable Findings — Part III: Reference Implementations

1. Per the github.com/a2aproject organization page^[41], the project hosts six top repositories with combined ~28,000 GitHub stars: A2A spec (22,999), a2a-python (1,801), a2a-samples (1,466), a2a-js (509), a2a-inspector (385), and a2a-java (380) — five SDKs and the validation toolchain.
2. Per the github.com/a2aproject/A2A repo card^[21], the reference implementation has 140 contributors, 249 open issues, and v1.0.0 released 2026-03-12, with top contributors holtskinner, kthota-g, amye, madankumarpichamuthu, pstephengoogle, zeroasterisk, darrelmiller (Microsoft), and didier-durand — confirming cross-vendor governance.
3. Per Microsoft DevBlogs (Sergey Menshykh, April 28 2026)^[41], the v0.3-to-v1 migration in the .NET SDK splits server registration: v0.3 used app.MapA2A(taskManager, "/agent"); v1 uses separate AddA2AServer() registration plus MapA2AHttpJson or MapA2AJsonRpc path mapping, with HTTP+JSON now the preferred binding (vs JSON-RPC in v0.3).
4. Per the ADK Python v1.30.0 release notes^[46], the release added A2A artifact streaming via interceptor (commit e63d991) — agents can now pass live artifacts (files, data objects, structured outputs) in A2A events, where v1.29.0 supported only text and status updates.
5. Per Microsoft Foundry Blog (Evan Mattson, April 17 2025)^[44], the first Semantic Kernel A2A integration sample predated a packaged A2A library and required custom plumbing — Python 3.10+, uv, OpenAI credentials, port 10020 — illustrating how rapidly the SDK landscape matured between April 2025 and April 2026.
6. Per Google Cloud's "Building Distributed AI Agents" guide^[19], the canonical ADK A2A pattern is A2AFastAPIApplication wrapping an ADK agent with the Card at /.well-known/agent.json and RPC endpoint at /rpc, using RemoteA2aAgent for inter-agent calls and recommending mTLS, OIDC, or API keys for production authentication.

#Part IV: Production Patterns — What 150+ Organizations Are Actually Shipping

The Linux Foundation press release on April 9, 2026 made a specific claim worth reading carefully: "more than 150 organizations supporting the standard, deep integration across Google, Microsoft and AWS platforms, and active production deployments across multiple industries"^[1]. Vertical adoption spans supply chain, financial services, insurance, and IT operations^[1]. This section walks through what that integration actually looks like vendor by vendor — what's GA, what's preview, and what's still custom integration work.

Google Cloud ships the most complete A2A integration because Google wrote the spec. Vertex AI Agent Engine has native A2A support — the Agent Engine documentation lists "Use an Agent2Agent agent" as a supported deployment target^[22], and the September 2025 Vertex AI Agent Builder post quoted the operational scale: "hundreds of thousands of agents have been deployed to Vertex AI Agent Engine"^[18]. Three deployment paths are documented: Vertex AI Agent Engine (managed runtime), Cloud Run (serverless), and GKE (full control)^[23]. The agent-starter-pack CLI tool with one-line CI/CD setup is the recommended entry point for new ADK projects^[16], and the Vertex GenAI Evaluation Service has been extended to evaluate A2A agent systems^[16]. The Gemini Enterprise Agent Platform announced at Google Cloud Next '26 added a guide titled "How A2A and MCP work together," an Agent Registry for discovery, an Agent Gallery in Gemini Enterprise for cross-organization federation, Atomic Agents in the Agent Garden, and Model Garden access to 200+ models including Gemini 3.1 Pro, Lyria 3, and Gemma 4^[20].

Microsoft Azure integrated A2A into Azure AI Foundry and Copilot Studio in early 2026^[1]. The integration covers agent discovery via Agent Cards and task delegation across Copilot Studio agents — for enterprise teams already on Microsoft's agent platform, this makes A2A a first-class integration rather than a custom middleware project. The earlier Power Platform devblog (April 28, 2025) documented Copilot Studio's MCP support via the connector infrastructure with virtual network integration, DLP controls, and multiple authentication methods^[47]; the July 16, 2025 announcement of GA custom-engine agents in Microsoft 365 Copilot^[48] (with the Microsoft 365 Agents Toolkit, Microsoft 365 Agents SDK, and partner agents from SAP Joule, LexisNexis Protégé, Meltwater, and Asana) is the foundation that A2A bolts on top of. The April 7, 2026 update on MCP Apps in Copilot chat^[49] confirmed parallel MCP and OpenAI Apps SDK support, with launch partners Outlook, Power Apps, Adobe Express, Coursera, Figma, and monday.com — and OAuth 2.1, Microsoft Entra SSO, and anonymous authentication options.

Amazon Web Services added A2A support through Amazon Bedrock AgentCore Runtime^[1]. Bedrock supports both MCP and A2A; AWS's implementation choices will influence how the protocols evolve given Bedrock's enterprise customer base. Salesforce CTO commentary on AgentExchange characterized the parallel pattern: A2A becomes the default standard for building agent-based systems in the cloud^[1].

Salesforce moved fastest into the multi-vendor world. Agentforce 3 (announced June 23, 2025) shipped native MCP and A2A support with documented customer outcomes: "reducing Engine's average customer case handle time by 15%, autonomously resolving 70% of 1-800Accountant's administrative chat engagements during critical tax weeks in 2025, and increasing Grupo Globo's subscriber retention by 22%"^[37]. AgentExchange added 30+ MCP partners (AWS, Box, Cisco, Google Cloud, IBM, Notion, PayPal, Stripe, Teradata, WRITER)^[37]. Then came Agent Fabric. Launched September 2025, Agent Fabric is Salesforce's "trusted agent control plane for your rapidly evolving multi-vendor AI landscape"^[50] and as of April 15, 2026 is managing "thousands of agentic instances" across customers including Capita, Alcon, and Diabsolut^[50]. The April 2026 expansion added Agent Scanners covering MCP servers and Amazon Bedrock, Microsoft Foundry, and GoDaddy with secure OAuth authentication; an MCP Bridge to expose existing APIs as MCP servers; LLM Governance on AI Gateway for token management; and Trusted Agent Identity with mobile authorization for high-stakes operations like money movement and legal review^[50]. Agent Broker, Salesforce's deterministic-orchestration product, entered beta in April 2026 with full GA scheduled June 2026^[50]. Andrew Comstock (GM Salesforce MuleSoft, creator of Agent Fabric) framed the architecture clearly: "Effective orchestration must bridge the gap between various vendor ecosystems," with A2A and MCP as the two interoperability standards, "both protocols now administered by open-source The Linux Foundation"^[51].

ServiceNow has the most documented A2A deployment path of any enterprise software vendor. The December 2025 "Zurich" release shipped full A2A v0.3 support through a layer called AI Agent Fabric^[52] — a multi-agent communication backbone connecting ServiceNow-built agents, customer-built agents, and partner-built agents. Authentication uses OAuth 2.0 and federated token authentication. The published HRSD/ITAM onboarding pattern is the cleanest example of A2A+MCP composition in any vendor's docs: when a new employee is hired, an HRSD AI agent kicks off onboarding via A2A, delegating to an ITAM AI agent to provision hardware and software; the ITAM agent uses MCP internally to pull role and department data, then places orders — the entire handoff requires no custom connector^[52]. The April 24, 2026 ServiceNow Community technical guide^[38] walks through exposing a ServiceNow AI Agent as an A2A server: any AI Agent with "Allow third party to access this AI agent" toggled on becomes A2A-compliant; the OAuth scope a2aauthscope is required for token-authenticated requests to /api/sn_aia/a2a/...; the Machine Identity Console (Zurich+) is used for OAuth Client Credentials setup; and the sn-a2a CLI repository at github.com/ServiceNow/sn-a2a^[38] is the reference. Platform requirements: Zurich or later plus the Now Assist AI Agents 6.0.x store app (which includes AI Agent Fabric with A2A support).

Adobe announced general availability of AI agents powered by the Adobe Experience Platform (AEP) Agent Orchestrator in September 2025^[52]. The Agent Orchestrator uses A2A specifically to make Adobe agents interoperable with Google Cloud's ecosystem. Adobe's NVIDIA partnership in March 2026 extended this further — NVIDIA infrastructure and AI libraries power the next generation of Adobe's agentic creative and marketing workflows, with A2A as the communication layer^[52]. The Adobe Marketing Agent shipped in IBM watsonx Orchestrate's Agent Catalog as of April 30, 2026^[53], which is the first cross-vendor catalog placement of A2A-coordinated agents in production.

IBM integrates at two levels. watsonx Orchestrate Agent Catalog hosts 150+ agents and pre-built tools from IBM and partners (Box, MasterCard, Oracle, Salesforce, ServiceNow, Symplistic.ai, 11x), with build-your-own-agent in under five minutes and integration with 80+ leading enterprise applications including Adobe, AWS, Microsoft, Oracle, Salesforce Agentforce, SAP, ServiceNow, and Workday^[54]. The Salesforce-IBM partnership combines Agentforce + watsonx Orchestrate with watsonx.ai integration for Salesforce Model Builder; Salesforce Data Cloud + IBM Data Gate enables IBM Z mainframe and Db2 access for Agentforce agents; joint customers begin in financial services, insurance, manufacturing, and telecommunications^[55]. The April 21, 2026 Adobe industry-solutions announcement quantified the business case: companies lose an average of $29 million annually because they cannot react quickly enough to customer demands; 75% of executives say their companies are too slow; only 34% of customer data collected today is used to inform CX decisions^[56].

The single most-cited A2A production deployment is the Gordon Food Service and Tyson Foods supply chain pilot on Google Cloud^[15]. Gordon Food Service (a food service distributor) and Tyson Foods (a major supplier) deployed agents from each organization that needed to coordinate on product searches and sales tracking. The challenge: both sides had legitimate security reasons to keep their internal systems opaque. Using Google's ADK with A2A, the two companies ran agents that collaborated — sharing relevant outputs, coordinating on search tasks — without exposing proprietary databases, pricing models, or internal logic to each other^[15]. The black-box design made the cross-organizational deployment possible in ways API integration would not have. Gordon Food Service is now planning to bring this to production in Gemini Enterprise and scale it to additional vendor partners^[15]. This is the pattern A2A was designed for, and the next 1,000 cross-organizational agent deployments will look like it.

The framework adoption story is uneven and worth flagging. CrewAI (1.10.1+, 45,900+ GitHub stars) ships native A2A support — diverse agents built on CrewAI can participate in A2A networks, delegate sub-tasks to agents on other frameworks, and receive delegated work without exposing internal tool configurations^[15]. LangGraph does not have native A2A as of April 2026^[15] — despite being arguably the most widely deployed orchestration layer for production agents, particularly in enterprises that need graph-based state machines. LangGraph agents can participate in A2A ecosystems because the protocol is transport-level, not framework-level, but teams using LangGraph must implement the A2A server side themselves: no built-in Agent Card generation, no native task lifecycle management, no maintained SDK integration^[15]. AutoGen is in a similar position. The practical implication for large enterprise deployments is that A2A interoperability for LangGraph-based agents requires either custom middleware or waiting for the ecosystem to deliver a maintained integration. Google Open Source's April 2026 first-birthday post called out ADK, LangGraph, AG2, and CrewAI as having demonstrated interop^[57], but "demonstrated interop" is not the same as "shipped native support."

#Quotable Findings — Part IV: Production Patterns

1. Per the Linux Foundation press release April 9, 2026^[1], A2A's first-year milestones include 150+ supporting organizations (up from 50+ at launch), 22,000+ GitHub stars, native integration in Vertex AI Agent Engine + Azure AI Foundry + Amazon Bedrock AgentCore Runtime, and SDK ecosystem expansion from a single Python implementation to five production-ready languages.
2. Per Google Cloud's "Get started with Vertex AI Agent Builder" post^[18], "hundreds of thousands of agents have been deployed to Vertex AI Agent Engine" with native A2A support when deploying to the Agent Engine runtime — the largest documented deployment count of any A2A-supporting platform.
3. Per the Salesforce Agentforce 3 announcement June 23, 2025^[37], Agentforce 3 launch customers reported quantified outcomes: Engine 15% reduction in average customer case handle time, 1-800Accountant 70% autonomous resolution of administrative chat engagements during 2025 tax weeks, Grupo Globo 22% subscriber retention increase.
4. Per the Salesforce Agent Fabric April 15, 2026 announcement^[50], Agent Fabric (launched September 2025) manages "thousands of agentic instances" with customers Capita, Alcon, and Diabsolut, and the April expansion added Agent Scanners (covering MCP servers, Amazon Bedrock, Microsoft Foundry, GoDaddy), MCP Bridge, LLM Governance on AI Gateway, and Trusted Agent Identity with mobile authorization for high-stakes operations.
5. Per the ServiceNow Community A2A technical guide April 24, 2026^[38], any ServiceNow AI Agent with "Allow third party to access this AI agent" toggled on becomes A2A-compliant; OAuth scope a2aauthscope is required for /api/sn_aia/a2a/... requests; platform requirement is Zurich or later plus Now Assist AI Agents 6.0.x store app.
6. Per the Gordon Food Service / Tyson Foods supply chain pilot documentation^[15], the production-ready deployment uses Google's ADK with A2A to coordinate agents across two organizations on product search and sales tracking without exposing proprietary databases, pricing models, or internal logic — the canonical cross-organizational A2A pattern.
7. Per the IBM-Adobe industry research April 21, 2026^[56], companies lose an average of $29M annually from inability to react quickly to customer demands; 75% of executives say their companies respond too slowly; only 34% of customer data collected today is used for CX decisions — the quantified business case for cross-system agent coordination.
8. Per the AgentMarketCap one-year report April 9 2026^[15], CrewAI 1.10.1+ ships native A2A support with 45,900+ GitHub stars; LangGraph and AutoGen lack native A2A as of April 2026, requiring teams to implement A2A server side themselves.

#Part V: Governance — Linux Foundation, AAIF, and the AP2 Extension

A2A's transition from a Google specification to a Linux Foundation project happened on June 23, 2025 at Open Source Summit North America in Denver^[14]. Mike Smith of Google announced the donation; Jim Zemlin (Executive Director of the Linux Foundation) and Rao Surapaneni (VP/GM of Applications Platform, Google Cloud) provided the launch quotes; the project launched with more than 100 supporting technology companies^[14]. The repository moved formally to github.com/a2aproject/A2A under the Apache 2.0 license^[14].

The governance framework documented in GOVERNANCE.md^[4] is intentional. The Technical Steering Committee has eight seats; in the Startup Phase each org appoints one employee as voting member, transitioning to Steady State 18 months after Project inception. Quorum requires at least 50% of voting members; decisions require majority vote of those in attendance when quorum is met. The TSC may elect a TSC Chair. Meetings are held on the Linux Foundation Zoom platform, and GitHub is the source of truth for significant project decisions^[4]. The Extension and Binding Governance document^[15] adds a parallel framework for Extensions and Custom Protocol Bindings — official artifacts must live under the a2aproject GitHub organization under Apache 2.0; experimental repos require sponsorship from an A2A Maintainer; the same TSC quorum and majority-vote rules apply; repositories transition from experimental-cpb-* to cpb-* after promotion; breaking changes require a new identifier and TSC review; and the Linux Foundation receives a perpetual, worldwide, non-exclusive, royalty-free license^[15].

The TSC composition is what makes the multi-vendor governance real. Founding members documented across the v1.0 announcement^[3] and the AgentMarketCap analysis^[15] are AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow. The April 9, 2026 commits page shows TSC member-management documentation work in flight (docs(GOVERNANCE.md): How to add new TSC members (#1571))^[45] alongside the v1.0.0 release tag (March 12, 2026)^[45] and post-1.0 work like custom protocol bindings documentation^[45] and the Rust SDK addition to the official SDK list (#1729)^[45]. Top contributors reflect this multi-vendor structure: holtskinner, kthota-g, amye, madankumarpichamuthu, pstephengoogle (Google), zeroasterisk, darrelmiller (Microsoft), and didier-durand^[21].

The Agentic AI Foundation (AAIF) is the umbrella under which A2A and MCP now coexist. Founded December 2025 under the Linux Foundation, with Anthropic, Block, and OpenAI as co-founders^[58], the AAIF mandate is to govern MCP and A2A specifications, ensure interoperability between implementations, prevent protocol fragmentation, and certify conformant implementations^[59]. Anthropic donated MCP to the Linux Foundation; OpenAI contributed AGENTS.md; Block contributed the goose agent framework as a reference implementation^[58]. Brad Axen of Block and the Anthropic governance statement that "MCP's governance model will remain unchanged" anchored the cross-vendor commitment^[58]. The IBM ACP merge into A2A in August 2025^[59] removed one of the three competing protocols and consolidated the agent-to-agent layer.

The AP2 (Agent Payments Protocol) extension is the most consequential extension proposal currently in flight. AP2 is a payments-specific extension to A2A maintained at github.com/google-agentic-commerce/ap2^[15]. As of April 2026 it had 60+ supporting organizations in payments and financial sectors^[60], reflecting a pattern where the underlying A2A spec defines the envelope and AP2 adds the payment-specific Agent Card fields, transaction primitives, and risk-control hooks. PayPal's Nitin Sharma quote in Google Cloud's November 2025 Vertex AI Agent Builder post — "uses ADK CLI; Agent Payment Protocol (AP2) on Agent Builder"^[17] — is the most concrete production reference to AP2 in action.

The DeepLearning.AI short course "A2A: The Agent2Agent Protocol" launched in 2026 alongside the milestone announcement^[1]. Combined with the project Tutorials, Samples, and SDK Reference^[1], plus the a2a-inspector validation suite and community-released Technology Compatibility Kit^[16], the educational and conformance infrastructure is now in place. Looking forward, the published roadmap calls out interoperability specification, registry consolidation, expanded testing and tooling, and security and deployment best practices^[1]; the joint MCP/A2A interoperability specification effort is anticipated under AAIF^[58].

#Quotable Findings — Part V: Governance

1. Per the Linux Foundation press release June 23, 2025^[14], A2A was donated by Google at Open Source Summit North America in Denver with more than 100 supporting technology companies at launch — repository at github.com/a2aproject/A2A under Apache 2.0 license.
2. Per A2A GOVERNANCE.md^[4], the TSC has eight seats with majority-vote decisions at 50% quorum, transitioning from Startup Phase (one employee per org) to Steady State 18 months after Project inception, with GitHub as the source of truth for significant project decisions.
3. Per the v1.0 announcement^[3], TSC representation includes AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow — confirming cross-vendor governance is structural, not nominal.
4. Per the Extension and Binding Governance framework^[15], experimental repositories require sponsorship from an A2A Maintainer, transition from experimental-cpb-* to cpb-* after TSC-vote promotion, and breaking changes require a new identifier and TSC review — protecting the spec from silent forks.
5. Per the AAIF/VentureBeat coverage December 2025^[58], the Agentic AI Foundation co-founded by Anthropic, Block, and OpenAI hosts both MCP and A2A under one Linux Foundation umbrella, with Anthropic's commitment that "MCP's governance model will remain unchanged" and Block contributing the goose agent framework as reference implementation.
6. Per the CyberTechnology Insights coverage^[60], the AP2 (Agent Payments Protocol) extension had 60+ supporting organizations in payments and financial sectors at one-year mark — the first vertical extension to reach critical mass.

#Part VI: A2A vs MCP — The Layered Stack and Where They Compose

The mental model that won — and that anyone deploying agents in 2026 should adopt — is that A2A is horizontal and MCP is vertical^[35][61]. MCP standardizes the connection from an agent to its tools, databases, and APIs^[61]. A2A standardizes the connection from one agent to another agent^[61]. They are not competing protocols. They are layers in a stack, and the production-grade reference architecture composes both.

Rao Surapaneni (Google Cloud GM, Business Applications Platform) framed it explicitly when A2A launched: "We see MCP and A2A as complementary capabilities. The way we are looking at Agent2Agent is at a higher layer of abstraction to enable applications and agents to talk to each other. So think of it as a layered stack where MCP operates with the LLM for tools and data"^[35]. Andrew Comstock (GM Salesforce MuleSoft, Agent Fabric creator) said the same thing when announcing Agent Fabric: "Two interoperability standards have emerged to ensure smooth handoffs. One is the Agent2Agent protocol (A2A) ... The second is the Model Context Protocol (MCP) developed by Anthropic. Both protocols are now administered by open-source The Linux Foundation"^[51].

The state of the two ecosystems as of April 2026 is asymmetric in a way worth understanding. MCP is mature: APIScout cites 97 million monthly SDK downloads as of February 2026^[59], and analyst commentary puts public MCP servers at over 5,000 with adoption from "every major AI provider"^[59]. A2A is younger and earlier: 22,000+ stars^[1], five SDKs, 150+ supporting organizations, and an estimated ~200 publicly listed A2A-compatible agents^[15]. The directional comparison is that "A2A is roughly where MCP was in mid-2024"^[62] — meaning A2A is a credible standard with growing adoption but its ecosystem of public, production-grade implementations is still concentrating.

The architectural distinction at the wire level is precise^[61][63][64]:

• MCP is client-server, stateless, JSON-RPC over stdio (local) or HTTP+SSE (remote)^[63]. Its core abstraction is Tools, Resources, Prompts — callable capabilities with schemas^[63]. Discovery is protocol-native: an agent calls tools/list at runtime to learn what is available^[63]. State management is stateless per call^[63]. The client (the agent) holds context; the server (the tool) does not.
• A2A is peer-to-peer between agents, stateful (with full task lifecycle), JSON-RPC 2.0 with optional gRPC and HTTP+JSON, plus Server-Sent Events for streaming^[63][64]. Its core abstraction is Tasks — units of work with status, artifacts, and streaming updates^[63]. Discovery is via Agent Cards served at well-known URLs^[63]. State is stateful — the task lifecycle persists across connections^[64].

Both protocols converged on a similar discovery affordance (well-known URL endpoints with JSON descriptors), and both are now administered by the Linux Foundation under the AAIF umbrella^[59]. A joint interoperability specification effort is anticipated to define how MCP tool invocations can trigger A2A agent delegations and vice versa — the formal bridge between the two layers^[35]. As of this writing no draft has been published.

The composition pattern in production deployments is now standard. The reference architecture, articulated in Microsoft's Semantic Kernel guest blog^[45], the Google Cloud "Building Distributed AI Agents" post^[19], and AgentMarketCap's analysis^[15], has three working parts: an orchestrator agent receives a task from a user; the orchestrator uses A2A to delegate sub-tasks to specialist agents (which may live in different organizations, frameworks, or clouds); each specialist agent uses MCP internally to call the tools, databases, and APIs it needs to complete its work. The classic ServiceNow HRSD-to-ITAM onboarding flow is exactly this pattern: HRSD agent receives the new-hire trigger, A2A-delegates to ITAM, ITAM uses MCP to pull role/department data and place hardware orders^[52]. Salesforce, ServiceNow, and Google ADK all implement BOTH protocols natively in this composition^{[15][52][37][38]}.

The honest answer to "MCP or A2A?" for any production team in 2026 is: both. The layered model is the only architecture that scales across vendor boundaries, and the work of choosing collapses into deciding what specifically each layer needs to do for your workflow.

#Quotable Findings — Part VI: A2A vs MCP

1. Per the Surapaneni VentureBeat interview April 2025^[35], Google framed A2A explicitly as complementary to MCP: "We see MCP and A2A as complementary capabilities... think of it as a layered stack where MCP operates with the LLM for tools and data."
2. Per APIScout^[59] and the AgentMarketCap state-of-A2A report^[15], MCP has 97 million monthly SDK downloads with 5,000+ public servers, while A2A has 22,000+ GitHub stars, 5 production SDKs, 150+ supporting organizations, and ~200 publicly listed A2A-compatible agents — A2A is roughly where MCP was in mid-2024^[62].
3. Per the AgentMarketCap A2A vs MCP comparison^[64], the wire-level distinction is precise: MCP is stateless client-server (JSON-RPC over stdio or HTTP+SSE) with Tools/Resources/Prompts as core abstraction; A2A is stateful peer-to-peer with Tasks as core abstraction and full lifecycle persistence.
4. Per the AAIF coverage on aaif.io^[58] and APIScout^[59], the December 2025 launch of the Agentic AI Foundation by Anthropic, Block, and OpenAI under the Linux Foundation united MCP and A2A under one governance umbrella with the explicit mandate to prevent protocol fragmentation and certify conformant implementations.
5. Per the Comstock/Salesforce framing^[51], the production architecture is "MCP + A2A as standard stack" with both protocols now administered by the Linux Foundation — the canonical multi-vendor framing from a software vendor that ships both.
6. Per Google Cloud's "Building Distributed AI Agents"^[19] and the AgentMarketCap two-protocol analysis^[64], the canonical composition is: orchestrator agent receives task, uses A2A to delegate to specialist agents, each specialist uses MCP internally to call tools — the pattern Salesforce, ServiceNow, and Google ADK all implement.
7. Per Google's "Five guides to building and scaling production-ready AI agents"^[20], the Gemini Enterprise Agent Platform announced at Google Cloud Next '26 ships an explicit guide titled "How A2A and MCP work together" — confirming the layered stack is now the documented hyperscaler architecture.

#Part VII: Honest Limits — What A2A v1.0 Doesn't Yet Solve

A2A v1.0 is production-stable for the deployment patterns the major cloud platforms support natively^[15]. It is not yet seamless plug-and-play across every framework, every threat model, and every production scenario. Five gaps deserve explicit naming because they shape what an implementer should expect to build versus inherit.

Schema standardization. A2A standardizes the envelope — message format, task lifecycle, transport binding, security scheme^[10][12] — but not the payload semantics. Two A2A-compliant agents can exchange messages successfully at the protocol level while completely disagreeing on what the messages mean. This is by design (it lets agents in different domains interoperate without a shared schema lockout) but it pushes the standardization burden to the application layer. Enterprise teams shipping cross-vendor pipelines have reported this as a recurring friction point^[15].

Determinism for high-stakes workflows. The protocol does not specify deterministic execution semantics. Financial workflows where the same input must produce the same output every time — settlement, reconciliation, regulatory reporting — require additional engineering on top of A2A's transport guarantees. The protocol is correct (it does not promise determinism) but the gap between "A2A-compliant agent" and "deterministic agent" is real, and the pattern most teams adopt is to wrap critical paths in deterministic orchestration layers (e.g., Salesforce Agent Broker^[50]) rather than rely on raw A2A semantics.

Observability. Distributed tracing across agent boundaries is not specified by the protocol. Enterprise teams deploying A2A at scale are integrating OpenTelemetry manually across every agent boundary^[15]. When a root orchestrator delegates to three specialist agents, each of which makes additional tool calls, attributing end-to-end latency to specific agents or identifying where a failure occurred requires distributed tracing infrastructure that the protocol itself does not provide. ServiceNow's AI Control Tower — a governance layer above AI Agent Fabric — is the most mature enterprise response to this^[52]; analogous control planes are being built at the platform level rather than the protocol level.

Per-request authorization with delegation chains. As Part II covered, AgentCardSignature signs the Card; per-request signing is in proposal form via x-agent-trust (Issue #1742)^[24]. Authorization with delegation chains — proving that Agent A authorized Agent B which authorized Agent C — is not part of the v1.0 spec^[24][25][27]. The pattern most teams adopt is transport-layer mTLS plus OAuth bearer tokens with scoped audiences, but a protocol-native delegation primitive is still missing.

Framework adoption is uneven. As Part IV noted, CrewAI ships native A2A support^[15], but LangGraph and AutoGen — two of the most widely deployed orchestration frameworks in production — do not^[15]. Teams using these frameworks must implement the A2A server side themselves. The pattern an implementer should expect: if your stack is hyperscaler-native (Vertex AI, Azure AI Foundry, Bedrock AgentCore) or vendor-platform-native (Salesforce Agentforce, ServiceNow AI Agent Fabric), A2A is plug-and-play; if your stack is custom-built on LangGraph or AutoGen, expect to invest in middleware.

The institutional foundation is solid — Linux Foundation governance with eight founding TSC members, multi-vendor commitment via AAIF, a stable v1.0 spec, five production SDKs, three hyperscaler integrations. The protocol layer is settled. The implementation gap — getting from "A2A is the standard" to "A2A is interoperable in my specific production deployment" — is where the next twelve months of engineering work will be concentrated. Gartner's forecast, summarized in tier-1 analyst coverage^[63][64], captures the macro picture: only 30% of enterprises will achieve system-level interoperability without a standardized protocol^[63]. A2A is the most credible candidate for that standardization layer. The gap between "candidate" and "delivered" is what implementers reading this paper will help close.

#Quotable Findings — Part VII: Honest Limits

1. Per the AgentMarketCap one-year report^[15], enterprise teams deploying A2A at scale are integrating OpenTelemetry manually across every agent boundary because the protocol itself does not specify distributed tracing — observability is solved at the platform level (e.g., ServiceNow's AI Control Tower above AI Agent Fabric), not at the protocol level.
2. Per the analysis of Issues #1497, #1672, #1742, and Discussion #1752^{[24][25][26][27]}, per-request signing and authorization with delegation chains are in proposal form, not v1.0 spec — the pattern most production teams adopt is mTLS + OAuth bearer tokens with scoped audiences.
3. Per the AgentMarketCap framework-gap analysis^[15], LangGraph and AutoGen — two of the most widely deployed orchestration frameworks — lack native A2A support as of April 2026, while CrewAI 1.10.1+ ships it; the practical implication is that teams using LangGraph must implement A2A server side themselves.
4. Per Machine Brief^[63] and AgentMarketCap commentary^[64], Gartner forecasts that only 30% of enterprises^[63] will achieve system-level interoperability without a standardized protocol — making A2A the most credible candidate for that layer.
5. Per the Salesforce Agent Fabric April 15, 2026 expansion^[50], deterministic orchestration is a separate product (Agent Broker, in beta) layered on top of A2A — confirming that A2A's transport layer alone is not sufficient for high-stakes deterministic workflows and that vendor-specific layers are how the determinism gap gets filled in production.

#Glossary

A2A Protocol (Agent-to-Agent Protocol): The Linux Foundation-governed open standard for inter-agent communication, originally launched by Google in April 2025 and donated to the Linux Foundation in June 2025. v1.0 shipped March 12, 2026. Defines six core operations, three transport bindings (JSONRPC, gRPC, HTTP+JSON), Agent Cards as discovery primitive, and JWS-signed identity. Spec at a2a-protocol.org.

Agent Card: The JSON metadata document an A2A server publishes (default path /.well-known/agent-card.json) describing its capabilities. Required fields include name, description, url, version, capabilities, defaultInputModes, defaultOutputModes, skills, and supported_interfaces. May carry an optional signatures array of AgentCardSignature records.

AgentCardSignature: A JSON Web Signature (JWS, RFC 7515) over the canonicalized Agent Card. Provides cryptographic proof that the Card was issued by a trusted authority and has not been tampered with. Carries protected (required, base64url-encoded JSON), signature (required, base64url-encoded), and optional header fields.

JWS (JSON Web Signature): IETF standard (RFC 7515) for digitally signing JSON content. The basis of Agent Card signing in A2A.

JWKS (JSON Web Key Set): Standard format for publishing the public keys an agent uses for signing. Typically served at a stable endpoint identified by the jku or kid JWS header parameters.

RFC 8785 (JSON Canonicalization Scheme, JCS): IETF standard for producing a deterministic, byte-identical serialization of JSON. Required for stable JWS signing — without canonicalization, two semantically identical JSON documents can produce different byte sequences and break signature verification. Adopted formally in A2A v1.0 for Agent Card signing.

AAIF (Agentic AI Foundation): Linux Foundation project launched December 2025, co-founded by Anthropic, Block, and OpenAI. Hosts both MCP and A2A under one governance umbrella with mandate to ensure interoperability, prevent fragmentation, and certify conformant implementations.

AI Agent Fabric: ServiceNow's multi-agent communication backbone introduced in the Now Assist AI Agents 6.0.x store app shipped in the December 2025 Zurich release. Provides A2A v0.3+ support for connecting ServiceNow-built, customer-built, and partner-built agents with OAuth 2.0 plus federated token authentication.

AP2 (Agent Payments Protocol): A2A extension maintained at github.com/google-agentic-commerce/ap2 for agent-driven payment transactions. Has 60+ supporting organizations in payments and financial sectors as of April 2026. PayPal cited as a production reference.

Vertex AI Agent Engine: Google Cloud's fully managed runtime for AI agents, with native A2A support. Documentation reports "hundreds of thousands of agents" deployed.

Azure AI Foundry / Copilot Studio: Microsoft's enterprise agent platform with native A2A integration shipped in early 2026, covering agent discovery via Agent Cards and task delegation across Copilot Studio agents.

Amazon Bedrock AgentCore Runtime: AWS's enterprise agent runtime with A2A support added as part of the AgentCore launch.

Salesforce Agent Fabric: Salesforce's "trusted agent control plane" launched September 2025, managing thousands of agentic instances with native MCP and A2A support, expanded April 2026 with Agent Scanners, MCP Bridge, AI Gateway LLM Governance, and Trusted Agent Identity.

MCP (Model Context Protocol): Anthropic-originated open standard (November 2024) for connecting agents to tools, databases, and APIs. Now governed by the AAIF under Linux Foundation. Vertical complement to A2A's horizontal coordination.

x-agent-trust extension: A proposal in Issue #1742 for an A2A extension that adds per-request signing capability via an Agent-Signature HTTP header carrying ECDSA signatures over canonicalized request bodies. Decomposed into Agent Card identity (slowly-changing JWKS) and per-request signature (body hash + nonce + timestamp + kid).

verifiedIdentity: A proposal in Issue #1672 for an optional Agent Card field carrying agentId, certificate, issuer, and verificationEndpoint to support pluggable identity providers (AgentID, APS, AIM).

ExtensionSupportRequiredError: A2A spec error returned when a required extension is not declared by the client. The wire-level affordance that makes the Extension Governance framework enforceable.

#Related Research

• The Agent Payment Stack 2026 — AP2 (Agent Payments Protocol) is the most consequential A2A extension in production. This paper covers the payments-specific layer in depth.
• The MCP Server Playbook for SaaS Founders — MCP is the vertical layer A2A composes with. Read this paper for what to ship at the tool-access layer.
• EU AI Act Article 14 for Agent Fleets — A2A's identity layer (signed Agent Cards) is what makes Article 14 oversight feasible across organizational boundaries; the paper covers the regulatory primitives that A2A's identity layer maps to.
• The Agent Fleet Operating Model — twelve quality SLOs and observability primitives that complement A2A's transport-layer guarantees. Read for the production observability layer that A2A does not specify.
• The WebMCP Tool Contracts — browser-side counterpart to A2A's server-side coordination. The two papers together cover the full client-and-server agent surface.

#References