Google, IETF y nuevos protocolos para agentes de AI: por qué A2A, Pilot y OpAMP son necesarios

Los sistemas de IA funcionan cada vez más no solo como chatbots autónomos, sino también como participantes en la infraestructura de red. En este contexto, está surgiendo una nueva clase de protocolos que ayuda a los agentes a descubrirse mutuamente, intercambiar tareas, ahorrar tokens y transmitir telemetría sin integraciones caóticas.

Por qué se necesitan protocolos

Los escenarios en los que la IA ya controla procesos del mundo real han dejado de ser teoría. En la infraestructura de red, los modelos de aprendizaje automático ya ayudan a detectar anomalías, aislar dispositivos IoT sospechosos y definir reglas de QoS. En paralelo, IETF publica documentos sobre la estructura de controladores de red inteligentes y redes orientadas por intención. Este es un cambio significativo: la IA se está convirtiendo no en una capa sobre la interfaz, sino en parte del bucle operacional que influye en el comportamiento del sistema en tiempo real.

El problema es que tales agentes rara vez hablan el mismo idioma. La mayoría de las veces se conectan a través de APIs separadas, conectores personalizados y lógica manual de intercambio de mensajes. Mientras el sistema sea pequeño, esto es tolerable. Pero cuando hay muchos agentes, los costos de integración, enrutamiento de tareas, gestión de estado y seguridad de la transmisión de datos crecen drásticamente. Por lo tanto, el mercado está buscando no otro framework, sino formas estandarizadas de comunicación entre agentes.

Cuatro enfoques notables

Cuatro soluciones son particularmente interesantes ahora porque abordan no el mismo problema, sino diferentes capas de la infraestructura de agentes. Algunas manejan conectividad de red directa, otras formato de mensajes, otras selección de ejecutor, y otras aún operación y observabilidad. En lugar de intentar inventar un super-protocolo universal, el mercado parece estar tomando un camino más pragmático: dividir la tarea en capas separadas y estandarizar cada una a su manera.

• Pilot de Vulture Labs ofrece a los agentes autónomos un stack de red completo. Los agentes reciben direcciones virtuales de 48 bits, y la comunicación ocurre sobre UDP usando Ed25519 y X25519. El enfoque está diseñado para comunicación directa incluso detrás de NAT, firewalls y en la nube.

• PAIRL de Dennis Verman traduce el lenguaje natural a un formato más compacto y legible por máquina. En lugar de explicaciones largas, el protocolo utiliza referencias y hashes de datos, y el autor estima ahorros de tokens en 70–90%. Además, puede establecer límites para tareas específicas.

• A2A se construye alrededor de "tarjetas de capacidad" JSON de agentes. Un agente describe lo que puede hacer, y otro basado en esta información selecciona un ejecutor y formato de interacción. El protocolo fue desarrollado inicialmente en Google y luego transferido a la Linux Foundation para su desarrollo posterior.

• OpAMP del ecosistema OpenTelemetry resuelve un problema más práctico: gestión remota de un gran número de agentes y recopilación de su telemetría. A través de él, puede obtener estado, datos del sistema, métricas de carga y enviar configuración de vuelta a los agentes.

"ref:doc:sha256:..." — un ejemplo de cómo PAIRL reemplaza una frase

larga con una referencia corta legible por máquina a un documento.

En términos generales, estos protocolos no compiten directamente entre sí. Pilot maneja conectividad de red, PAIRL compactación y estructura de mensajes, A2A descripción de roles y coordinación en un sistema multiagente, y OpAMP operación, observabilidad y configuración remota. Esta es la señal clave del mercado: el ecosistema de sistemas de agentes se está descomponiendo rápidamente en capas técnicas separadas, cada una desarrollando sus propios estándares.

Quién establece el estándar

A2A está recibiendo la mayor atención en este momento, y la razón es clara: la iniciativa provino de Google, y la idea encaja bien con el crecimiento de productos multiagente. El artículo presenta un ejemplo simple: planificación de un viaje internacional donde un agente reserva vuelos, otro selecciona un hotel y un tercero encuentra tours. Este enfoque requiere un formato común para describir capacidades; de lo contrario, cada combinación se convierte en un proyecto separado.

Curiosamente, la comunidad ya está comparando A2A con MCP de Anthropic: ambas soluciones utilizan JSON-RPC pero resuelven diferentes problemas.

Notablemente, casi cada uno de los protocolos mencionados ya tiene no solo una idea, sino infraestructura de trabajo a su alrededor. Para Pilot, se han publicado un whitepaper y una demostración; para PAIRL documentación y un ejemplo público de transformación de solicitudes; para A2A especificaciones detalladas e incluso un curso de capacitación preparado con especialistas de Google Cloud e IBM Research. OpAMP tiene documentación para HTTP y WebSocket, estructuras de mensajes e implementaciones listas, incluida una versión en Go. Esto ya no es un concepto en una diapositiva, sino un conjunto de herramientas que se pueden probar en sistemas reales.

Qué significa esto

El mercado de sistemas de agentes está comenzando a repetir la historia inicial de Internet: primero viene un zoológico de soluciones incompatibles, luego un conjunto común de protocolos. Para equipos que construyen productos multiagente, ahora es un buen momento para mirar los estándares: ayudan a reducir el volumen de integraciones personalizadas, simplificar el escalado y hacer que los agentes sean parte de la infraestructura de ingeniería normal en lugar de una colección de scripts dispares.