Two open standards now form the plumbing beneath every serious agentic AI deployment: Model Context Protocol (MCP), which governs how agents access enterprise data, and Agent2Agent (A2A), which governs how agents coordinate with each other. Both sit under the Linux Foundation, MCP originating at Anthropic and A2A launched by Google with backing from Salesforce, SAP, and others. The standards are real and already in use, but critical gaps remain<\/a>, particularly around cross-vendor agent identity and memory persistence, gaps that working groups are still actively closing.<\/p>\n Where you sit on the MCP-versus-A2A adoption curve tells you almost everything about your organizational readiness. If your team is still building single-task agents that pull documents or run a calculation, you are an MCP shop, which describes the majority of enterprises right now. A2A only becomes relevant when you start chaining agents across functions or vendors, and that moment arrives faster than most IT roadmaps anticipate. The companies that treat MCP deployment as a one-off project rather than an architectural commitment will hit a wall the moment their agents need to hand off work.<\/p>\n The unsolved problem that deserves more attention than it gets is what Forrester calls “portable agent identity,” which is essentially the question of whether an agent from one vendor can be trusted to act inside another vendor’s system without human review at every boundary. Right now it cannot, at least not reliably. A DevOps chain involving a planning agent, a testing agent, and a security agent from three different vendors has no standardized way to enforce permissions across that chain. That is not a theoretical risk; it is the specific failure mode that will surface the first time an autonomous agent touches a production environment it shouldn’t.<\/p>\n The vendors most exposed by this gap are the ones selling the vision of fully orchestrated, multi-agent enterprises today, while the working groups building the identity layer are still months away from a usable spec. The practical implication for anyone renewing an enterprise AI contract or evaluating an orchestration platform is straightforward: ask the vendor exactly how cross-vendor agent permissions are enforced at runtime, and treat a vague answer as a red flag, not a roadmap.<\/p>\n Portable agent identity is the mechanism that lets an AI agent carry verifiable credentials about who it is, which systems it is allowed to touch, and what actions it is forbidden to take, even when it moves across vendor boundaries. Think of it as a passport with access controls baked in. Without it, trust collapses to the lowest common denominator: a human in the loop at every handoff. A2A’s current spec handles orchestration but leaves this identity layer largely unresolved, which is why multi-vendor agent chains remain operationally risky.<\/p>\nWhat this means for your business<\/h2>\n
Concept deep-dive: Portable agent identity<\/h2>\n