The label before the spec: what “A2A-compliant” actually verifies
Sources cited in this piece · Salesforce, Top Innovations in the Winter '27 Release (2026-08-31; GA 2026-10-12) · Agent2Agent (A2A) Protocol Specification v1.0.0 · Forkast reporting 2026-10-10 and 2026-10-12 (archived copies)
On October 12, 2026, Salesforce's Winter '27 release became generally available. The announcement, dated August 31, carries one sentence that deserves to be read slowly: “Agentforce's native Third-Party Orchestration extends Agentforce across any A2A-compliant ecosystem — enabling Agentforce to orchestrate agents from AWS, Azure, Google, and more or to participate as a subagent in architectures where external orchestrators already exist.”
With that sentence, “A2A-compliant” moved out of a protocol's technical vocabulary and into the product packaging of a major enterprise suite. A label that sells is a label that gets audited — so the fair question is not whether the phrase is justified, but what it verifies. Our verdict up front: the label certifies the conversation, not the counterpart; and the industry is currently shipping answers faster than it ships the rubric.
1. What the label rides on
The Agent2Agent (A2A) specification defines the Agent Card as “a self-describing manifest for an agent” — the agent publishes its own identity, capabilities, skills and security requirements at a well-known address. The signature field exists, but it is optional: signatures — array of AgentCardSignature — No — JSON Web Signatures computed for this AgentCard, in RFC 7515 JWS format. So the floor of “compliant” is: speaks the wire protocol, and serves a self-published name card.
Forkast's summary of the GA is blunt, and we find nothing in the specification that contradicts it: the protocol “ships the wire and a self-published name card, and almost nothing a procurement team would want verified.”
2. Three things the label does not verify
First: counterparty identity is self-asserted. The card states who the agent claims to be; the signature that would bind that claim to a key is a MAY, not a MUST. TLS grounds the connection in a certificate — and a certificate anchors a domain, not an agent. Many agents can live behind one domain, sharing one certificate, the way many tenants live behind one doorbell.
Second: discovery has no governance layer. A formal registry specification never shipped — the A2A project closed the discussion that hosted the registry work and redirected the need to two adjacent specifications, AI Catalog and ARD, both of which have their own ratification processes ahead of them. In the meantime, as an Apicurio engineer put it in May 2026: “at least five independent registry implementations are shipping with incompatible APIs, which means the interoperability window is closing — the longer we wait, the harder it gets to align.”
Third — and this is design, not defect: compliance certifies the conversation, not the conduct. The protocol is built for opaque execution: agents collaborate on declared capabilities without needing access to each other's internal state, memory or tools. A label on that design honestly says “we can talk” — it says nothing about what either side will do once the talking starts.
3. The vacuum does not stay empty
The label went GA on October 12. Three related artifacts had been promised for October; as of October 10, none had shipped. The Personal Agent Protocol (PAP) — announced October 6 at the Sierra Summit by Sierra and Meta with six launch partners including Shopify, Stripe and Walmart, followed on October 9 by a working draft named Poppy with thirty-five design partners including OpenAI, Visa and Mastercard — still had no formal v0.1. The general availability of Google's Gemini Agent, announced October 8, remained in private preview. And the A2A Agent Registry formal specification, whose three-layer architecture (Agent Card, Publication Record, Trust-Authorization Overlay) the community had already converged on since its June 2025 proposal, remained unratified.
This is vacuum economics, and it is nobody's conspiracy: when a standard slips, the market does not pause. Vendor extensions and independent implementations fill the gap and harden their own assumptions about identity, trust and discovery — assumptions that may never quite align with the final spec. Builders select on what has shipped. The label shipped; the rubric did not. That order of operations is worth naming, because it quietly decides where verification will live for years.
4. What would make the label mean something
A label becomes verifiable when a buyer can check it without trusting the seller. Three upgrades would do most of the work: (1) a signature that is expected rather than optional — and a named key authority behind it, so “who vouches” is a field, not a rumor; (2) freshness — an answer to “is this card still true now,” carried inside the artifact with an expiry, instead of signed into permanence; (3) independent verification — checkable offline, with the network cut, without reaching a live chain of registries.
This is where our two pillars sit, and we state the boundary precisely. Where a statement lives is an addressing question — the Resonant Time Transfer Protocol (RTTP) derives the answer from a canonical authority, so discovery needs no landlord registry at all. Whether a statement stands is an attestation question — Identity Quality Assurance (IQA) seals the answer into a fixed-size envelope that carries its vouching subject, a 120-second standing lease, and verification that completes offline. Nothing in the A2A wire format forbids any of this; the card could carry all three tomorrow. We are not selling a replacement — we are pointing at the empty rows of the table above.
5. A checklist for buyers, today
None of this requires waiting for a spec. If a vendor sells you “A2A-compliant,” ask five things: fetch the Agent Card yourself from its well-known address; check whether it is signed, and verify the signature if it is present; ask which registry — of the several shipping — governs discovery, and how stale entries expire; ask what the vendor's own test suite certified, conversation or conduct; and ask what happens to your orchestration when the counterparty's card changes. Forkast is right that the burden of verification has moved to the buyer — our addition is that the burden should be carried as a spec question, not a marketing question.
Sources [1] Salesforce, Top Innovations in the Winter '27 Release (2026-08-31; GA 2026-10-12), salesforce.com — quoted verbatim, accessed 2026-10-18 [2] Agent2Agent (A2A) Protocol Specification v1.0.0, a2a-protocol.org — AgentCard definition (“a self-describing manifest for an agent”), optional signatures field (RFC 7515 JWS), accessed 2026-10-18 [3] Forkast, “A2A-Compliant Is Now a Shipping Label. The Spec That Would Define It Has Not Shipped.” (2026-10-12) — quoted verbatim from the archived original (forkast.news, fetched 2026-10-18; also syndicated at toscale.io) [4] Forkast, “Three Agent Specs Promised for October Remain Unshipped. The Vendor Extensions Filling the Vacuum Are Fragmenting the Stack.” (2026-10-10) — quoted verbatim from the archived original (fetched 2026-10-18) [5] Editorial note: [3] and [4] are secondary reporting; their factual claims about the Salesforce release were re-checked against [1], and their characterizations of the A2A specification against [2]. Individuals named in secondary sources are cited by affiliation only.
One line: a label is a claim about a claim — the interesting engineering is making the second claim checkable, row by row, by someone who owes the seller nothing.