🦸🏻#17: What is A2A and why is it – still! – underappreciated?

Remember the classic example of what we wish AI agents could do smoothly? “Book me a trip to New York next weekend. Prefer a direct flight, leave Friday afternoon, back Sunday evening. And find a hotel close to a good jazz bar.” The problem with that (besides becoming a cliché) is AI agents still struggle to understand your full intent, plan across multiple steps, and act reliably across tools – all without constant hand-holding. Each step (parsing the task, finding options, making tradeoffs, booking) works okay in isolation, but stitching it all together smoothly and safely? That’s still brittle and error-prone. Most agents today operate in silos, each locked into its own ecosystem or vendor. As a result, we have a fragmented landscape where agents can’t directly talk to each other, limiting their usefulness in complex, cross-system workflows. In April 2025, Google unveiled Agent2Agent (A2A) as an open protocol to break these silos​. Backed by an all-star roster of over 50 partners (from Atlassian and Salesforce to LangChain)​. A2A aims to be the “common language” that lets independent AI agents collaborate seamlessly across applications.

When we first published this article, just a few weeks after the launch, A2A still felt underappreciated. It had not ignited the frenzy one might expect given its pedigree. That early reaction is worth preserving because it shows how quickly the agent-protocol layer changed.

At the time, the public attention curve even suggested a slowdown – why such a lukewarm reception for what could become critical infrastructure?

In this article, we’ll dive deep into A2A – what it is, why it exists, how it works, what people thought about it at launch, and why its adoption started slowly before the ecosystem grew. We’ll walk through the technical foundation of A2A, compare it to protocols like Anthropic’s MCP, and explain the real-world challenges that come with building multi-agent systems. Along the way, we’ll also look at why Google’s push for agent interoperability could have much bigger implications – possibly even laying the groundwork for a searchable, internet-scale directory of AI agents. As always, it’s a great starting guide, but also useful for those who have already experimented with A2A and want to learn more. Dive in!

What’s in today’s episode?

Google’s announcement of A2A checked all the right boxes: a compelling vision of cross-agent collaboration, heavyweight partners, open-source code, and even a complementary relationship with Anthropic’s Model Context Protocol (MCP)​. In theory, the timing looked perfect. The AI world was abuzz with “agent” frameworks – but most first-generation “AI agent” stacks were solo players, single large language models equipped with a toolbox of plugins or APIs. MCP, announced in late 2024, was beginning to show the value of standardizing how an AI agent accesses tools and context, acting as a kind of “USB-C port for AI”​. A2A picked up where that left off: standardizing how multiple autonomous agents communicate, so they could exchange work and results without custom integration glue.

So why didn’t A2A take off overnight? Part of the issue was hype dynamics. When Anthropic announced MCP in late 2024, it initially received a tepid response; only months later did it trend as a game-changer. A2A appeared to be following a similar path. Its value was abstract at first glance – enterprise agent interoperability was not as immediately flashy as a new state-of-the-art model or a chatbot that wrote code. Many developers had not yet felt the pain of multi-agent collaboration because they were still experimenting with single-agent applications. In smaller projects, one could simply orchestrate several API calls within one script or use a framework like LangChain internally, without needing a formal protocol. The urgency of A2A’s solution became clearer in larger, more complex environments – exactly those found in big companies – but that story took time to reach the broader community.

Another factor was “yet another standard” fatigue. By April 2025, approaches for extending LLMs were already multiplying: function calling, plugin systems, custom RPC schemes, and vendor-specific agent APIs. Developers reasonably asked: Do we really need another protocol? A2A was new, with few public success stories and no killer demo that made “agents talking to agents” feel urgent. The infrastructure problem was real, but it had not yet become a buzzword in everyday AI developer chats.

At its core, Agent2Agent (A2A) is an application protocol that lets independent AI agents speak to each other in a structured way. It defines shared operations and data objects for discovery, messages, tasks, status updates, and results. A2A v1.0 maps those operations onto three standard protocol bindings: JSON-RPC, gRPC, and HTTP+JSON/REST. Any agent framework or vendor can implement the open Apache-licensed standard, much as different web systems can interoperate through common web protocols.

At the heart of A2A is the Agent Card – a public JSON manifest that a service can publish at /.well-known/agent-card.json. It describes the agent, its skills, supported input and output modes, security requirements, and one or more supported interfaces. Think of it as an OpenAPI-style profile: a client can inspect the card before deciding which interface to use and whether the agent is suitable for the job. Cards can also be obtained from a registry or supplied directly, and v1.0 allows signed cards and richer cards available after authentication.

A2A defines two flexible roles: Client (requesting agent) and Server (performing agent). Any A2A-compliant agent can fluidly switch roles, enabling flexible topologies like peer-to-peer meshes or hub-and-spoke models.

The core unit of longer-running collaboration is a Task, but not every exchange has to create one. A client starts with the SendMessage operation; the remote agent may answer with a direct Message or return a Task that can be tracked. Tasks carry an ID and move through explicit states such as submitted, working, input-required, completed, failed, or canceled. This supports multi-step work, clarification questions, and asynchronous completion without forcing the client to see the remote agent’s internal reasoning.

Messages and their Parts structure the dialogue. A Message comes from either the client or the agent, and its Parts can carry text, structured data, inline bytes, or a file URL. In v1.0, these use one unified Part structure rather than separate text, file, and data part types. Task status is represented separately, which keeps conversation content distinct from the lifecycle of the work.

When a task produces a result, the output can be packaged as an Artifact, also built from Parts. An artifact might contain a report, a JSON dataset, an image, or a file reference. It is the result of the delegated work, not a promise of permanent storage; retention and reuse still depend on the implementation.

A2A also supports Streaming and Push Notifications. A streaming-capable agent can send task, status, message, and artifact updates over Server-Sent Events (SSE). For work that continues after the original connection closes, a client can configure push notifications if the server advertises that capability. These are optional capabilities, so a client should inspect the Agent Card before relying on them.

Under the hood, A2A deliberately uses familiar infrastructure. Version 1.0 separates the common application model from its JSON-RPC, gRPC, and HTTP+JSON/REST bindings; streaming uses SSE in the web bindings. Agent Cards declare security schemes such as API keys, HTTP authentication, OAuth 2.0, OpenID Connect, or mutual TLS. A2A describes how an agent advertises and applies those schemes, but credential issuance and trust policy remain outside the protocol.

A typical A2A interaction might look like this: Agent Alpha (client) needs a sales chart. It fetches Agent Beta’s (server) Agent Card and sees a “create_chart” capability. Alpha uses SendMessage to send: “Generate a bar chart of sales by region for Q1.” Beta decides that the work needs to be tracked, creates a Task, and reports its status as it works. If Beta needs more details – say, clarification on which regions – it updates the Task to input-required, with a status message explaining what is missing. Alpha then sends another Message with the requested information. When the chart is ready, Beta marks the Task completed and returns the chart as an Artifact, which Alpha can use or hand off to another agent.

Because Beta’s skills were discoverable and invoked through a standard A2A interface, this interaction avoided the usual brittle handoffs and custom glue code. A2A v1.0 defines a common application model with JSON-RPC, gRPC, and HTTP+JSON/REST bindings. That’s the promise of A2A: a dependable boundary for agents built by different teams, frameworks, and vendors.

What you'll need:

What to do:

In a second terminal, return to the same helloworld directory and run the official test client:

The sample client discovers the server and sends a message through the current A2A Python SDK. Treat the sample as a protocol demonstration, not production-ready security architecture.

Everything after that – security, registries, observability – is just normal micro-service hygiene, only now your “micro-service” speaks in tasks and artifacts instead of REST verbs.

Before A2A, most AI workflows revolved around a single “uber-agent” orchestrating a stack of tools – hence MCP’s rise – so genuine agent-to-agent hand-offs were rare. Attempts at multi-agent collaboration were improvised: brittle natural-language chats or vendor-locked frameworks that couldn’t mix Microsoft, Google, and open-source agents without heavy glue code. With no common way to discover peers, pass tasks, or reference artifacts, every handshake was bespoke – and fragmentation quickly became a scaling nightmare. (Academic protocols like KQML and FIPA-ACL tried to solve this in the ’90s, but they never crossed over into today’s LLM world.)

With all this promise, it’s important to ask: Does A2A solve everything? Of course not. Much like MCP or any new technology, A2A comes with its own set of challenges and is not a cure-all for multi-agent systems. It’s better to think of A2A as a powerful enabler – an integration layer that can make previously impossible workflows feasible – but not a guarantee of success on its own.

One important limitation: A2A doesn’t make agents smarter – it just makes it easier for them to talk. If you connect two mediocre agents, you don’t get brilliance; you risk endless task-passing with no progress. Effective collaboration still needs careful design: deciding who tackles what, ensuring shared goals, handling failures. In short, A2A doesn’t eliminate the need for orchestration intelligence; it simply makes the communications in that orchestration standardized.

Adopting A2A also introduces operational overhead. Each agent becomes a service (with an HTTP endpoint or embedded server), which means managing a mesh of agents: HR on Workday, sales on Salesforce, custom Python analytics – all needing discovery, authentication, monitoring, and resilience. It’s microservices all over again. For small workflows, a simple script might be easier. Like MCP, which only pays off when you have many tools and contexts, A2A only pays off when you’re stitching together many agents with diverse capabilities.

A2A is young, but it is no longer merely a draft. Version 1.0 is the project’s first stable, production-ready specification. That does not remove implementation risk: SDKs, platform integrations, conformance tooling, and operational practices are still maturing. Teams moving from v0.3 should use the official migration guides because v1.0 changed method names, the Part model, Agent Card interfaces, and several field names.

Compatibility is still a hurdle, although the critical-mass problem looks different now. The Linux Foundation says the ecosystem has grown beyond 150 supporting organizations. Microsoft supports A2A connections in Copilot Studio and offers A2A tools and hosting in Microsoft Foundry, with some Foundry capabilities still in preview. AWS supports deploying A2A servers in Bedrock AgentCore Runtime. That is real progress, but a logo or integration does not guarantee that two independently built agents will behave well together. Version support, optional capabilities, authentication, extensions, and task semantics still need to be tested end to end.

Security remains a frontier. A2A can advertise standard authentication schemes, use HTTPS, sign Agent Cards, and protect extended cards behind authentication. But the protocol does not decide which agent should be trusted, what data it may see, or whether its output is safe. External Agent Cards, messages, artifacts, and status updates must be treated as untrusted input: validate them, scope credentials narrowly, defend downstream models against prompt injection, and put audit, policy, and rate controls around agent-to-agent traffic.

None of this is a dealbreaker. It’s just what new infrastructure looks like. Microservices took years to mature. A2A will too. It's not a silver bullet – it’s protocol glue. But with the right expectations and pilot projects, it can solve communication problems in multi-agent systems. The rest still depends on good design, thoughtful implementation, and a community willing to push it forward.

Will MCP and A2A become competitors? The short answer is no. While some argue that competition might emerge if A2A starts absorbing functionalities traditionally covered by MCP – particularly if companies begin modeling their data and services primarily as independent agents rather than mere tools or resources – I find this scenario highly unlikely.

Tools and resources will always remain distinct and essential building blocks in agentic systems, and the space for their integration is expansive enough to comfortably accommodate both protocols. MCP excels at standardizing interactions between LLMs and external data sources or tools, while A2A addresses secure, stateful inter-agent communication. Given their complementary strengths and the sheer scale of the agentic ecosystem, both MCP and A2A will coexist, each finding its clearly defined and valuable role.

Where does A2A fit into the emerging AI infrastructure stack? To answer that, picture the layers involved in turning raw AI models into useful autonomous agents. In previous discussions, we’ve broken down the components of agentic systems – things like memory, reasoning, and tool use. A2A doesn’t try to solve all of those; it slots in as a communication and coordination layer.

First, consider a single agent. It typically consists of a core model (like an LLM), behavior logic (via prompting or planning), and mechanisms for interfacing with the outside world (tools, APIs). Frameworks like LangChain, Semantic Kernel, and Google’s Agent Development Kit (ADK) help manage these parts. MCP, as we’ve covered before, standardizes how agents plug into external tools.

A2A sits one level higher: agent-to-agent. If MCP and tool APIs enable an agent to act on the world, A2A enables agents to act on each other. They’re complementary, not competitors. In fact, they often combine. An agent’s A2A Card could advertise capabilities internally powered by MCP – for example, an "Invoice Processing Agent" could offer to extract invoice fields (via A2A) while using OCR tools (via MCP) under the hood. A2A orchestrates multi-agent workflows, while leaving internal tool management to each agent.

Stacking it up:

Importantly, A2A doesn’t replace LangChain, Semantic Kernel, Google ADK, or other frameworks – it gives independently built agents a common boundary. The project now maintains official SDKs for Python, Go, JavaScript, Java, .NET, and Rust, plus framework-oriented samples. A LangChain agent and an ADK or Semantic Kernel agent can collaborate if each side implements compatible A2A interfaces; the protocol does not make every framework interoperable automatically.

It’s a familiar pattern: web systems became easier to compose once common protocols and API conventions replaced bespoke integrations. A2A is trying to create a similarly dependable boundary for AI agents.

Finally, while OpenAI’s function calling allows intra-agent tool use, A2A enables inter-agent cooperation. They serve different scopes and will likely coexist in sophisticated systems.

If it succeeds, A2A will become the lingua franca of multi-agent workflows – a quiet but critical enabler of the next phase of AI infrastructure.

A2A is far better known than it was at launch, yet the most interesting part is still easy to underestimate: the kinds of workflows and collaborations a shared agent protocol can make possible. Let’s look at a few.

Many of these setups were either infeasible or extremely costly before. Ironically, while the AI world chases bigger models and fancier prompts, it might be humble plumbing like A2A that unlocks qualitatively new capabilities. By making agentic collaboration modular, secure, and plug-and-play, A2A lowers the barrier to innovation – and we’re just starting to see what’s possible.

Technically, yes – but the distinction matters.
A2A defines a machine-readable Agent Card and a standard well-known location, /.well-known/agent-card.json. Clients can also receive cards through direct configuration or registries, so the protocol does not itself create a global directory. Still, public cards give a search engine a useful hook: a crawler could discover card URLs, validate and index their metadata, and build a searchable layer above the protocol. That would be a product built on A2A, not a feature guaranteed by A2A.

Signals inside Google Cloud show the appetite.
The searchable Agent Gallery now lives inside Gemini Enterprise, where users can discover Google-built, partner, marketplace, and in-house agents. Google Cloud also exposes partner-built agents through its Agent Marketplace, and A2A is part of the interoperability layer behind this ecosystem. That is already a governed catalog for agents – just not the open, web-scale crawler imagined here.

A2A lays the pipes; whether Google or someone else turns those pipes into the world’s switchboard is still an open question. The protocol is no longer an obscure launch-week experiment: it has neutral governance, a stable 1.0 specification, official SDKs, conformance work, and major cloud integrations. But the larger thesis has not been settled. If a public agent index emerges, it could become something like DNS plus search for autonomous software – potent, profitable, and politically radioactive. Until that future crystallizes, pilot A2A, verify protocol versions and security assumptions, and stay nimble. Infrastructure wins hinge less on brilliance than on trust, incentives, and a thousand quiet integration stories. Watch those stories.

A2A is an open protocol for communication and collaboration between independent AI agents. It standardizes capability discovery, task exchange, messages, status updates, and artifacts without requiring one agent to expose its internal implementation.

A2A coordinates peer agents that delegate and complete tasks together. MCP connects an AI application or agent to tools, resources, and contextual data. A remote A2A agent can itself use MCP to access tools while working on a delegated task.

A2A stands for Agent2Agent. The name describes the protocol’s focus: interoperable communication between autonomous or semi-autonomous agent systems built by different teams, vendors, or frameworks.

Yes. In this context, A2A is the common abbreviation for the Agent2Agent protocol. It should not be confused with unrelated uses of A2A in advertising, payments, or application integration.

An Agent Card is a JSON document published by an A2A server. It describes the agent’s identity, endpoint, supported capabilities, skills, protocol features, and authentication requirements so client agents can discover how to work with it.

Resources to Dive Deeper:

Sources from Turing Post