When tech giants release a new protocol, it is rarely out of pure technical altruism. More often than not, it is a way for a giant to stake out territory, set rules, and quietly impose its own engineering habits on the broader industry. Choosing a protocol is never just about adding a few lines of API code; it means surrendering your system architecture to someone else’s design philosophy. When Google introduced the Agent-to-Agent (A2A) protocol in 2025 and later donated it to the Linux Foundation, the exact same underlying logic was at play.
In an era where AI inference costs just fractions of a cent per request, developers can easily spin up a simple JSON endpoint if two systems need to talk. Why, then, did enterprise giants like Salesforce, SAP, and ServiceNow gather around the table to push a dedicated A2A protocol? Is this solving a genuine engineering bottleneck, or is it just another wave of hype?
In production enterprise environments, the friction scenarios that traditional APIs fail to address—and yet cause immense operational headaches—are actually very specific. This is not about single-machine code execution or internal microservice calls; it is about cross-organization, cross-platform remote delegation. In actual enterprise workflows, such applications have very clear boundaries.
Take enterprise customer support as a concrete example. A customer submits a complex refund dispute on a Salesforce front-end page. After the Salesforce AI identifies the user intent, querying internal CRM data alone is insufficient. It must reach out to SAP’s AI to check ERP financial deductions, while simultaneously calling ServiceNow’s AI to review historical ITIL service tickets. These three AIs run on entirely different cloud infrastructures, built by three competing software vendors, with zero mutual trust over each other’s private data assets. If the goal were merely fetching static data, standard REST APIs would suffice. But the crucial requirement here is that the AIs inside SAP and ServiceNow must perform independent reasoning and rule evaluations within their own trust boundaries.
During execution, SAP’s AI might pause its workflow due to risk threshold violations, waiting for a human manager’s manual approval; or it might require cross-tenant user re-authorization because an OAuth credential expired. This long-running, pause-and-resume execution model—combined with cross-system governance—is the true fertile ground where A2A protocol requirements grow.
The supply chain pilot between Tyson Foods and major distributor Gordon Food Service illustrates another representative cross-company scenario. Tyson’s AI sales agent and Gordon’s AI procurement agent established a long-term conversational negotiation mechanism directly via protocol boundaries. The agents on both sides operate like black boxes: Tyson does not need to expose its internal database schemas or private system prompts to Gordon, nor does Gordon need to open up its internal ERP purchasing endpoints. Governed by protocol boundaries, both agents automatically share real-time inventory levels, negotiate replenishment schedules, and pass sales leads. The essence of cross-boundary collaboration is not replacing local function calls, but building a stateful, permission-governed bridge between two mutually untrusted, architecturally distinct enterprise systems.
Since cross-boundary delegation is a genuine need, why can’t developers simply piece together ad-hoc REST APIs instead of inventing a standardized protocol? To understand this demand, it helps to contrast A2A with Anthropic’s Model Context Protocol (MCP). Their core design goals and target problems reflect two entirely different engineering paradigms.
MCP addresses a very direct challenge: enabling AI models to seamlessly read local files, query Postgres databases, or invoke Slack APIs. Born out of Anthropic’s desire to improve Claude Desktop and IDE developer experiences, MCP is lightweight, relies on standard I/O or simple HTTP, and aims to let developers attach local tools to model context in under ten minutes.
However, when the problem shifts from attaching local tools to delegating multi-turn tasks from one company’s AI to another company’s AI, both traditional APIs and MCP hit immediate limits. In cross-company delegation, you cannot assume the remote agent’s tech stack, you cannot predict how long it will run, and you certainly cannot rely on simple synchronous HTTP request-response cycles. A remote agent might reason for three minutes before discovering insufficient permissions, pausing to wait for human intervention, or needing to stream real-time progress updates back to the orchestrator.
The more brutal reality stems from commercial and market size asymmetry. As the saying goes, fish where the fish are. MCP targets the vast majority of mainstream AI developers—anyone building an AI application needs to connect their model to databases and local files. This universal need and low barrier to entry allowed MCP to quickly generate explosive grassroots ecosystem momentum across Cursor, VS Code, and open-source communities. In contrast, cross-agent remote RPC targets an extremely niche enterprise market: only when organizations grow large enough to coordinate AIs across Salesforce, SAP, and UiPath does a standardized inter-agent RPC protocol become necessary. This massive gap in addressable market size naturally dictates that A2A’s developer ecosystem momentum remains far lower than MCP’s.
To solve the challenges of long-running execution, zero-trust
boundaries, and cross-organization authorization, Google offered a
distinctly Google-style engineering answer. Google designed A2A much
like building microservices: leveraging HTTP for transport, JSON-RPC 2.0
and gRPC for wire formats, and exposing capabilities via standardized
Agent Cards (/.well-known/agent-card.json) backed by
cryptographic signatures. This entire design was tailored from day one
to satisfy corporate infrastructure requirements around API gateway
routing, firewall traversal, OAuth2 delegation, and Server-Sent Events
(SSE) streaming.
For task orchestration, Google introduced an explicit task state machine covering the full lifecycle: from submitted and working, to input required (paused for input) and auth required (paused for authorization), ultimately converging to terminal states. This architecture contrasts sharply with MCP’s atomic, synchronous tool invocation. While MCP acts like a local function call returning immediate results, A2A must accommodate remote agents running for extended periods or requiring mid-workflow permission grants. In terms of role assignment, Google took a decisive stance by strictly separating the Client Orchestrator from the Remote Executor.
When many engineering teams experimented with multi-agent systems last year, the most intuitive idea was creating an agent chatroom—letting PM, Dev, and QA agents discuss tasks freely in natural language. But after running this in production, token bills and execution latencies provided a rude awakening. A simple task involving several turns of natural language clarification caused token consumption to jump fivefold and latency to stretch past ninety seconds, while minor hallucinations from any single agent frequently cascaded into global task failures. Relying on agents chatting freely to complete work proved engineeringly unviable. Google completely abandoned this chatroom fantasy, enforcing strict control flow: a central orchestrator retains global intent, while remote agents serve purely as specialized execution units.
Yet while this design resolves remote RPC complexities, it faces severe erosion within single applications from in-memory sub-agent architectures. When people discuss multi-agent value, they frequently cite three classic use cases: using a sub-agent to scan 50,000 lines of logs and return a 200-word summary for context garbage collection, using a planner model paired with a cheaper model for cost reduction, or dispatching multiple sub-agents for parallel search. But assuming these require a network protocol is a fundamental misconception; in real-world deployment, none of these single-application patterns require any network protocol whatsoever.
In modern agent tools like Claude Code, Codex, or OpenCode, in-process sub-agent mechanisms solve these exact problems locally with zero network overhead. Developers can fork contexts and dispatch sub-tasks directly within local memory, without deploying HTTP endpoints or configuring Agent Cards. The stellar performance of local sub-agents inside single-system applications consumes the vast majority of A2A’s potential use cases, leaving A2A’s non-substitutable value strictly confined to the remaining ten percent of cross-company remote RPC scenarios.
These architectural trade-offs and market squeezes combine to produce a rather awkward outcome for inter-agent protocols. A narrow addressable market, paired with formidable security and engineering hurdles, leaves A2A in a thankless predicament. Enabling agents to communicate across network boundaries introduces endless security vulnerabilities.
The most lethal threat is prompt injection cascading. If a web-scraping sub-agent is compromised by malicious payload data, its returned output can trick the parent orchestrator into executing dangerous local commands, such as deleting workspace files or exfiltrating API keys. Another thorny issue is the confused deputy problem, where a low-privilege external agent leverages a high-privilege remote agent’s identity to access unauthorized data.
A deeper danger lies in the mismatch of authorization models. Local CLI tools default to inheriting the user’s local terminal permissions; however, once wrapped as an HTTP A2A server, the tool instantly transforms into a remote multi-tenant service. Google’s own Gemini CLI recently patched a critical A2A isolation vulnerability after discovering that sharing a workspace across multiple A2A tasks allowed prompt injections to escalate directly into remote code execution. Furthermore, zombie tasks present persistent operational risks: if a user cancels a job without reliable cancellation notifications reaching the remote agent, the remote worker becomes a zombie process silently burning tokens and potentially writing corrupt data in the background.
An extremely niche target market, compounded by prompt injection cascades, identity propagation, multi-tenant sandbox isolation, and zombie task cancellation, ultimately seals the fate of the A2A protocol. It will likely quiet down and continue serving as part of enterprise B2B plumbing, but across the broader AI developer ecosystem, it is destined to remain lukewarm.