Google, IETF, and new protocols for AI agents: why A2A, Pilot, and OpAMP are needed

AI systems increasingly work not only as standalone chatbots but also as participants in network infrastructure. Against this backdrop, a new class of protocols is emerging that helps agents discover each other, exchange tasks, save tokens, and transmit telemetry without chaotic integrations.

Why Protocols Are Needed

Scenarios where AI already controls real-world processes have ceased to be theory. In network infrastructure, machine learning models already help detect anomalies, isolate suspicious IoT devices, and define QoS rules. In parallel, IETF publishes documents about the structure of intelligent network controllers and intent-based networks. This is a significant shift: AI is becoming not a layer on top of the interface, but part of the operational loop that influences system behavior in real time.

The problem is that such agents rarely speak the same language. Most often they are connected through separate APIs, custom connectors, and manual message exchange logic. While the system is small, this is tolerable. But when there are many agents, costs for integration, task routing, state management, and data transmission security grow sharply. Therefore, the market is looking not for another framework, but for standardized ways for agents to communicate.

Four Notable Approaches

Four solutions are particularly interesting right now because they address not the same problem, but different layers of agent infrastructure. Some handle direct network connectivity, others—message format, others—executor selection, and still others—operation and observability. Instead of trying to invent a universal super-protocol, the market appears to be taking a more pragmatic path: breaking the task into separate layers and standardizing each one in its own way.

• Pilot from Vulture Labs offers autonomous agents a complete network stack. Agents are assigned 48-bit virtual addresses, and communication occurs over UDP using Ed25519 and X25519. The approach is designed for direct communication even behind NAT, firewalls, and in the cloud.

• PAIRL from Dennis Verman translates natural language into a more compact and machine-readable format. Instead of lengthy explanations, the protocol uses references and data hashes, and the author estimates token savings at 70–90%. Plus, you can set limits for specific tasks.

• A2A is built around JSON "capability cards" of agents. One agent describes what it can do, and another based on this information selects an executor and interaction format. The protocol was initially developed at Google, then transferred to the Linux Foundation for further development.

• OpAMP from the OpenTelemetry ecosystem solves a more practical problem: remote management of a large number of agents and collection of their telemetry. Through it, you can get status, system data, load metrics, and send configuration back to agents.

"ref:doc:sha256:..." — an example of how PAIRL replaces a long phrase

with a short machine-readable reference to a document.

Looking broadly, these protocols do not compete directly with each other. Pilot handles network connectivity, PAIRL—message compactness and structure, A2A—role description and coordination in a multi-agent system, and OpAMP—operation, observability, and remote configuration. This is the key market signal: the ecosystem of agent systems is rapidly decomposing into separate technical layers, each developing its own standards.

Who Sets the Standard

A2A is receiving the most attention right now, and the reason is clear: the initiative came from Google, and the idea fits well with the growth of multi-agent products. The article presents a simple example—planning an international trip where one agent books flights, another selects a hotel, and a third finds tours. This approach requires a common format for describing capabilities, otherwise each combination becomes a separate project.

Interestingly, the community is already comparing A2A with MCP from Anthropic: both solutions use JSON-RPC but solve different problems.

Notably, almost each of the mentioned protocols already has not just an idea, but working infrastructure around it. For Pilot, a whitepaper and demo have been published; for PAIRL—documentation and a public example of request transformation; for A2A—detailed specifications and even a training course prepared with Google Cloud and IBM Research specialists. OpAMP has documentation for HTTP and WebSocket, message structures, and ready implementations, including a Go version. This is no longer a concept on a slide, but a set of tools that can be tried in real systems.

What This Means

The market for agent systems is beginning to repeat the early history of the Internet: first comes a zoo of incompatible solutions, then—a common set of protocols. For teams building multi-agent products, now is a good time to look at standards: they help reduce the volume of custom integrations, simplify scaling, and make agents part of normal engineering infrastructure rather than a collection of disparate scripts.