What happened to Google's A2A?

Remember when Google announced the Agent2Agent (A2A) protocol back in April 2025? It was supposed to be the universal language for AI agents - a groundbreaking open standard that would enable seamless communication between agents across different platforms and vendors. Fast forward to September 2025, and A2A seems to have quietly faded into the background while the Model Context Protocol (MCP) has become the de facto standard. What happened?

The Promise of A2A

Google’s A2A protocol launched with ambitious goals. It promised to break down silos in AI development by providing a common language for agents to:

• Discover each other’s capabilities
• Securely exchange information
• Coordinate complex multi-agent tasks
• Enable true interoperability across vendors

The technical architecture looked solid. A2A provided a comprehensive specification for agent discovery, capability negotiation, and secure message passing. When Google donated it to the Linux Foundation in June 2025, forming the Agent2Agent project, it seemed like the protocol was on track to become the industry standard.

The July 2025 Upgrade

Google announced version 0.3 on July 31, 2025, bringing significant improvements:

• gRPC support for high-performance communication
• Enhanced security with signed security cards
• Extended Python SDK for easier client-side implementation
• Enterprise-grade features for orchestration at scale

The announcement highlighted impressive ecosystem growth, with over 150 organizations supporting A2A, including major partners like Adobe, ServiceNow, S&P Global, and Twilio. Google showcased real enterprise use cases like Tyson Foods and Gordon Food Service using A2A agents to share product data and optimize their supply chains. They also introduced comprehensive developer tools: native support in the Agent Development Kit (ADK), flexible deployment options via Agent Engine, Cloud Run, and GKE, plus integration with Agentspace and the AI Agent Marketplace.

These were all the right moves for enterprise adoption. Google Cloud was clearly positioning A2A as the enterprise solution for multi-agent systems. So why didn’t it take off despite this momentum?

Meanwhile, in the MCP Ecosystem…

While Google was building enterprise features, the Model Context Protocol was gaining grassroots momentum. As I’ve covered in my extensive MCP series, the protocol took a fundamentally different approach:

1. Developer-first philosophy: While A2A focused on enterprise orchestration, MCP prioritized individual developer experience. For indie developers, A2A was practically inaccessible - you needed to understand complex agent orchestration, security cards, and multi-agent communication patterns just to get started. My post on building a Hello World MCP server shows how MCP lets you get started in minutes, not hours.

2. Pragmatic simplicity: A2A’s comprehensive specification was powerful but complex. It didn’t cover the simple needs that most developers actually have - like reading files, making API calls, or running scripts. MCP chose simplicity and immediate utility. As I explored in MCP Inspector vs MCP Tools, the ecosystem provides intuitive tools that make debugging and development straightforward.

3. Real-world focus: While A2A emphasized agent-to-agent communication, MCP focused on the more immediate need: connecting AI to existing tools and services. My posts on building filesystem servers in Go and creating app openers for macOS show practical applications developers could build today.

4. Evolution over revolution: MCP evolved rapidly based on community feedback. When SSE proved limiting, they moved to Streamable HTTP. When developers needed interactive workflows, they introduced Elicitations. Each change addressed real developer pain points.

The Community Factor

Perhaps the biggest difference was community adoption. While A2A had Google’s backing, MCP had Claude’s integration from day one. This meant developers could immediately test their MCP servers with a production-ready AI assistant.

The MCP community also benefited from clear, practical documentation and a growing ecosystem of examples. My post on project scaffolding with MCP tools shows how the ecosystem evolved to support rapid development.

Where A2A Went Wrong

Looking back, A2A’s challenges weren’t technical - they were strategic:

1. Over-engineering: A2A tried to solve every possible agent communication scenario from day one. Despite the impressive list of partners in Google’s July announcement - Adobe, ServiceNow, S&P Global, Twilio - most developers needed simpler solutions. An indie developer wanting to build a simple tool integration had to wade through concepts like agent discovery, capability negotiation, and security cards - overkill for basic needs. MCP started simple and evolved.

2. Top-down vs bottom-up: Google’s enterprise-first approach meant individual developers had little reason to experiment with A2A. While Google was building Agentspace and AI Agent Marketplace for enterprise distribution, MCP’s integration with consumer AI tools gave every developer a reason to try it immediately.

3. Timing: By the time A2A reached v0.3 with practical features like the Agent Development Kit (ADK) integration, MCP had already captured developer mindshare. The network effects were too strong to overcome.

4. Complexity without immediate value: A2A’s multi-agent orchestration capabilities and deployment options (Agent Engine, Cloud Run, GKE) were impressive but solved problems most developers didn’t have yet. MCP solved the immediate problem of connecting AI to tools.

The Indie Developer Experience

Perhaps nothing illustrates the difference better than the indie developer experience. With A2A, a solo developer couldn’t just spin up a quick experiment over the weekend. You needed to understand:

• Complex agent orchestration patterns
• Security card implementation
• Multi-agent communication protocols
• Enterprise deployment strategies

Meanwhile, with MCP, that same developer could build and deploy a useful tool in an afternoon. Want to give your AI access to your file system? Twenty lines of code. Need to integrate with an API? Even simpler. A2A was solving problems indie developers didn’t have, while ignoring the simple integrations they desperately needed.

The Startup Angle

As I discussed in MCP Startups, the protocol’s simplicity and immediate utility created opportunities for entrepreneurs. A2A’s complexity and enterprise focus made it harder for startups to build businesses around it. The ecosystem matters as much as the technology.

What Can We Learn?

The A2A vs MCP story offers valuable lessons for protocol design:

1. Start simple, evolve based on usage: MCP’s incremental approach beat A2A’s comprehensive specification.

2. Developer experience trumps features: Having more capabilities doesn’t matter if developers can’t easily use them.

3. Immediate utility drives adoption: MCP worked with existing AI assistants from day one. A2A required building new infrastructure.

4. Community beats corporate backing: Google’s resources couldn’t compete with an engaged developer community.

5. Timing matters: Being first with a working solution beats being best with a future solution.

The Current State

As of September 2025, A2A isn’t technically dead - still exists, and the specification is still available. But development has slowed significantly, and most of the AI agent ecosystem has consolidated around MCP.

Google Cloud still supports A2A for some enterprise customers, but even they’ve started adding MCP compatibility to their AI services. It’s a tacit acknowledgment that the developer community has chosen.

Looking Forward

The A2A story reminds us that in the world of developer tools and protocols, adoption beats architecture. Google built what might have been a technically superior protocol, but MCP built what developers actually wanted to use.

For those interested in the winning approach, check out my comprehensive guide to MCP’s advanced capabilities. The protocol continues to evolve.

The irony is that A2A’s vision of interoperable, communicating agents is still the future - it’s just being built on MCP instead. Sometimes the best protocol isn’t the one with the most features or the biggest corporate backer. Sometimes it’s the one that developers actually want to use.

_{This article was proofread and edited with AI assistance.}