A história da computação distribuída é de proliferação de protocolos seguida de consolidação.
A Frequent Object Request Dealer Structure (CORBA), o Distributed Part Object Mannequin (DCOM), a invocação de método remoto Java (RMI) e o protocolo simples de acesso a objetos (SOAP) competiram pelo mercado de integração empresarial no last da década de 1990, antes que a transferência de estado representacional (REST) vencesse silenciosamente por ser mais simples e nativa de HTTP.
Protocolo Extensível de Mensagens e Presença (XMPP), Web Relay Chat (IRC) e uma dúzia de protocolos proprietários fragmentaram mensagens em tempo actual antes que o transporte de telemetria MG (MQTT) e os WebSockets conquistassem seus respectivos nichos. Cada novo paradigma de computação gera uma explosão de padrões concorrentes e depois converge lentamente à medida que as implementações se acumulam e a interoperabilidade se torna economicamente necessária.
O ecossistema de agentes de IA está atualmente em fase de proliferação. Quatro protocolos significativos foram publicados nos últimos dezoito meses: Mannequin Context Protocol (MCP) da Anthropic no last de 2024, Agent Communication Protocol (ACP) da IBM Analysis em março de 2025, Agent2Agent (A2A) do Google em abril de 2025 e Agent Community Protocol (ANP) de um grupo de trabalho independente.
O W3C AI Agent Protocol Group Group abriu um caminho de padrões. A Força-Tarefa de Engenharia da Web (IETF) está recebendo rascunhos da Web sobre transporte de agentes. As conferências estão realizando workshops sobre interoperabilidade. Toda semana traz um novo repositório GitHub que pretende resolver o problema de comunicação do agente.
Compreender onde e com que rapidez isso converge tem consequências reais para as decisões de arquitetura que estão sendo tomadas neste momento.
O que os protocolos realmente resolvem
A proliferação parece mais caótica do que é, porque a maioria desses protocolos aborda diferentes camadas de uma pilha, em vez de competir pelo mesmo slot. A confusão vem do advertising, que descreve cada um como “o padrão para comunicação de agentes de IA”, sem especificar qual aspecto da comunicação.
MCP é uma interface de chamada de ferramentas. Ele outline como um modelo descobre quais funções um servidor expõe, como invocá-las e como interpretar a resposta. É um contrato de chamada de procedimento remoto (RPC) digitado entre um cliente modelo e um servidor de ferramentas, executado em HTTP. A Linux Basis confirmou mais de 10.000 servidores MCP públicos ativos e 164 milhões de downloads mensais do Python SDK até abril de 2026. O MCP já ganhou a camada de chamada de ferramentas. O trabalho de padronização é efetivamente realizado.
A2A é uma interface de coordenação de tarefas. Enquanto o MCP outline como um agente chama uma ferramenta, o A2A outline como dois agentes delegam uma tarefa. Ele apresenta cartões de agente (anúncios de capacidade), estados do ciclo de vida da tarefa e três modos de interação: síncrono, streaming e assíncrono. O Google doou-o à Linux Basis em junho de 2025, e as equipes empresariais de IA o adotaram amplamente porque preenche uma lacuna actual que o MCP deixa aberta.
ACP é um formato de envelope de mensagem. Leve, sem estado, projetado para troca de mensagens entre agentes sem a semântica de coordenação whole do A2A. É útil em sistemas onde a simples passagem de mensagens é suficiente e a sobrecarga do ciclo de vida da tarefa do A2A é desnecessária.
ANP é um protocolo de descoberta e identidade. Ele usa identificadores descentralizados (DIDs) para identidade do agente e gráficos JSON-LD para descrições de capacidade, fornecendo uma base para mercados de agentes descentralizados onde nenhum registro central é necessário.
A pilha que está surgindo: descoberta de capacidade through ANP ou registros mais simples, coordenação de tarefas through A2A, chamadas de ferramentas through MCP e mensagens leves through ACP para casos que não exigem gerenciamento completo do ciclo de vida da tarefa. Estas camadas complementam-se em vez de competirem.
O problema de transporte que permanece
Cada protocolo nesta lista é executado em HTTP. Isso reflete a origem dos protocolos: equipes de pesquisa, fornecedores de API e empresas de software program empresarial que criam sistemas onde o HTTP é uma suposição inquestionável. HTTP é o protocolo que eles conhecem, aquele que seus servidores já falam e aquele que facilita as demonstrações.
O problema de produção é que o HTTP assume um servidor acessível. Por trás da tradução de endereços de rede (NAT) — e 88% dos dispositivos em rede ficam atrás do NAT — não há servidor acessível sem retransmissão. Para frotas de agentes que precisam encaminhar tarefas diretamente entre pares através dos limites da nuvem, redes domésticas e implantações de borda, essa centralização força todas as mensagens através da infraestrutura de retransmissão. A infraestrutura de retransmissão adiciona latência, custo e modo de falha.
Os protocolos da camada de aplicação resolvem a semântica do que os agentes dizem uns aos outros. Eles não resolvem como os agentes se encontram e estabelecem conexões diretas. Esse é um problema da camada de sessão, Camada 5 no modelo de interconexão de sistemas abertos (OSI) e nenhum MCP, A2A, ACP ou ANP o aborda.
As tecnologias para resolvê-lo existem. A perfuração UDP com utilitários de passagem de sessão para NAT (STUN) fornece passagem NAT para aproximadamente 70% das topologias de rede. X25519 Diffie-Hellman e AES-256-GCM fornecem criptografia autenticada no nível do túnel sem autoridade de certificação. Conexões rápidas de Web UDP (QUIC) (RFC 9000) ou protocolos de janela deslizante personalizados sobre protocolo de datagrama de usuário (UDP) fornecem entrega confiável sem o bloqueio direto do TCP. Essas são as mesmas primitivas que o WireGuard usa para túneis VPN e que o WebRTC usa para fluxos de mídia de navegador para navegador.
O que difere no contexto do agente é o roteamento baseado em capacidade. Os agentes precisam encontrar pares não pelo nome do host, mas pelo que esses pares podem fazer. Um agente de pesquisa deve ser capaz de consultar “quais pares possuem dados cambiais em tempo actual?” e receba uma lista de agentes especializados atualmente ativos. Isto está mais próximo de um registro de serviços do que de um DNS, e é uma extensão pure da filosofia de design da ANP aplicada à camada de transporte.
Vários projetos estão montando essas peças. O Protocolo Piloto tem a especificação publicada mais completa, com um IETF Web-Draft cobrindo endereçamento, estabelecimento de túneis e travessia NAT para redes de agentes. libp2p fornece uma base testada em batalha com primitivas semelhantes. O grupo de trabalho QUIC da IETF está desenvolvendo extensões de travessia NAT que serão relevantes aqui.
Como será a convergência
Os protocolos baseados em HTTP (MCP, A2A) já estão convergindo para versões estáveis. Os próximos 12 meses verão o fortalecimento da produção, melhorias de segurança, servidores MCP sem estado para escalabilidade horizontal, melhor federação A2A – em vez de novos designs fundamentais. As camadas de chamada de ferramentas e coordenação de tarefas estão amplamente resolvidas.
A camada de transporte está 18 a 24 meses atrasada. Espere um período de diversidade de implementações à medida que as equipes experimentam diferentes abordagens para redes de agentes ponto a ponto (P2P), seguido pela consolidação em torno de um pequeno número de implementações, uma vez acumulados os dados empíricos sobre desempenho e confiabilidade. As vias de normalização da IETF e do W3C provavelmente produzirão algo na janela 2027-2028, altura em que uma ou duas implementações de código aberto terão acumulado implementações de produção suficientes para estabelecer padrões de facto antes da especificação formal.
Para os líderes de engenharia que tomam decisões de arquitetura hoje, a implicação prática é a adoção em camadas. Os protocolos da camada de aplicação são estáveis o suficiente para serem desenvolvidos. A adoção do MCP agora é de baixo risco. A adoção do A2A para coordenação multiagente é razoável com a expectativa de que o protocolo evolua. A camada de transporte é onde você constrói algo personalizado e planeja substituí-lo ou avalia as implementações iniciais sabendo que o espaço ainda está em movimento.
As equipes que terão maior vantagem quando a camada de transporte se estabilizar são aquelas que projetaram seus sistemas de agentes com uma separação clara entre semântica de aplicação (MCP, A2A) e transporte (o que estiver abaixo). A separação limpa é barata para implementar agora e cara para modernizar mais tarde, uma lição que a period dos microsserviços ensinou a qualquer um que tentasse adicionar observabilidade ou interrupção de circuito em sistemas que não tinham nenhuma.
Philip Stayetski é cofundador do Vulture Labs.
Bem-vindo à comunidade VentureBeat!
Nosso programa de visitor posts é onde especialistas técnicos compartilham insights e fornecem análises profundas, neutras e não adquiridas, sobre IA, infraestrutura de dados, segurança cibernética e outras tecnologias de ponta que moldam o futuro das empresas.
Leia mais do nosso programa de visitor submit – e confira nosso diretrizes se você estiver interessado em contribuir com um artigo de sua autoria!
