Salesforce reached a milestone for its agent ecosystem on October 12, 2026, when the Winter ’27 Release became generally available. The announcement, which carries an August 31, 2026 date, signals a shift in how enterprise software vendors describe their connectivity. According to the release documentation, “Agentforce’s native Third-Party Orchestration extends Agentforce across any A2A-compliant ecosystem.” This capability allows the system to orchestrate agents from AWS, Azure, Google, and other providers, or to participate as a subagent in architectures where external orchestrators already exist. The phrase A2A-compliant has officially moved from the technical documentation of a protocol into the product packaging of a major enterprise suite.
The label has a precise home: the A2A Protocol Specification, whose latest released version is 1.0.0. In this context, wire-level compliance means an entity has implemented the protocol and publishes a self-described Agent Card. This card is a JSON metadata document that the server publishes about its own identity, capabilities, skills, endpoint, and authentication requirements. When two systems are A2A-compliant, they can engage in interoperable conversations, including task exchange, capability discovery, and standard bindings. This allows agents to interact without requiring custom, point-to-point integrations for every new connection.
However, the label certifies far less than the marketing language implies. A buyer should recognize three specific limitations. First, counterparty identity is entirely self-asserted. The specification states that Agent Cards may be digitally signed using JSON Web Signature, but this is optional. While clients should verify signatures when present, the protocol does not mandate them. Second, there is no governance layer for discovery. A formal registry specification never shipped, as evidenced by the closure of A2A GitHub Discussion #741. The maintainers redirected the discovery need to two adjacent specifications, AI Catalog and ARD, leaving the registry question unresolved. Third, the protocol is designed for opaque execution, meaning agents collaborate based on declared capabilities without needing access to each other’s internal state, memory, or tools. Compliance certifies the conversation, not the conduct or the behavior of the agent itself.
The consequence of this shift is that interoperability has become a procurement question. Because a major enterprise suite now sells orchestration across any A2A-compliant ecosystem as a generally available product, the burden of verification falls squarely on the buyer. The label provides a common language for connection, but it does not provide a guarantee of safety or identity. Organizations must now validate the agents they connect to their internal systems, as the protocol remains agnostic to the underlying intent or reliability of the participants.
The industry will likely grapple with these gaps at the upcoming AGNTCon and MCPCon North America, scheduled for October 22-23, 2026, in San Jose. With over 3,500 attendees and 1,000 organizations expected, the event serves as a focal point for the infrastructure of the agent economy. Google Cloud VP Rao Surapaneni is set to keynote on October 23 regarding the challenge of shipping autonomous agents safely with open standards, observability, and control. His talk will cite open protocols like the Model Context Protocol, A2A, and OpenTelemetry. Observers will be watching to see if the registry and conformance questions receive a formal home or if the vacuum continues to be filled by fragmented vendor extensions.
A buyer must look past the marketing label to verify the actual state of an integration. One can fetch the Agent Card from the well-known path to inspect the metadata directly. A prudent operator should ask whether the card is digitally signed and which specific registry, if any, governs the discovery of that agent. These steps provide a baseline for trust that no single compliance label can currently answer. As the ecosystem matures, builders must distinguish between protocols that enable connections and systems that enforce secure, reliable behavior.