In The Loop Episode 12 | Google Agent2Agent (A2A): The Future Of AI Agent Protocols Or A Flop?

You're scrolling through your phone at 6 AM when you get a ping: your fridge has been restocked, your flight has been rerouted, there's a taxi waiting when you land, and your tax rebate has already been filed and processed. All while you were asleep. No apps, no browser tabs—just a single AI agent quietly managing your entire life.

Today’s episode is all about the plumbing that could make this vision a reality. Google calls it the Agent2Agent Protocol (A2A).

Think of it as a shared language between your personal agent, your company’s HR agent, and even the local council’s services agent. If it works, individuals, companies, and even governments could be run—and collaboration managed—entirely by AI agents.

In this episode, we’re exploring what this means for you and how it could all come together. We'll dig into the technical underpinnings, as well as the criticism Google has faced for taking this approach.

This is In The Loop with Jack Houghton. I hope you enjoy the show.

‍

‍

Multi-agent systems, MCP, A2A tied together

The reason I wanted to talk about this today is that it ties together a lot of themes I’ve touched on over the last few episodes. I’ve said it before, but I really believe multi-agent systems are the future—and 2025 is the year they’re going to take a major leap into the spotlight.

I covered this back in Episode 6. Listen on Spotify, Apple Podcast, or YouTube.

As I explained, it’s not easy to get a whole system of AI agents to work at scale. Without proper coordination, things can spiral into chaos—or even total system failure—especially if there’s a bad actor or a hacker disrupting the network.

Then there’s the scalability issue: how many agents are we talking about? Hundreds of thousands? Millions? Billions? The scale introduces a whole new layer of complexity. It reminds me of the early days of the internet, when people were still trying to wrap their heads around the idea of millions of users coming online and interacting through this new digital space.

I’ve also discussed the challenges around user interface design for human-agent interactions. If you're not deep in the tech world, you might overlook the UI layer, but it’s crucial. It’s something we take for granted now.

Back in Episode 3 (listen on Spotify, Apple Podcast, or YouTube), I talked about how Apple revolutionized personal computing by making user interfaces intuitive—and that same kind of leap is needed for AI agents.

Google’s new protocol is a bold attempt to solve many of the challenges I’ve broken down throughout this series. Go back and listen to those episodes—they’re still super relevant and go into much more detail than I’ll get into today.

‍

‍

How does A2A work?

So why do I think this protocol could be a big deal for the future of AI agents? At its core, A2A is trying to address the multi-agent question—something a lot of people misunderstand. Many assume one agent equals one entity or that multiple agents means multiple standalone bots. But in reality, what appears to be one agent might actually be a whole system of agents working together behind a single interface.

Solving this kind of complexity is key, especially for tech companies. Take Mindset AI: we work with companies to embed AI agents into their products quickly. One client might use an agent to handle web searches, another to run database queries, and another for calculations. Each agent is specialized and equipped with tools it can access on demand to do its job well. And just to clarify: when I say “tool,” I mean an integration—something I’ll explain more in a moment.

The big issue here is that there’s no consistent standard. Company A’s agent system might struggle to interoperate with Company B’s. Several frameworks are trying to fix this, but there’s still no open standard. These protocols are crucial for collaboration across ecosystems because fragmentation slows down innovation. Every new agent you create multiplies the complexity of the system.

That’s where Google’s Agent2Agent Protocol comes in. It aims to standardize how agents communicate, regardless of how they’re built. Think of it as a common language and rulebook for agents to interact, especially at the user interface level. The goal is interoperability: any agent should be able to discover and talk to any other agent, just like a browser can talk to any website via HTTPS. By solving this communication bottleneck, Google hopes to enable a world where multi-agent systems actually function effectively at scale.

‍

What’s the difference between MCP and A2A?

Now, many people are asking: will this replace the Model Context Protocol (MCP)? I covered MCP in Episode 8—listen on Spotify, Apple Podcast, or YouTube.

MCP is aimed more at helping agents access external integrations—tools—within their own environment. For example, one agent might use a flight search tool from Booking.com or fetch weather data via a BBC Weather integration. Those platforms need to expose those tools to be usable by other agents, and MCP helps make that possible. It makes it easy for developers to build agents that can access those services—and for service providers to make their tools available to agents.

In that sense, Google’s A2A protocol is designed to sit above MCP. While MCP is about letting agents interact with services like Booking.com or BBC Weather, A2A is about enabling agents to communicate with each other—across companies, products, and platforms.

‍

‍

The key principles of the A2A protocol

Let’s zoom out and look at the big picture for agent-to-agent protocols like the one Google just released.

Say you want to plan a trip—from Manchester to New York to Hawaii. Imagine having a personal AI assistant on your phone. With agent-to-agent protocols, your assistant can talk to a travel orchestrator agent, who then communicates with a flight agent to find and book flights, a hotel agent to reserve rooms, and a rental car agent to arrange transportation. Each of these agents would represent an honest company, platform, or website—each with its own agents published and available.

‍

Orchestrator agent

Without a shared agent-to-agent protocol, this system quickly breaks down. Each company’s agent might be built differently: different LLMs, tools, and data setups. The orchestrator has to coordinate all of that and deliver a smooth result: flight confirmed, hotel booked, car reserved. But if they can't communicate properly, the whole process can fail.

That’s where a shared protocol comes in. Google's Agent2Agent standard makes this possible by enforcing a common set of rules. At the core of it: JSON.

‍

JSON

JSON is a lightweight, universal format for structuring and exchanging data. Every modern programming language—Python, JavaScript, Go, Java, Swift—understands JSON. Agents don’t need to agree on languages, just on how to package information. So instead of reinventing the wheel, Google’s protocol aligns with how MCP works too—they’re compatible.

This is the kind of infrastructure moment that feels like the early days of the internet—like when HTTPS or SMTP became standards. These protocols could be just as foundational. But here’s the catch: protocols only matter if people adopt them. Nobody gets paid to use them. It’s a collective decision by builders, companies, developers, and platforms to play by the same rules for the sake of interoperability.

‍

Agent cards

Now, JSON is just one part of the protocol. Another key element is the concept of agent cards. Agent cards are critical for multi-agent systems. Every message between agents must include a certain context: who the user is, what system is involved, the agent’s role—all packaged into the agent card and formatted in JSON.

So when one agent connects to another, it receives that agent’s card. That might include the agent’s name (e.g., "Flight Agent"), a description ("searches and books flights"), and version info (like "v0.0112"). It’s how agents introduce themselves and explain what they do—in a structured, machine-readable format.

That agent card also includes a URL—the endpoint where the agent lives—plus a list of skills. These are the specific tasks the agent can perform, like searching for flights or booking them. And this is what makes agent discovery possible.

If one agent needs help from another, it can use the card to figure out which agent is best suited for the task. It’s like an agent directory, and the skills section tells you exactly what each agent can do.

But it’s not just about functionality—these cards also influence how the user interface works. They play a role in shaping how agents collaborate with humans. They inform the UI, showing the user which agents are available, what they’re capable of, and what actions they’ll take. So when you ask a question, your assistant might respond with something like: “I’m checking with agents A, B, D, E, and F”—and behind the scenes, it’s using those agent cards to do it.

This becomes part of the overall experience—surfacing agent capabilities and setting user expectations through the interface. So these cards aren’t just metadata; they’re a key layer in making multi-agent systems usable and understandable.

So, with all that in place, what does this actually mean for you?

‍

‍

What does A2A mean for you—and what could go wrong?

Let’s start with the big idea: a true personal assistant agent.

Imagine an agent on your phone that just knows what you need. It’s aware of what you usually buy—oat milk, cat food, your Sky Sports subscription—and you can just say:

“Restock the fridge before Friday; I’m back from holiday then.”

It takes care of everything: contacts the supermarket agent, attaches your loyalty data, checks your reward points, confirms the purchase, gives you a price and delivery window, and checks your calendar to avoid any clashes. You don’t touch a thing.

Now, stretch that idea beyond shopping.

Consider how much bureaucracy could be eliminated if this worked across all government services. It won’t happen overnight—governments are notoriously slow to modernize, especially with personal data involved—but the potential is huge.

You could renew a license, and the license agent would check your identity with a citizen ID agent, verify fines with the traffic agent, and grab your eyesight certificate from a health agent. No waiting weeks. No paperwork. No counters.

That’s the promise. But...

‍

1. It can go dark—fast

There’s a risk that’s easy to overlook: once these agents connect and scale, the systems they build can start making decisions that humans don’t fully understand.

One of my favorite examples comes from Kai-Fu Lee’s AI 2041, where a young girl in India is denied insurance—not because of anything she did, but because she was linked to someone an AI system flagged as high risk. Just knowing that person was enough.

When AI agents pull together data from across your digital life—from relationships to behavior to spending—and make automated decisions based on it, it becomes almost impossible to audit. You might never even know what flagged you.

And if you look at something like U.S. health insurance, where rejections are profitable, you start to see the problem. If AI agents are optimized for outcomes like profit, not fairness, they’ll simply do what they’re designed to do—and the human impact could be brutal.

‍

2. Google's A2A protocol is trying to do too much

On a technical level, the protocol Google’s proposing is incredibly ambitious—and that’s part of the problem.

Instead of just helping one agent talk to another, it tries to solve everything at once: discovery, capability sharing, long-running task handling, retries, error flows, even UI updates. It’s a lot.

For developers, this isn’t something you can casually plug in. You have to understand the entire architecture, implement multiple moving parts, and follow strict formatting rules—just to get a basic interaction working.

Compare that to Anthropic’s Model Context Protocol, which took off because it was so simple to use. You could run a basic test in a few lines of code, see immediate results, and iterate fast. That kind of simplicity is why it went viral.

Even Dharmesh Shah, CTO at HubSpot, called Google’s protocol “too much,” suggesting it feels more like an enterprise product than a foundation for an open, flexible agent ecosystem.

‍

3. It doesn’t scale—yet

The agent-to-agent protocol works well in small, trusted groups. Like a few teams in the same company. Everyone knows each other. They can call if something breaks.

But what happens when there are thousands—or millions—of agents built by different teams across different companies, even different countries?

The current discovery model is: each agent has a URL, like

agent.travelcompany.com

If you know the URL, you can ask what it does, and it replies with a little capability card. That’s fine on a small scale.

But what if you add a new agent that needs to find 30 others? Or if millions of agents are constantly trying to discover and message each other every second? That’s chaos.

There’s no shared directory. No index. No universal marketplace. No real infrastructure for agent discovery at scale. And sure—maybe Google or another big player will try to build that. But if they do, you can bet they’ll try to monetize every layer of it.

And here’s the final kicker: Google hasn’t convinced OpenAI, Anthropic, or Hugging Face to sign on. Without the major model providers, it’s hard to see this becoming the standard. So, as I said, it’s not a clear winner.

‍

‍

Closing thoughts

So, where does this leave us? To summarize, Google’s Agent2Agent protocol is an attempt to establish the rules for how agents can communicate in the future.

At first glance, it seems that Google is trying to set the rules in a positive way for separate companies across multiple countries and locations that have no connection to each other. But actually, I think they're just trying to go after big enterprises in safe environments on a small scale.

So, although it paints a very clear picture that every person, company, and government is going to have agents representing them, it's a cumbersome protocol. The discovery model isn't built to scale, and right now, it's not accepted by a single big model provider.

I have no idea where this is going to go. We will be testing it at Mindset AI soon, but as I said, it's cumbersome, so it's not something you'll want to jump into over the weekend. This is an ever-evolving space where Mindset AI will be experimenting. If you follow the In The Loop podcast or Mindset AI’s journey, you'll be the first to hear what we think of the future of this protocol and multi-agent systems in general.

That's it for today. Please share this with someone who might enjoy this content. Subscribe to the podcast, rate it, share it in a Slack channel for people to learn about AI.

‍