The recent announcement of Google’s A2A (Agent-to-Agent) protocol in April 2025 has generated significant buzz in the tech community, particularly or even entirely concerning its association with AI agents. However, while the protocol’s potential for AI agents and their interaction is a wider ecosystem is potentially very relevant, it is essential to recognize A2A’s potential value for broader application and data integration purposes. And the fact that the protocol itself has no specific AI characteristics.

A2A is an open standard designed to enable communication and collaboration between AI agents from various vendors and frameworks. The protocol facilitates capability discovery, task management, secure collaboration, and supports diverse data types, promoting seamless multi-agent workflows across enterprise systems. Supported by over 50 partners, including prominent tech and SaaS vendors and service providers such as Atlassian, Box, Cohere, Intuit, Langchain, MongoDB, PayPal, Salesforce, Oracle, SAP, and ServiceNow, A2A’s robust backing underscores its significance.

It is hailed by some as the missing link in an AI agent powered ecosysteem and a breakthrough of almost momentous proportions. Together with MCP, A2A will change the face of software industry.

Some of the early articles seem based on a superficial read through of Google’s announcements. And suggest a strong AI specific focus in the A2A specification.

Moving Beyond AI Agent Hype

Despite the prevalent emphasis on A2A’s association with AI agents, it is crucial to look beyond this apparent focus.

While I believe that agent to agent communication or better still: agent with agent collaboration, will benefit from a protocol that goes beyond today’s standards for REST and GraphQL, SSE, OpenAI and AsyncAPI , I do not see the AI (or even LLM) specific elements in A2A. Which increases the potential of A2A tremendously: it can be leveraged by “conventional” programs. Any application can engage in interactions with an A2A server — similar to interactions with a REST API but potentially richer (asynchronous, long running multi-step-conversations, streaming). And any application can publish A2A style services, similar to REST or GraphQL API and potentially richer.

Consider A2A as the overarching standard for programmatic interactions that has long been sought. Web Services (UDDI, WSDL, SOAP, XML) never quite achieved their full potential, and a true standard for an API directory never materialized. OpenAPI, REST, and JSON, while useful, do not encompass the complete package. A2A could fill this void, offering a richer interaction protocol that benefits conventional programs and AI agents alike.

The Path Forward

To truly appreciate A2A’s capabilities, it is essential to explore and experiment with the protocol. By trying out A2A, technical architects can witness its evolution and assess its applicability for various integration scenarios. Be mindful, however, not to be swayed by the noise surrounding A2A’s association with AI agents. The protocol’s broad applicability makes it a valuable foundation for regular application integration and data exchange.

AI as enabler for the rise of A2A

If an assumed strong association with AI agents is going to help push A2A forward and turn it in a widely embraced protocol that all of us in programmatic interactions, application integration , data exchange and AI agentic collaboration can benefit from, I will applaud it and happily join in. Hybrid solutions that combine traditional programs (services, client application) with AI agents through A2A — and perhaps also eventually use A2A as a foundation for the traditional interactions — are on the horizon.

If and when a few important (somewhat) lacking aspects are properly taken care of. Such as security — authentication, authorization, encryption. Note: A2A supports enterprise-grade authentication like API keys, OAuth, and bearer tokens. Google has emphasized that A2A is an open protocol, suggesting that the community will play a significant role in its development and the addition of new features, including security enhancements.

A Closer look at A2A

A nice concrete, handson introduction to A2A can be found in this article: Getting Started with Google A2A: A Hands-on Tutorial for the Agent2Agent Protocol . Note: this article describes AI powered agents as the participants in the A2A interactions. That is a great example. However, realize that “regular, non LLM” Python, JavaScript, Java, .NET etc. programs can take part just as easily.

Some interesting concepts of A2A are discussed in this article:

• Agent Discovery (Agent Card — similar to OpenAPI / WSDL)
• Task Lifecyle (including submit, enquire for status, subscribe)
• Rich Content and Parts — text, file, data, “forms”
• Streaming (SSE)
• Negotiation (not actually part in A2A but suggested and somewhat facilitated — largely to be implemented in client and server, not in the protocol or the messages)

Conclusion

In conclusion, while A2A’s connection to AI agents is noteworthy, its broader potential for application and data integration should not be overlooked. Technical architects are encouraged to explore A2A, consider its application in various integration scenarios, and contribute to its ongoing development. By embracing A2A, we can pave the way for a more unified and efficient approach to programmatic interactions, benefiting both conventional and AI-powered programs.