Google, IETF e novos protocolos para agentes de AI: por que A2A, Pilot e OpAMP são necessários

Os sistemas de IA funcionam cada vez mais não apenas como chatbots autônomos, mas também como participantes da infraestrutura de rede. Neste contexto, está surgindo uma nova classe de protocolos que ajuda os agentes a se descobrirem, trocar tarefas, economizar tokens e transmitir telemetria sem integrações caóticas.

Por que os protocolos são necessários

Cenários em que a IA já controla processos do mundo real deixaram de ser teoria. Na infraestrutura de rede, modelos de aprendizado de máquina já ajudam a detectar anomalias, isolar dispositivos IoT suspeitos e definir regras de QoS. Em paralelo, o IETF publica documentos sobre a estrutura de controladores de rede inteligentes e redes orientadas por intenção. Esta é uma mudança significativa: a IA está se tornando não uma camada sobre a interface, mas parte do loop operacional que influencia o comportamento do sistema em tempo real.

O problema é que tais agentes raramente falam a mesma língua. Na maioria das vezes, são conectados através de APIs separadas, conectores personalizados e lógica manual de troca de mensagens. Enquanto o sistema é pequeno, isso é tolerável. Mas quando há muitos agentes, os custos de integração, roteamento de tarefas, gerenciamento de estado e segurança da transmissão de dados crescem drasticamente. Portanto, o mercado está buscando não outro framework, mas formas padronizadas de comunicação entre agentes.

Quatro abordagens notáveis

Quatro soluções são particularmente interessantes agora porque resolvem não o mesmo problema, mas diferentes camadas da infraestrutura de agentes. Algumas lidam com conectividade de rede direta, outras com formato de mensagem, outras com seleção de executor, e outras ainda com operação e observabilidade. Em vez de tentar inventar um super-protocolo universal, o mercado parece estar seguindo um caminho mais pragmático: dividir a tarefa em camadas separadas e padronizar cada uma delas à sua maneira.

• Pilot da Vulture Labs oferece aos agentes autônomos um stack de rede completo. Os agentes recebem endereços virtuais de 48 bits, e a comunicação ocorre sobre UDP usando Ed25519 e X25519. A abordagem é projetada para comunicação direta mesmo atrás de NAT, firewalls e na nuvem.

• PAIRL de Dennis Verman traduz linguagem natural em um formato mais compacto e legível por máquina. Em vez de explicações longas, o protocolo usa referências e hashes de dados, e o autor estima economia de tokens em 70–90%. Além disso, você pode definir limites para tarefas específicas.

• A2A é construído em torno de "cartões de capacidade" JSON dos agentes. Um agente descreve o que pode fazer, e outro com base nessas informações seleciona um executor e formato de interação. O protocolo foi inicialmente desenvolvido no Google e depois transferido para a Linux Foundation para desenvolvimento posterior.

• OpAMP do ecossistema OpenTelemetry resolve um problema mais prático: gerenciamento remoto de um grande número de agentes e coleta de sua telemetria. Através dele, você pode obter status, dados do sistema, métricas de carga e enviar configuração de volta para os agentes.

"ref:doc:sha256:..." — um exemplo de como PAIRL substitui uma frase

longa por uma referência curta e legível por máquina para um documento.

Observando amplamente, esses protocolos não competem diretamente entre si. Pilot lida com conectividade de rede, PAIRL com compactação e estrutura de mensagens, A2A com descrição de funções e coordenação em um sistema multi-agente, e OpAMP com operação, observabilidade e configuração remota. Este é o principal sinal do mercado: o ecossistema de sistemas de agentes está se decompondo rapidamente em camadas técnicas separadas, cada uma desenvolvendo seus próprios padrões.

Quem define o padrão

A2A está recebendo a maior atenção agora, e a razão é clara: a iniciativa veio do Google, e a ideia se encaixa bem com o crescimento de produtos multiagente. O artigo apresenta um exemplo simples—planejamento de uma viagem internacional onde um agente reserva voos, outro seleciona um hotel e um terceiro encontra passeios. Esta abordagem requer um formato comum para descrever capacidades, caso contrário, cada combinação se torna um projeto separado.

Curiosamente, a comunidade já está comparando A2A com MCP de Anthropic: ambas as soluções usam JSON-RPC, mas resolvem diferentes problemas.

Notavelmente, quase cada um dos protocolos mencionados já possui não apenas uma ideia, mas uma infraestrutura funcional ao seu redor. Para Pilot, um whitepaper e demo foram publicados; para PAIRL—documentação e um exemplo público de transformação de requisição; para A2A—especificações detalhadas e até um curso de treinamento preparado com especialistas do Google Cloud e IBM Research. OpAMP tem documentação para HTTP e WebSocket, estruturas de mensagem e implementações prontas, incluindo uma versão em Go. Isso não é mais um conceito em um slide, mas um conjunto de ferramentas que pode ser testado em sistemas reais.

O que isto significa

O mercado de sistemas de agentes está começando a repetir a história inicial da Internet: primeiro vem um zoológico de soluções incompatíveis, depois um conjunto comum de protocolos. Para equipes que construem produtos multiagente, agora é um bom momento para observar os padrões: eles ajudam a reduzir o volume de integrações personalizadas, simplificar o dimensionamento e tornar os agentes parte da infraestrutura normal de engenharia, em vez de uma coleção de scripts disparatados.