06-reference/research

cross substrate agent identity registry standard

2026-09-13·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
agent-identityagent-registrya2aportabilitycompetitor

Agents Can Now Carry Identity Across Vendors, but Agent State Still Has No Standard

The question

Is a cross-substrate agent-state / agent-registry / agent-identity standard (A2A, MCP-registry) emerging that would let a third party own agent state across Agent 365 + Agentspace + Agentforce?

Context: this is open follow-up #4 from [[2026-07-04-enterprise-agent-roles-vs-agent-pets-default]]. That brief concluded that RDCO's wedge is "substrate-portable state-ownership above whichever control plane the client runs" and warned that a portability standard would narrow it. This brief checks what shipped or was ratified between July and September 2026. It separates "announced support" from "shipped and documented."

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

Direct answer: no. No standard has emerged that lets a third party own agent state across Agent 365, Agentspace/Gemini Enterprise and Agentforce. Between July and September 2026, what shipped was portable agent identity (OAuth/OIDC plus workload-identity federation, now a WIMSE working-group draft) and A2A-based discovery and messaging. Every vendor also built its own "central registry for everyone's agents." Identity and messaging are plumbing. State (the role definition, memory, eval history and operating context that make an agent-role compound) has no standard at the protocol layer, the registry layer or the IETF layer. The July brief's feared outcome, "a portability standard lands and the wedge narrows," has not happened for the part of the wedge that matters.

For RDCO the net effect widens the seam, but it splits the wedge in two, and one half is being taken. The half being taken is cross-vendor agent inventory and governance. Google's Agent Registry explicitly catalogs third-party agents and MCP servers, and Agent 365 is positioned as the unified registry on top of Entra. A pitch like "we'll give you one pane of glass over all your agents" is now a line item those two platforms bundle. RDCO should stop implying it. The half that widens is client-owned state above the substrates. Identity federation and A2A Agent Cards now make it cheap for one client-owned agent-role to be enrolled in all three hubs at once. It can hold an Entra Agent ID via federation, appear in Google's registry as an A2A agent, and be reachable from Agentforce over A2A. Meanwhile its role definition, skills, evals and memory live in a store the client owns. The plumbing standards lower the cost of operating above the substrates. None of them moves the state into the substrate.

The concrete positioning move for the founder's lane is "state in the client's data platform, identity federated in." A phData Snowflake client can keep agent state (skills, role specs, eval logs, memory) as governed tables in its own Snowflake account. The same agent then authenticates into M365 via Entra workload-identity federation and into Google via Agent Identity, exactly as documented. The honest caveat is that federation into Entra is documented, but nothing primary shows that Agentforce accepts external agent identities the same way. The Salesforce leg is the weakest link in any "works across all three" claim, and it should not be pitched as proven.

Narrowing triggers to watch, which would actually shrink the wedge: (1) a vendor-neutral registry that all three hubs sync to, for example MCP Registry GA extended to agents, or a Linux Foundation agent directory adopted by Microsoft, Google and Salesforce; (2) A2A or MCP adding a state/memory primitive, the same trigger named in [[2026-07-25-portable-agent-memory-standard]]; (3) one hub, most plausibly Agent 365 given Entra's identity-provider gravity, becoming the de facto registry of record and offering durable agent-state storage for third-party agents. None of the three is visible in primary sources as of 2026-09-13.

Why this is in the vault

This brief answers the portability-gap follow-up from [[2026-07-04-enterprise-agent-roles-vs-agent-pets-default]]. It directly edits the RDCO/phData agent-deployment pitch: drop "cross-vendor agent inventory" (now bundled by Google Agent Registry and Agent 365), and lead with "client-owned agent state in the client's Snowflake, identity federated into each vendor hub." It also resolves the identity watch-trigger in [[2026-07-25-agent-first-class-identity]]: the federation pattern for giving a non-Microsoft agent an Entra Agent ID is now documented.

Open follow-ups

Related

Sources

Vault:

Web (primary, fetched):

Web (primary, search-index only, not fetched):

Web (secondary, claims marked UNVERIFIED above):