Does Your Team Need to Care About an Agent-to-Agent Protocol Standard?

Three of the five Birds-of-a-Feather sessions at IETF 126 in Vienna last week were about AI agents. Not one - three. That is an unusual concentration for a body whose sessions normally cover things like BGP security and DNS extensions, and it signals something concrete: agent-to-agent communication has moved from a vendor feature to an internet infrastructure problem.

The session that matters most for teams building with AI agents right now is called agentproto. For more than a year, vendors shipped competing AI agent protocols - Anthropic's MCP, Google's A2A, and several more - and none of them cleared the one bar that makes a protocol truly interoperable across organizational boundaries: an IETF RFC. On July 23, the agentproto Birds-of-a-Feather session at IETF 126 brought that question into the Internet Engineering Task Force, with a view toward chartering a Working Group.

This is not a product announcement. But it does change the strategic calculus for any team choosing between MCP and A2A right now.

What is the agent-to-agent protocol landscape right now?

The past year has produced a rush of competing, overlapping protocols for connecting AI agents to one another and to the tools they use - Model Context Protocol (MCP), Agent2Agent (A2A), the Agent Communication Protocol (ACP), the Agent Network Protocol (ANP), and more. That fragmentation has a cost: every pairing of agent frameworks currently needs its own integration.

The two protocols that have actually landed in production are MCP and A2A. They do different things:

• MCP (Anthropic, now Linux Foundation): connects an agent to tools and data sources - databases, APIs, file systems. Think of it as the integration layer.
• A2A (Google, now Linux Foundation): handles agent-to-agent collaboration - one agent delegating a task to another, across different frameworks and vendors.

MCP serves as a standardization layer for AI applications to communicate with external services such as APIs, data sources, and predefined functions. A2A focuses on agent collaboration, facilitating communication between AI agents. Both protocols are meant to complement each other.

A useful way to see the difference: a retail store might have its own inventory agent that uses MCP to interact with databases storing information about products and stock levels. If that inventory agent detects products low in stock, it notifies an internal order agent, which then uses A2A to communicate with external supplier agents and place orders.

A2A's ecosystem numbers are real. Since April 2025, the number of organizations supporting A2A has grown from more than 50 to over 150 - including AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow. The core repository has surpassed 22,000 GitHub stars, and the SDK ecosystem has expanded from a single Python implementation to five production-ready languages, including JavaScript, Java, Go, and .NET.

But "150 companies signed a support letter" and "developers actually reach for this instead of a REST call" are two different claims. Protocol ecosystems often look larger in press releases than they feel in day-to-day engineering work. "Supported by" is not the same thing as "deeply used in production by most developers."

What the IETF agentproto session actually decided

A BoF is not a standards vote. A Birds-of-a-Feather session is an initial, community-wide discussion about a topic that may be ripe for new work in the IETF. Some BoFs are working-group-forming: their goal is to confirm that there is enough consensus, energy, and a tight enough scope to charter a new Working Group, often with a draft charter already on the table.

Building on a well-attended IETF 124 side meeting and requirements work led by Jonathan Rosenberg and Cullen Jennings, the session aims to identify which building blocks of agent-to-agent and agent-to-tool communication genuinely need to be standardized, with a view toward chartering a Working Group to take that work forward.

Five competing AI agent protocols - Anthropic's Model Context Protocol, Google's Agent2Agent, the Agent Communication Protocol, the Agent Network Protocol, and Cisco's Agntcy Framework - have each staked out overlapping territory without any of them clearing the one bar that makes a protocol truly interoperable across organizational boundaries.

If a Working Group is chartered, the resulting standard - likely an RFC two to three years out - would establish the protocol baseline that every vendor shipping inter-domain AI agent infrastructure would eventually need to implement.

The specific gaps the IETF session was built around are worth naming. Three of the five BoFs at IETF 126 focused on AI agents: agentproto - a proposal to charter the first IETF working group for agent-to-agent and agent-to-tool communication protocols; DAWN - Discovery of Agents, Workloads, and Named Entities, tackling how agents find each other at scale; and DMSC - Dynamic Multi-Agent Secured Collaboration, exploring how agents coordinate across trust boundaries.

The message from Vienna is clear: the identity, authorization, and trust layer for AI agents is now a first-class internet infrastructure problem.

What A2A v0.3 actually changed, and the gap it didn't close

Google released version 0.3 of the A2A protocol on July 31, which brings a more stable interface to build against. This version introduces gRPC support, the ability to sign Agent Cards, and extended client-side support in the Python SDK.

The signed Agent Cards piece matters more than it sounds. Version 0.3 added JWS signing so a client can verify a card wasn't tampered with in transit - which matters more than it sounds like the first time someone points out that an Agent Card is just an unauthenticated JSON file sitting at a well-known URL.

But signing a card is not the same as knowing who owns the agent behind it. An Agent Card answers "what can this agent do," not "who owns it, and what should it be allowed to know." That's a real gap, not a nitpick. It is exactly the gap DMSC and DAWN exist to address at the IETF level.

There is also a structural difference in how MCP and A2A got adopted that teams should understand before picking a foundation:

MCP started simple and evolved. Google's enterprise-first approach with A2A meant individual developers had little reason to experiment early. That asymmetry still shows up in which protocol gets reached for first.

What this means for teams building with AI agents today

The honest answer is: right now, the IETF session is a watch item, not an action item. What is genuinely new is that agent-to-agent communication is now being treated as an internet-infrastructure problem, not just a vendor feature. That changes the risk profile of building on either MCP or A2A.

Here is what to actually do:

• If you are building agent-to-tool integrations, MCP is the right layer. It is simpler, has wider tooling, and the developer ecosystem is larger today.
• If you are building agent-to-agent workflows across different vendor systems, A2A is the only protocol with the task lifecycle semantics you need - but budget time to understand Agent Cards and how you will handle identity.
• If you are building something that crosses organizational boundaries - your agent calling a partner's agent - neither protocol has solved cross-domain identity cleanly yet. That is the problem the IETF is being asked to tackle.
• Watch the IETF Datatracker for the agentproto Working Group charter. A proposal typically moves from a Birds-of-a-Feather session to a Working Group charter, through multiple Internet-Draft revisions, through IETF-wide last call and Area Director review, to publication as an RFC. The typical timeline from a BoF to a published Internet Standard runs two to four years. That is longer than most sprint cycles - but RFCs are the thing that make protocols permanent.

The real shift from this week is not that MCP won or A2A won. It is that the IETF - the body that produced TLS, DNS, and QUIC - is now in the room. The case for a common protocol is the same one that gave us HTTP, SMTP, and every other protocol that stuck: pairwise integrations don't scale. At some point that logic applies to agent communication too.

Agent-to-agent protocol standard: common questions

What is the difference between MCP and A2A?

MCP connects an AI agent to tools and data sources - think APIs, databases, file systems. A2A connects AI agents to each other, handling task delegation across frameworks and vendors. They are designed to complement each other: MCP handles the tool layer, A2A handles the coordination layer. Most production systems will eventually use both.

Is there an official IETF standard for AI agent communication?

Not yet. For more than a year, vendors shipped competing AI agent protocols - Anthropic's MCP, Google's A2A, and several more - and none cleared the bar of an IETF RFC. On July 23, 2026, the agentproto BoF at IETF 126 in Vienna opened the question of whether the IETF should charter a Working Group to change that. A resulting RFC is realistically two to four years away.

What did A2A v0.3 change?

Version 0.3 brings a more stable interface to build against and introduces gRPC support, the ability to sign Agent Cards using JWS, and extended client-side support in the Python SDK. The signed cards close one security gap - verifying a card was not tampered with in transit - but do not resolve the deeper question of cross-domain agent identity.

What is an Agent Card in the A2A protocol?

A2A uses metadata documents known as Agent Cards to describe an agent's capabilities and how it can be accessed. These documents are exchanged using widely adopted web technologies such as HTTP and JSON-based messaging formats. An Agent Card sits at a well-known URL, tells a client what the agent can do, and - since v0.3 - can be cryptographically signed to confirm it was not altered.

Should my team adopt A2A or wait for an IETF standard?

Build on MCP for tool integrations - that choice is low-risk regardless of what the IETF produces. For agent-to-agent work within one organization, A2A is safe to adopt now: agents are increasingly deployed across departments, products, and partner ecosystems. The key question is no longer whether agents can coordinate within one stack, but whether they can collaborate reliably across organizational and platform boundaries. Open protocols determine whether organizations can compose best-of-breed systems or become locked into isolated stacks. For cross-organizational workflows, wait until the identity story firms up.