Picture a 62-year-old woman who needs a follow-up with her cardiologist.
Today, this is how it usually goes. She calls the clinic to find a slot. She calls her insurer to check coverage. She calls the diagnostic lab to book the blood test the doctor wants before the visit. Then she works out how to fit all three on the same morning.
Three calls. Three hold queues. Three times she explains who she is.
Now imagine she tells one assistant, “I need a cardiology follow-up before the end of the month,” and the assistant sorts out the rest.
That is the promise of AI agents talking to each other. It also raises a question most businesses haven’t thought about yet: how do agents built by different companies even speak the same language?
The problem: agents are islands
Over the past two years, companies have deployed AI agents for support, sales, scheduling and operations. Many work well.
But each one lives inside its own walls. The clinic’s agent is built on one stack. The insurer’s agent on another. The lab’s agent on a third. Each speaks its own dialect, with its own way of describing tasks and returning results.
If you want them to cooperate today, an engineer has to build a custom bridge for every pair. Three agents need three bridges. Thirty agents need hundreds.
We have seen this before. In the early days of the internet, computers couldn’t easily talk to each other until common standards arrived. Email worked because a Gmail user could write to someone on Outlook without either company building anything special.
Agents need something similar.
Enter A2A
A2A stands for Agent2Agent. It is an open protocol, introduced by Google in 2025 and now supported by a growing group of technology companies under the Linux Foundation. Its goal is simple: give AI agents a shared way to find each other, communicate and work together, no matter who built them.
You don’t need the technical detail to follow the idea. Three pieces matter.
1. A business card. Every agent can publish a short public description of itself: who it is, what it can do and how to reach it. In A2A this is called an Agent Card. Our patient’s assistant can read the clinic’s card and know that this agent handles appointments.
2. A task. One agent asks another to do something, such as “find a cardiology slot.” The task has a lifecycle. It can be accepted, in progress, waiting for more information, completed or failed. Real work isn’t one question and one answer. It is a conversation that can pause, ask a clarifying question and carry on.
3. A result. When the work is done, the agent hands back something concrete: a confirmed booking, a document, a decision.
There is one more idea that matters a lot, especially for doctors and anyone handling sensitive data. In A2A, agents are opaque to each other. The clinic’s agent doesn’t open up its internal systems, full schedules or patient records. It shares only what it chooses to share to get the job done. Each organisation keeps control of its own data and logic.
A2A is not the same as MCP
You may also hear about MCP, another emerging standard. The two are often confused, so here is the simplest way to separate them.
- MCP connects an agent to tools: a database, a calendar, a booking system.
- A2A connects an agent to other agents.
An agent uses MCP to do things inside its own world. It uses A2A to collaborate with agents outside it. A well-built system will likely use both.
The example, revisited
Let’s go back to our patient. This is an illustration, not a live deployment, but it shows how the pieces fit.
Her assistant reads the clinic’s Agent Card and sends a task: “Find a follow-up with the cardiologist, mornings preferred, before the 30th.”
The clinic’s agent checks availability and comes back with a question: “Dr. Rao has Tuesday at 10:30 or Thursday at 9:00. Is this a routine follow-up or related to a new symptom?” The task pauses until the assistant answers, because it already knows this is routine.
Next, the assistant asks the insurer’s agent whether the visit and the pre-visit tests are covered. The insurer’s agent confirms coverage and flags that one test needs pre-authorisation. It starts that process itself.
Then the lab’s agent is asked for a blood-test slot the morning before the Thursday visit. It offers 8:00 AM, fasting required.
Finally, the assistant brings it all back to the patient in one message: “You’re booked with Dr. Rao on Thursday at 9:00. Blood test at 8:00 AM the day before, please come fasting. Your insurer has approved both.”
She made no calls. She repeated nothing. And at no point did the clinic, insurer or lab expose their internal systems to each other. They exchanged only what the task needed.
Where it gets hard
This is the point where most articles stop. It shouldn’t be, because the hard questions are not about the protocol.
Trust. How does the clinic’s agent know the request really comes from the patient’s assistant and not from someone pretending to be it? Identity and authentication between agents is a serious engineering problem.
Permission. What is the patient’s agent allowed to share, and with whom? Her appointment history may be fine to share with the clinic. It may not be fine to share with the lab. Someone has to define and enforce those boundaries.
Accountability. If an agent books the wrong slot or shares the wrong detail, who is responsible? In healthcare and finance, this cannot be an afterthought.
Context. This is the one we think about most. A protocol lets agents talk. It does not make them understand. If the patient’s assistant doesn’t remember her preferences, her earlier tests or what she told it last month, then it will pass a poorly informed request to every agent it meets. A standard way of communicating doesn’t fix poor context. It just spreads it faster.
We saw the same thing in the airline example from our last article. An agent that sounds fluent but works with the wrong information produces a more articulate wrong answer. When many agents are involved, the damage compounds.
What this means for businesses
If agents become able to work with each other across company boundaries, a few things follow.
First, your business will be talking to other businesses’ agents, not only to customers. Procurement, scheduling, claims, onboarding and follow-ups are all candidates.
Second, being “agent-ready” will start to matter, the way having a website did. Can an outside agent discover what your business offers? Can it request something in a structured way? Can it get a reliable answer?
Third, the quality of each agent will depend less on the model behind it and more on three things we keep coming back to:
- Knowledge: does the agent have accurate, approved business information?
- Memory: does it remember the customer and what has already happened?
- Action: can it complete the task within clear limits, or hand over to a human when it should?
A2A gives agents a common language. Knowledge, memory and action decide whether anything useful is said in it.
Where ROVA AI fits
These are the problems we are working on at ROVA AI.
ROVA Cortex is our enterprise memory layer. It helps agents keep relevant context about customers and past interactions across conversations and channels, so each interaction doesn’t start from zero.
ROVA Knowledge Base helps businesses organise their documents, policies and FAQs so agents can retrieve reliable, approved information.
Combined with the right tools, an agent can know the business, remember the customer and complete the task. Agent-to-agent standards like A2A are a natural next step, because an agent with good context becomes much more valuable when it can work with other agents.
To be clear, this is an evolving area, and we are still learning. Making agents reliable inside one company is hard enough. Making them reliable between companies is harder. The standards are young, and real-world deployments will teach us a lot.
But the direction feels right.
The takeaway
For years, the question was whether AI could talk. Then it became whether AI could act. The next question is whether AI can collaborate, safely, across organisations, with the right context and clear boundaries.
Protocols like A2A make that possible. Good context makes it worthwhile.
And the patient at the start of this article? She just wants her appointment booked, her insurance sorted and her blood test on the right morning.
She doesn’t care how the agents talk to each other. She only cares that they get it right.
