Yes! Although I've created a number of open-source A2A packages (
https://github.com/a2anet) so I'm a little biased. For a more objective view, I keep an eye on the A2A SDK's monthly downloads (
https://pypistats.org/packages/a2a-sdk). They're at ~10.9M compared to MCP's 257M, so MCP is downloaded about 24x more than A2A.
A2A is much more popular in enterprise than startups. All of the cloud providers and enterprise orchestration platforms (e.g. Gemini Enterprise, AgentForce, watsonx Orchestrate, SAP Joule) support it. People in enterprise typically make their agents A2A compatible so they can use them on these platforms, share them with other teams, etc.
The startups that I have seen use A2A typically use it for at least one of the following reasons:
1. To standardise their API endpoints. A2A specifies how to send and receive text, data, and files, so they can write client code once and reuse it with different agent frameworks.
2. To standardise agent cataloging. A2A introduces the concept of an Agent Card which contains information about the agent like its name, description, skills, accepted input, etc.
3. For long-running tasks. A2A was explicitly designed for long-running tasks and supports polling, streaming, and webhooks.
Confusingly, none of the above use cases are necessarily agent-to-agent. Turns out to standardise agent-to-agent communication, discovery, and authentication, you need to standardise agent communication, discovery, and authentication.
The A2A protocol is a good (not perfect) solution for agent-to-agent communication and it will continue to grow. How much it grows depends on how agents evolve. At the moment companies are building MCP servers for coding agents and chatbots, but not agents themselves. I believe that companies will eventually start building agents to control and improve their customer's experience. If they do this, A2A is the natural choice because it solves all of the problems associated with discovering, connecting, and communicating with agents over the internet.