A2A Protocol: An Enterprise Architecture Decision Guide

There is a pattern in enterprise AI deployments that almost every technology leader will recognise. The first agent works well. The second agent works well. Then someone asks why the two cannot talk to each other. The answer turns out to be weeks of bespoke integration work, fragile API glue, and a growing maintenance burden that quietly eats into the efficiency gains the agents were supposed to deliver.

This is the integration tax. Until recently, it was simply the cost of doing business in a multi-vendor AI environment.

The A2A Protocol is an attempt to standardise that boundary. It is backed by more than 150 organisations and managed by the Linux Foundation, with Microsoft, AWS, SAP, ServiceNow, Workday and IBM among its supporters. That breadth makes A2A relevant to architecture decisions; it is too early to treat it as universal infrastructure.

The A2A Protocol: 5 Minute Primer

The A2A Protocol defines a standard way for AI agents from different vendors to discover each other, communicate, and hand off tasks — without either system needing to know how the other works internally.

In practice, a Salesforce Agentforce agent handling a customer escalation could hand a retrieval task to a Google agent, which could query a ServiceNow agent for ticket history. A2A standardises the messages and task lifecycle between them. Implementers may still need product configuration, identity mapping, error handling and agreement on what each agent's capabilities mean.

The mechanism is straightforward: agents expose an Agent Card — a structured description of their capabilities, available actions, and authentication requirements. Orchestrating agents discover these cards, compose workflows, and delegate subtasks. Responses flow back through the same protocol layer. From a developer's perspective, integrating a new agent is closer to calling an API than building a custom connector.

Source datasets do not need to be copied wholesale between systems for agents to collaborate. A Salesforce agent can ask a ServiceNow agent to act where the data resides, but the request and any authorised result still cross a trust boundary. Data classification, minimisation and audit requirements therefore remain.

Why This Helps Enterprise AI Architecture

The conventional approach to multi-agent enterprise AI has required one of two compromises. Either consolidate everything onto a single vendor's platform and accept lock-in, or build and maintain custom integrations between platforms and accept technical debt. Most organisations have ended up doing some of both, and neither is satisfying.

A2A offers a third path: a heterogeneous agent ecosystem where vendors compete on capability rather than proprietary integration. The Salesforce-Google announcement demonstrates this concretely — two major competitors building complementary agents that interoperate rather than forcing customers to choose.

The implications for enterprise architecture are material:

• Best-of-breed with a common protocol. Organisations can select agents by capability while reducing the amount of bespoke message and task-lifecycle code between them.
• A narrower form of vendor lock-in. A common protocol can make substitution easier, but product-specific data models, identity controls and workflow semantics can still create migration work.
• Composable workflows. Complex business processes that span multiple systems — order-to-cash, hire-to-retire, procure-to-pay — can be automated by orchestrating specialist agents rather than requiring a single monolithic AI deployment.
• Potentially shorter integration work. Pre-built, genuinely interoperable agents can reduce protocol plumbing, although end-to-end testing and operational integration remain.

The 150+ Organisation Ecosystem

The breadth of A2A adoption matters as much as the protocol itself. With Google, Microsoft, AWS, Salesforce, SAP, ServiceNow, Workday, and IBM all committed, A2A covers the core enterprise software stack for most large organisations. A workflow that needs to touch CRM, ERP, ITSM, and HCM systems can do so through A2A. None of those vendors need bespoke agreements with each other.

The Linux Foundation's stewardship matters too. Placing A2A under open governance reduces dependence on one vendor's roadmap and creates a formal route for multiple implementers to shape the specification. Kubernetes shows that neutral governance can support broad infrastructure adoption, but A2A still has to prove implementation consistency and operational maturity.

A2A is complementary to, not competitive with, Anthropic's Model Context Protocol (MCP), which governs how individual agents access tools and data sources. MCP handles the agent-to-tool layer; A2A handles the agent-to-agent layer. Enterprises building on Claude Managed Agents can use both.

What This Means for Your Platform Decisions

If you are evaluating or re-evaluating your AI platform strategy, A2A changes several of the assumptions that have historically driven those decisions.

Re-evaluate the case for platform consolidation

The traditional argument for standardising on a single AI platform includes integration simplicity. Working A2A support weakens the protocol-level part of that argument, but consolidation can still simplify identity, observability, support, data models and commercial management. Test those layers separately instead of treating protocol compatibility as portability.

Prioritise A2A support in vendor selection

Ask vendors which A2A specification version they support, which authentication profiles are implemented, how Agent Cards are governed, and whether conformance has been tested with products outside their own ecosystem. A roadmap statement is weaker evidence than a repeatable interoperability test.

Think in workflows, not tools

A2A enables a shift in how enterprise AI is designed. Rather than deploying an AI tool that assists with individual tasks, organisations can design end-to-end workflows where multiple specialist agents collaborate. This requires a different conversation internally — from "which AI tool do we buy?" to "which business process do we want to automate end-to-end, and which agents are best suited to each stage?"

Plan your data governance model now

A2A enables agents to collaborate without moving data between systems, but this requires deliberate configuration. Establish which agents are permitted to instruct which other agents, what data each is authorised to access, and how audit trails are maintained across multi-agent workflows. These governance decisions are much easier to make before workflows are in production than after.

A2A does not eliminate multi-agent complexity. It gives teams a common protocol at one important boundary. Treat it as an interoperability layer to test, not as proof that a multi-vendor workflow is portable, secure or operable end to end.

Frequently asked questions

What is the A2A protocol?

An open standard, managed by the Linux Foundation and backed by more than 150 organisations, for agent discovery, task exchange and status updates across vendor and framework boundaries. Product-specific integration, identity and semantic alignment may still be required.

How does A2A work in practice?

Each agent exposes an Agent Card describing its capabilities, actions and authentication. Orchestrating agents can discover these cards and delegate tasks through a common protocol. Source datasets can remain in their systems, although task messages and authorised results still cross system boundaries.

How is A2A different from MCP?

They operate at different layers. Anthropic's Model Context Protocol governs how a single agent accesses tools and data; A2A governs how agents talk to each other. They are complementary, and enterprises can use both.

What should enterprises do about A2A now?

Ask every AI platform you evaluate whether it supports A2A and on what timeline, reconsider the integration-driven case for single-vendor consolidation, design in workflows rather than tools, and set your multi-agent data-governance model before workflows reach production.

We publish pieces like this regularly. Get new posts by email.