I still see a lot of the current AI conversation focused on which model, which platform, or which vendor an organisation should choose, which of course matters. As AI agents become more useful, a different question starts to appear: what happens when those agents need to work together across different platforms?
That is where Agent-to-Agent, or A2A, becomes interesting. Not because it solves everything but because it points toward a more realistic enterprise future, where organisations do not have one or more AI agents, in a single platform, doing everything. They have multiple agents, built for different purposes, running in different environments, handing work off to each other in a controlled way.
What is it?
At a foundational level, A2A is a protocol that allows AI agents to communicate with each other. More specifically, it is intended to help independent agents, built with different tools, frameworks, or vendors, discover one another, exchange information, and coordinate work. The official A2A documentation describes it as an open standard for interoperability between independent agent systems, including systems built across different frameworks, languages, and vendors.
That may sound technical, and under the covers it is, but the business idea is straightforward. Instead of building one large agent that tries to do everything, an organisation may have several purpose-specific agents, in different environments from different vendors:
- one that understands HR policy
- one that works with finance data
- one that supports customer service workflows
- one that sits inside Microsoft Copilot Studio
- one that runs in a Google environment
- one that wraps a custom internal application
A2A is about creating a more standard way for those agents to interact. One important part of this is the “Agent Card.” In practical terms, this is a description of the agent: what it does, where it can be reached, what capabilities it has, and how other agents should interact with it.
I recently tested this pattern in a small experiment: to get a Microsoft Copilot Studio agent to call a Google Agent Platform Studio agent over A2A. It was not smooth. Copilot Studio had trouble finding the Agent Card, even though I could see it directly in a browser. I then manually configured the Google agent inside Copilot Studio and could see the call going across, but then ran into an unexpected API key issue. So, maybe not a polished enterprise pattern yet (or reasonably so, it’s my problem, not the environments problem).
The technology is there, it’s real and the pieces are emerging. That makes this less of a science project and more of a signal.
What does it mean from a business perspective?
This is not just a developer integration topic. It has implications for AI strategy, architecture, governance, and adoption.
The future will probably be multi-agent and multi-vendor. Most organisations already run across multiple technology ecosystems. Microsoft, Google, Salesforce, ServiceNow, custom apps, legacy systems, data platforms, and sector-specific tools all coexist. AI agents will likely follow the same pattern, being closer to the data that they use to function.
A2A shifts the discussion from “which platform wins?” to “how do the parts work together?” That is a better enterprise question. Organisations do not need every agent to live in the same environment. They need clear integration patterns, security, accountability, and operational control and insights.
Purpose-specific agents become more practical. A finance agent does not need to be the same as an HR agent. A customer service agent does not need to live in the same stack as an engineering support agent. A2A makes it easier to imagine agents running where they make the most sense.
Governance has to travel across the handoff. If one agent passes work to another, who owns the outcome? Which permissions apply? What gets logged? What happens if the second agent makes a poor recommendation or calls the wrong tool? These are business questions as much as technical ones.
A2A does not replace good architecture. It is not a reason to connect everything to everything. Microsoft’s multi-agent architecture guidance is sensible here: use native platform orchestration where possible, use MCP for secure access to tools and data, and use A2A for cross-platform agent integration where interoperability is needed.
Risk management? - Vendor lock-in changes shape. A2A may reduce some forms of lock-in by allowing agents from different vendors to work together. But it does not eliminate lock-in completely. Organisations will still depend on platform capabilities, security models, governance tooling, developer experience, monitoring, pricing, vendor maturity and possibly labour lock-in.
Operational maturity matters. It is one thing to get two agents talking in a test environment. It is another to run that pattern safely in a regulated, public sector, or risk-aware organisation. The gap between “it works” and “we can rely on it” is where most of the real work sits.
What do I do with it?
I would not suggest rushing into A2A because it sounds exciting, I would suggest putting it on the radar.
Start by mapping where agents are likely to appear in your organisation. Look across Microsoft 365, Copilot Studio, CRM, ERP, service management, data platforms, custom applications, and vendor products. The question is not just “where are we using AI?” It is “where might agents need to interact?”
Separate tools, agents, and workflows. A tool performs a function. An agent reasons or acts toward a goal. A workflow connects steps - possibly uses, or is used by an agent. Keeping those concepts separate helps avoid overbuilding and over connecting.
Look for bounded use cases first. Good early candidates are narrow, low-risk, and easy to observe. For example, one agent gathering structured information and another agent drafting a response for human review. Avoid starting with high-consequence, fully automated decisions. If the consequence is high, human review, stronger controls, logging, and clear ownership become much more important.
Pay attention to identity and permissions early. Do not treat authentication as something to clean up later. Agent-to-agent communication without a clear identity and permission model will become messy very quickly (more to com me on that next week as I work on it).
Ask vendors better questions. When reviewing AI platforms, ask how they support agent interoperability, authentication, logging, governance, and cross-platform handoffs. The quality of those answers will matter more as agent adoption grows.
Treat this as architecture, not just experimentation. Small experiments are useful. They reveal the friction. But the business value comes when those lessons are translated into standards, patterns, governance, and repeatable delivery. Get A2A into the hands of your Enterprise and Solution Architects.
A2A is still early, and the practical implementation details do not seem trivial, that’s why it is worth paying attention to now. The organisations that benefit from agentic AI will not just be the ones that build clever agents. They will be the ones that understand how agents fit into real workflows, real systems, real accountability structures, and real organisational constraints.
For me, the interesting part is not just that one agent can call another agent (although that does scratch a technical itch). It’s also what means for enterprise and solution architecture, governance, and adoption when AI starts to move beyond isolated assistants and into connected work.