The Internet Engineering Task Force opened its 126th meeting in Vienna on Saturday. About 1,000 engineers are in attendance. Five Birds-of-a-Feather sessions are scheduled across the week, and three of them are about AI agent communication. The one that matters most for anyone building with MCP or A2A happens Thursday morning.

That session is called agentproto. Its purpose is to determine whether the IETF will charter a Working Group to produce a formal internet standard for agent-to-agent communication. If it does, the resulting RFC would sit alongside protocols like HTTP, TLS, and SIP as a baseline every vendor eventually needs to implement.

Five Protocols, No Standard

The past eighteen months produced five competing protocols for connecting AI agents to tools and to each other:

  • Model Context Protocol (MCP) from Anthropic, donated to the Linux Foundation in December 2025. 97 million monthly SDK downloads by early 2026. Adopted by every major AI provider.
  • Agent2Agent (A2A) from Google, donated to the Linux Foundation in June 2025. 150 organizational supporters by April 2026, including AWS, Cisco, IBM, Microsoft, Salesforce, SAP, and ServiceNow.
  • Agent Communication Protocol (ACP) from the open-source community.
  • Agent Network Protocol (ANP) targeting decentralized agent meshes.
  • Agntcy Framework from Cisco, focused on enterprise orchestration.

Each addresses different layers of the stack. MCP standardizes how a single agent connects to external tools and data — the client-server layer. A2A standardizes how agents discover each other and delegate tasks — the peer-to-peer layer. Neither covers the full picture.

What Is Missing

A framework document authored by Jonathan Rosenberg (the lead author of the SIP RFC that governs real-time communications) and Cullen Jennings of Cisco identifies four gaps that current protocols do not address:

  1. Cross-domain identity federation. How does one organization’s agent prove to another organization’s agent that it is authorized to act on a user’s behalf?
  2. Multi-hop lifecycle management. When an agent chain spans three organizations and the middle node fails, what happens to the work in progress?
  3. User confirmation before irreversible actions. The protocol has no mechanism to require human approval before an agent chain triggers a payment, deletes a record, or signs a contract.
  4. Protocol-level attribution for security incidents. When a prompt injection propagates from Agent A through Agent B to Agent C, who is responsible?

That last point is not theoretical. In multi-agent systems, a malicious user interacting with one agent can craft input designed to propagate through a chain of trusted agents. The injection bypasses the first agent’s defenses entirely and exploits the trust relationship between them. OWASP ranks prompt injection as the top security threat for LLM-based applications. The Rosenberg-Jennings framework argues that the protocol itself must include mechanisms for logging, attribution, and incident reconstruction.

Three AI Sessions This Week

The agentproto BoF is not the only AI-related session at IETF 126:

DAWN (Tuesday) targets decentralized agent discovery. The problem: agents today need pre-configured knowledge of each other’s endpoints. DAWN would define an automated, interoperable discovery mechanism that works without a centralized registry. This is the same problem DNS-AID (accepted by the Linux Foundation in May 2026) addresses through DNS records.

DMSC (Wednesday) is a diagnostic session mapping the requirements for an AI agent gateway model — capability exposure, request forwarding, policy control, and secure inter-agent communication. It will not form a Working Group but its output feeds directly into agentproto’s charter discussions.

agentproto (Thursday, 09:00 CEST) is the decision point. It builds on a framework document that positions AI agent protocols as a new layer in the internet stack, sitting above HTTP, SIP, and RTP in the same way those application-layer protocols sit above TCP and IP.

What Thursday’s Outcome Means

If the IETF charters a Working Group, it is declaring that AI agent communication is an internet-layer problem, not a product-layer problem. The resulting RFC — likely two to three years away — would establish the protocol baseline that every vendor shipping inter-domain AI agent infrastructure needs to implement.

If the session reveals too much disagreement, the community returns to the mailing list and the current landscape continues: MCP and A2A set the de facto standard through market adoption rather than formal specification.

Either outcome shapes the next two years. An RFC process does not replace MCP or A2A. It builds on them. MCP handles the agent-to-tool layer. A2A handles the agent-to-agent layer. The IETF standard would address the cross-domain, multi-organizational layer that sits above both.

What This Means for Developers

For developers building with MCP today: nothing changes immediately. The MCP servers you use, the transports you have configured (stdio, SSE, or HTTP), and the tools you have connected all continue to work. MCP at 97 million monthly downloads is not going away regardless of what happens in Vienna.

What does change is the trajectory. If the IETF charters agentproto, every MCP server operator and A2A implementer will eventually need to think about cross-domain identity, lifecycle management, and attribution logging. The protocol stacks will gain new requirements at the edges where organizations connect to each other.

The IETF process is slow by design. An RFC from the agentproto BoF would land somewhere in 2028 or 2029. That is enough runway for the current ecosystem to mature without disruption, and enough signal for architects to start thinking about what interoperability at internet scale actually requires.

Session materials and recordings will be posted to the IETF Datatracker as sessions conclude.

FAQ

Q: Will an IETF standard replace MCP? A: No. MCP handles agent-to-tool communication. An IETF standard would address the cross-domain agent-to-agent layer, covering gaps like identity federation and multi-hop lifecycle that MCP was not designed to solve. The two are complementary.

Q: Does this affect the MCP servers in my current setup? A: Not in the near term. Your MCP server configurations will keep working. Any IETF-driven changes would show up as new requirements at the protocol edges, not as breaking changes to existing server interfaces.

Q: When would an IETF RFC actually ship? A: The typical timeline from a Birds-of-a-Feather session to a published RFC is two to four years. If agentproto charters a Working Group this week, a published standard would arrive in 2028 or 2029 at the earliest.