Google A2A Protocol: The MCP Rival With 50 Launch Partners #

Google unveils the Agent2Agent (A2A) protocol today at Google Cloud Next '25 — an open specification that lets AI agents from different vendors discover each other, negotiate capabilities, and collaborate on complex tasks. With 50+ launch partners including Salesforce, SAP, Atlassian, ServiceNow, Box, Cohere, LangChain, and Workday, A2A represents the most significant attempt yet to standardize how autonomous agents communicate across organizational and platform boundaries.

The announcement is triggering immediate debate about whether A2A competes with or complements Anthropic's Model Context Protocol (MCP), which launched in November 2024 and has since become the default standard for connecting AI assistants to tools. The reality is simpler than the Twitter discourse suggests: MCP connects models to tools; A2A connects agents to other agents. You need both.

Here's the complete breakdown of what A2A is, how it works, and what the 50-partner launch means for the future of multi-agent systems.

---

Table of Contents #

• What Is the Agent2Agent (A2A) Protocol?
• A2A vs MCP: Complementary, Not Competing
• How A2A Works: The Technical Architecture
• Agent Cards: The JSON Metadata Standard
• Task Lifecycle Management and Multi-Turn Collaboration
• The 50+ Launch Partner Ecosystem
• Google Cloud Next '25: The Complete AI Stack
• Building With A2A: The Agent Development Kit
• Implications for Production AI Infrastructure
• Limitations and Open Questions
• Frequently Asked Questions

---

What Is the Agent2Agent (A2A) Protocol? #

A2A is an open protocol that standardizes agent-to-agent communication, enabling autonomous agents from different vendors to discover, negotiate, and collaborate on tasks without human intervention. Unlike MCP, which focuses on connecting a single model to tools and data sources, A2A addresses the higher-order problem of inter-agent coordination — what happens when multiple autonomous agents need to work together on a shared objective.

Google's announcement at Cloud Next '25 establishes A2A as a vendor-neutral specification, not a proprietary Google product. The protocol is hosted at google.github.io/A2A with open source reference implementations, and the specification is designed to be implementation-agnostic — any agent framework that supports HTTP and JSON can adopt it.

The core value proposition is interoperability at the agent layer. Before A2A, an enterprise running Salesforce's Agentforce, ServiceNow's AI agents, and custom Google ADK agents had three isolated systems that couldn't coordinate. With A2A, these agents can discover each other, advertise their capabilities through standardized Agent Cards, and negotiate multi-step task execution with shared context.

---

A2A vs MCP: Complementary, Not Competing #

The "A2A vs MCP" framing misses the architectural reality: these protocols operate at different layers of the AI stack and solve different problems. Understanding the distinction is essential for designing production multi-agent systems.

Dimension	MCP (Anthropic)	A2A (Google)
Layer	Model-to-tool connection	Agent-to-agent communication
Connection target	Tools, data sources, APIs	Other autonomous agents
Relationship type	Model uses tool	Agent collaborates with agent
State model	Stateful session	Task-oriented, multi-turn
Discovery mechanism	Static configuration	Dynamic Agent Card discovery
Negotiation	Tool schema matching	Capability negotiation
Scope	Single client-server pair	Multi-party collaboration
Typical use case	Claude queries a database	Sales agent negotiates with fulfillment agent

MCP connects an AI assistant to its tools. When Claude needs to read a file, query Postgres, or post to Slack, MCP provides the standardized wire protocol. It's the "USB-C for AI tools" — a common interface that lets any MCP-compatible client use any MCP-compatible tool.

A2A connects autonomous agents to each other. When a customer service agent needs to escalate to a technical support agent, or when a sales agent needs to coordinate with an inventory agent, A2A provides the protocol for that collaboration. It's the "email for AI agents" — a common format for inter-agent communication.

The stack looks like this:

┌─────────────────────────────────────────────────────────────┐
│                    MULTI-AGENT ORCHESTRATION               │
│              (A2A: agents coordinate via Agent Cards)       │
├─────────────────────────────────────────────────────────────┤
│                    MODEL-TOOL CONNECTION                   │
│        (MCP: each agent connects to its tools/resources)    │
├─────────────────────────────────────────────────────────────┤
│                    FOUNDATION MODELS                       │
│              (Claude, GPT-4, Gemini, etc.)                  │
└─────────────────────────────────────────────────────────────┘

A single enterprise deployment likely uses both: MCP for tool access within each agent, A2A for coordination between agents. The Salesforce agent uses MCP to query Salesforce data, then uses A2A to negotiate with the ServiceNow agent when the case requires IT support.

---

How A2A Works: The Technical Architecture #

A2A is built on HTTP with JSON message payloads, designed for web-native deployment and enterprise integration. The protocol defines explicit phases for agent discovery, capability negotiation, task creation, and collaborative execution.

The A2A Connection Flow #

When two agents need to collaborate, A2A specifies a four-phase interaction model:

Phase	Purpose	Key Actions
Discovery	Find and identify agents	Query Agent Card endpoint, parse capabilities
Negotiation	Agree on task parameters	Exchange supported operations, confirm availability
Execution	Perform the collaborative task	Create task, exchange messages, share artifacts
Completion	Finalize and hand off	Task status updates, result delivery, cleanup

Discovery starts with the initiating agent fetching an Agent Card — a JSON metadata document published by the target agent at a well-known URL (typically /.well-known/agent.json). The Agent Card specifies the agent's name, version, supported capabilities, authentication requirements, and available endpoints.

Negotiation involves the initiating agent sending a capability check to confirm the target agent can handle the requested task type. This prevents wasted effort on incompatible requests and allows agents to gracefully decline tasks outside their scope.

Execution centers on the Task object — A2A's core abstraction for collaborative work. Tasks have lifecycles (submitted, working, input-required, completed, failed), support streaming updates, and can include multi-turn interactions where agents request clarification or additional information from each other.

Message Types and Structure #

A2A defines several message types that flow between agents:

Message Type	Purpose	Direction
Task	Represents a unit of work to be performed	Bidirectional
Message	Communication within a task context	Bidirectional
Artifact	Structured output from task execution	Server → Client
Part	Component of message content (text, file, data)	Either direction

Tasks contain messages; messages contain parts. Parts can be text (natural language), files (binary or structured data), or data (JSON objects). This nesting enables complex collaborative workflows where agents exchange multiple types of information over extended interactions.

---

Agent Cards: The JSON Metadata Standard #

Agent Cards are the cornerstone of A2A's discovery mechanism — standardized JSON metadata that agents publish to describe their capabilities, endpoints, and authentication requirements. Think of an Agent Card as an agent's business card and API documentation combined.

Agent Card Structure #

An Agent Card follows a defined schema with these key fields:

Field	Purpose	Example
name	Human-readable agent identifier	"Salesforce Lead Qualification Agent"
version	Semantic version of the agent	"2.1.0"
capabilities	List of supported operations	["createLead", "updateContact", "qualifyOpportunity"]
skills	Detailed capability descriptions with input/output schemas	Array of skill objects
endpoints	URL paths for A2A operations	{ "a2a": "/a2a", "agentCard": "/.well-known/agent.json" }
authentication	Required auth mechanisms	{ "type": "oauth2", "scope": "a2a:execute" }

{
  "name": "Enterprise Sales Agent",
  "version": "2.1.0",
  "description": "Qualifies leads and routes opportunities to sales reps",
  "capabilities": {
    "a2aVersion": "1.0",
    "supportsStreaming": true,
    "supportsMultiTurn": true
  },
  "skills": [
    {
      "id": "qualifyLead",
      "name": "Lead Qualification",
      "description": "Scores and categorizes inbound leads",
      "input": {
        "type": "object",
        "properties": {
          "leadData": { "type": "object" },
          "scoringModel": { "type": "string", "enum": ["standard", "enterprise"] }
        }
      },
      "output": {
        "type": "object",
        "properties": {
          "score": { "type": "number" },
          "category": { "type": "string" },
          "recommendedAction": { "type": "string" }
        }
      }
    }
  ],
  "authentication": {
    "type": "oauth2",
    "authorizationEndpoint": "https://auth.enterprise.com/oauth2/authorize",
    "tokenEndpoint": "https://auth.enterprise.com/oauth2/token"
  }
}

The Well-Known Endpoint Pattern #

A2A adopts the IETF well-known URI convention for Agent Card discovery. Agents publish their metadata at /.well-known/agent.json, allowing any other agent to discover capabilities with a single HTTP GET request.

This pattern enables dynamic ecosystem formation — new agents can join a network and become discoverable without a central registry. Enterprise deployments can maintain internal directories, but the protocol itself doesn't require one.

---

Task Lifecycle Management and Multi-Turn Collaboration #

A2A's Task object enables sophisticated multi-agent workflows with explicit state management, streaming updates, and support for human-in-the-loop scenarios. This distinguishes A2A from simpler RPC-style protocols that assume single-request-single-response interactions.

Task States and Transitions #

A Task moves through defined states during its lifecycle:

State	Meaning	Transition Trigger
submitted	Task created, awaiting acceptance	Agent receives task creation request
working	Agent actively processing	Agent accepts and begins execution
input-required	Agent needs more information	Agent sends clarification request
completed	Task finished successfully	Agent delivers final result
failed	Task terminated with error	Unrecoverable error or cancellation

The input-required state is particularly important for realistic agent collaboration. When an agent needs clarification, additional data, or human approval, it transitions to this state and sends a message requesting input. The initiating agent can respond with the needed information, delegate to a human, or cancel the task.

Streaming and Async Updates #

A2A supports streaming task updates via Server-Sent Events (SSE), allowing long-running collaborative tasks to report progress in real time. This is essential for enterprise workflows where agents might work on tasks for minutes or hours — users need visibility into progress.

Multi-Turn Collaboration Example #

Consider a customer escalation workflow:

1. Support Agent (Salesforce) creates task: "Technical diagnosis required for enterprise customer"
2. Technical Agent (ServiceNow) accepts, transitions to working
3. Technical Agent requires logs, transitions to input-required, sends request
4. Support Agent retrieves logs via MCP from Salesforce, sends as message
5. Technical Agent analyzes, identifies hardware issue, sends preliminary diagnosis
6. Support Agent confirms customer has maintenance contract, approves dispatch
7. Technical Agent creates dispatch order, transitions to completed
8. Support Agent receives final artifact with dispatch confirmation and ETA

This entire interaction happens through A2A, with each agent maintaining its own internal MCP connections to its respective tools.

---

The 50+ Launch Partner Ecosystem #

Google's A2A announcement includes commitments from over 50 organizations spanning enterprise software, AI platforms, and systems integrators — the broadest agent interoperability coalition yet assembled. The partner list signals serious enterprise intent and provides immediate credibility for the protocol's production viability.

Key Launch Partners by Category #

Category	Partners	Significance
CRM/Customer Data	Salesforce, HubSpot, Intuit	Agent-to-agent customer workflows
Enterprise Platforms	SAP, ServiceNow, Workday, Atlassian	Cross-platform business process automation
Cloud/Productivity	Google Cloud, Box, MongoDB	Content-aware agent coordination
AI/ML Platforms	Cohere, LangChain, PayPal, Weights & Biases	Model and infrastructure integration
Systems Integrators	Accenture, BCG, Deloitte, PwC, McKinsey	Enterprise deployment and consulting
Agent Frameworks	CrewAI, LangChain, LlamaIndex	Open source multi-agent ecosystem

What Partner Commitment Means #

The Salesforce commitment is particularly significant. As the dominant CRM platform, Salesforce's participation means A2A could become the standard for customer-facing agent coordination. If Salesforce's Agentforce can negotiate with ServiceNow agents via A2A, enterprises can build true cross-platform customer workflows without vendor lock-in.

The LangChain and CrewAI partnerships bridge open source and enterprise. These frameworks power thousands of production agent deployments. Their A2A support means developers can continue using familiar tools while gaining enterprise-grade interoperability.

Systems integrator involvement signals enterprise readiness. Accenture, Deloitte, and PwC don't commit to protocols that can't pass security review. Their presence suggests A2A has been vetted for enterprise deployment patterns including authentication, audit logging, and compliance.

---

Google Cloud Next '25: The Complete AI Stack #

A2A doesn't exist in isolation — it's part of a comprehensive Google AI platform refresh announced at Cloud Next '25. Understanding the full context helps assess how A2A fits into Google's broader agent strategy.

The Complete Cloud Next '25 AI Announcement Stack #

Component	What It Is	A2A Relationship
Gemini 2.5 Flash	Fast, cost-efficient model for high-volume tasks	Agents built on Gemini use A2A to coordinate
Gemini 2.5 Pro	Advanced reasoning model for complex tasks	Higher-capability agents with A2A coordination
Agent Development Kit (ADK)	Google's framework for building agents	ADK agents are A2A-native by default
Vertex AI Agent Builder	Low-code/no-code agent construction	Built agents export A2A Agent Cards automatically
A2A Protocol	Agent-to-agent interoperability standard	The connective tissue between all of the above

Agent Development Kit (ADK) #

ADK is Google's official framework for building A2A-compliant agents. It provides:

• Native A2A server and client implementations
• Automatic Agent Card generation from agent definitions
• Built-in support for the full Task lifecycle
• Integration with Google's AI infrastructure (Gemini, Vertex AI)
• Python and Java SDKs (with TypeScript planned)

ADK agents can act as A2A servers (exposing their capabilities to other agents) or A2A clients (initiating tasks with other agents), or both simultaneously. This dual capability enables hub-and-spoke architectures where a central orchestration agent coordinates multiple specialized agents.

Vertex AI Integration #

A2A is deeply integrated into Vertex AI, Google's enterprise AI platform. Agents deployed via Vertex AI automatically receive:

• Managed A2A endpoints with automatic scaling
• IAM-based authentication for A2A connections
• Audit logging for all inter-agent communication
• Integration with Google's security and compliance frameworks

This enterprise polish distinguishes A2A from academic or research-oriented protocols. Google is positioning A2A as the standard for production enterprise deployments, not just experimental projects.

---

Building With A2A: The Agent Development Kit #

Google's Agent Development Kit provides the reference implementation for A2A, with Python and Java SDKs that handle protocol details and let developers focus on agent logic. For teams evaluating A2A, ADK is the practical starting point.

ADK Architecture #

ADK follows a modular architecture with clear separation between agent logic and protocol handling:

Component	Responsibility	Developer Touchpoints
Agent	Core logic, reasoning, tool use	Implement business logic, define tools
Session	Context management, memory	Configure persistence, set context window
Service	A2A protocol server	Define endpoints, authentication
Client	A2A protocol client	Initiate tasks, handle responses

Creating an A2A-Compatible Agent #

Building an ADK agent that exposes A2A capabilities follows this pattern:

1. Define agent tools — What the agent can do (query database, call API, etc.)
2. Specify input/output schemas — Type-safe interfaces for agent capabilities
3. Configure A2A service — HTTP endpoints, authentication, rate limiting
4. Deploy — ADK generates the Agent Card and exposes A2A endpoints

ADK handles the protocol implementation details: Agent Card generation, Task state management, message serialization, error handling, and streaming updates.

A2A Client Usage #

For agents that need to call other A2A agents, ADK provides a client library:

1. Discover — Fetch Agent Card from target agent's well-known endpoint
2. Negotiate — Check capabilities match the intended task
3. Create Task — Submit task with initial context and requirements
4. Handle Updates — Process streaming status updates and messages
5. Retrieve Result — Access final artifacts when task completes

The client supports both synchronous (wait for completion) and asynchronous (callback on update) patterns, fitting different orchestration architectures.

---

Implications for Production AI Infrastructure #

A2A represents a fundamental architectural shift in how production multi-agent systems are designed and deployed. For teams building enterprise AI infrastructure, the protocol changes what's possible and what best practices look like.

From Monolithic to Federated Agent Architectures #

Before A2A, enterprises typically built monolithic agents — single systems that attempted to handle too many responsibilities, or isolated agents that couldn't coordinate. A2A enables a federated model:

Approach	Structure	Scaling Characteristic
Monolithic	Single agent with all capabilities	Linear complexity growth
Isolated	Multiple independent agents	Coordination via human handoff
Federated (A2A)	Specialized agents with A2A coordination	Sub-linear complexity, composable

Federated architectures scale better. Each agent has a narrow scope that's easier to develop, test, and maintain. When new capabilities are needed, you add a new agent rather than modifying an existing one. A2A provides the wiring that makes this composition possible.

Enterprise Integration Patterns #

A2A supports several enterprise deployment patterns:

Hub-and-Spoke: A central orchestration agent (often custom-built) coordinates multiple specialized agents from vendors (Salesforce, ServiceNow, etc.). The hub agent maintains business logic for when to invoke which spoke.

Peer-to-Peer: Agents discover and negotiate directly without central coordination. Suitable for loosely coupled workflows where any agent might initiate collaboration.

Hierarchical: A tree structure where parent agents delegate to child agents, which may further delegate. Enables complex decomposition of enterprise workflows.

Security and Governance Considerations #

A2A's design addresses enterprise security requirements:

Concern	A2A Mechanism	Enterprise Implication
Authentication	OAuth 2.0, mutual TLS	Integrates with existing IAM
Authorization	Agent Card capability scoping	Principle of least privilege
Audit	Task lifecycle logging	Compliance trail for all agent actions
Isolation	Per-task context boundaries	Containment of sensitive operations

The protocol doesn't mandate specific implementations for these — it provides the hooks for enterprises to apply their existing security frameworks.

---

Limitations and Open Questions #

A2A is a v1.0 specification, and the launch-day documentation reveals both intentional scope constraints and areas where the protocol will need to evolve. Understanding these helps set appropriate adoption timelines.

Current Protocol Limitations #

Limitation	Status	Impact
Discovery beyond well-known URIs	Not specified	Requires custom directories or registries
Agent reputation/trust scoring	Out of scope	Enterprises must implement their own trust frameworks
Payment/billing for agent services	Not defined	Commercial agent marketplaces need extensions
Cross-domain authentication	OAuth 2.0 only	SAML, custom auth require implementation work
Real-time constraints	Not specified	Latency-sensitive applications need custom handling

The MCP Integration Question #

Google has not yet specified how A2A agents should use MCP tools, or whether ADK will support MCP natively. This matters because most production agents need both:

• MCP to connect to their internal tools (databases, APIs, file systems)
• A2A to coordinate with other agents

The most likely outcome is converged implementations where agent frameworks support both protocols. LangChain and CrewAI's involvement in the A2A launch suggests this convergence is already underway — their ecosystems have strong MCP support and will likely bridge both protocols.

Ecosystem Maturity Timeline #

While 50+ partners committed at launch, actual A2A implementations will roll out over months:

• Immediate: Reference implementations from Google (ADK), LangChain, CrewAI
• Q2 2025: Major platform integrations (Salesforce, ServiceNow beta programs)
• H2 2025: Production enterprise deployments from launch partners
• 2026: Broad ecosystem adoption if initial deployments succeed

---

Frequently Asked Questions #

Q: What is the Google A2A protocol? #

A: The Agent2Agent (A2A) protocol is an open specification from Google that standardizes how autonomous AI agents discover each other, negotiate capabilities, and collaborate on tasks. A2A enables agents from different vendors to work together through a common communication format based on HTTP and JSON.

Q: How is A2A different from MCP? #

A: A2A and MCP operate at different layers of the AI stack. MCP connects models to tools and data sources — it's how a single AI assistant accesses external capabilities. A2A connects agents to other agents — it's how multiple autonomous agents coordinate on shared tasks. Most production deployments will use both: MCP for tool access, A2A for inter-agent communication.

Q: What are Agent Cards in A2A? #

A: Agent Cards are JSON metadata documents that agents publish to describe their capabilities, endpoints, authentication requirements, and supported operations. Published at /.well-known/agent.json, Agent Cards enable dynamic discovery — any agent can fetch another agent's Card to determine if collaboration is possible.

Q: Which companies support A2A at launch? #

A: Google announced 50+ launch partners including Salesforce, SAP, ServiceNow, Atlassian, Workday, Box, Cohere, Intuit, LangChain, MongoDB, PayPal, UKG, Accenture, BCG, Deloitte, KPMG, McKinsey, PwC, and Wipro. The partner list spans CRM platforms, enterprise systems, AI infrastructure providers, and consulting firms.

Q: How does A2A handle authentication? #

A: A2A specifies OAuth 2.0 as the standard authentication mechanism, with support for mutual TLS for enterprise deployments. Individual agents can require specific scopes or credentials, and the protocol includes hooks for custom authentication extensions.

Q: Can A2A agents work with MCP tools? #

A: Yes — A2A and MCP are complementary. An A2A agent typically uses MCP to connect to its internal tools (databases, APIs, file systems), then uses A2A to coordinate with other agents. The protocols operate at different layers and don't conflict.

Q: What is the Agent Development Kit (ADK)? #

A: ADK is Google's official framework for building A2A-compliant agents. Available in Python and Java, ADK provides native A2A server and client implementations, automatic Agent Card generation, and integration with Google's AI infrastructure including Gemini and Vertex AI.

Q: Is A2A a Google proprietary protocol? #

A: No — A2A is an open specification hosted on GitHub with open source reference implementations. While Google is the primary author and promoter, the protocol is designed to be vendor-neutral and the specification is published for community contribution.

Q: How does A2A handle long-running tasks? #

A: A2A supports streaming updates via Server-Sent Events (SSE), allowing agents to report progress on long-running tasks in real time. The Task object includes states like working and input-required that support extended multi-turn interactions.

Q: When will A2A be production-ready? #

A: A2A is released as a v1.0 specification today, with reference implementations available immediately. Google and launch partners are targeting production deployments in the second half of 2025. Enterprises should evaluate now, with production adoption timelines dependent on specific partner platform integrations.

Q: Can A2A agents request human input? #

A: Yes — A2A's input-required Task state explicitly supports human-in-the-loop scenarios. When an agent needs clarification or approval, it transitions to this state and sends a message requesting input. The initiating agent (or a human monitoring it) can provide the needed information to continue.

Q: What deployment patterns does A2A support? #

A: A2A supports multiple enterprise deployment patterns: hub-and-spoke (central orchestrator with specialized agents), peer-to-peer (direct agent negotiation), and hierarchical (nested delegation). The protocol is flexible enough to support various organizational structures.

---

Build Multi-Agent Systems That Actually Work #

A2A is the protocol layer that makes enterprise multi-agent coordination possible. But protocol adoption alone doesn't deliver business outcomes — you need the right architecture, the right implementation strategy, and the right integration approach.

That's where I come in.

I help founders, operators, and engineering teams ship AI automation that actually works:

• Multi-agent architecture design — Hub-and-spoke, federated, or hierarchical patterns matched to your use case
• A2A and MCP integration — Connecting Google's agent ecosystem with Anthropic's tool ecosystem
• Custom agent development — Production-grade agents using ADK, LangChain, or custom frameworks
• Enterprise integration — Connecting agents to your existing systems (Salesforce, ServiceNow, ERP, etc.)

Recent focus: With Google A2A launching today as an open protocol specification and MCP already established, the agent interoperability landscape is stabilizing. Google is working with partners toward a production-ready version later this year — the teams that evaluate and plan now will have a significant advantage as the ecosystem matures.

If you're evaluating A2A for your multi-agent infrastructure — or you have workflows that should be automated but aren't yet — let's talk.

Book a 30-minute AI automation strategy call →

---

Related posts you might find useful:

• Anthropic's Model Context Protocol Launches — The foundation of tool-agent connectivity
• OpenAI's Responses API and Agents SDK — OpenAI's competing approach to agent infrastructure
• Google Antigravity Multi-Agent Blueprint — Advanced patterns for coordinating multiple AI agents

---

William Spurlock is an AI automation engineer and custom web designer who helps founders and teams ship production-grade AI workflows and premium digital experiences. Follow @williamspurlock on X for daily insights on AI agents, A2A, MCP, and modern web architecture.