MCP, A2A, ACP e ANP: os protocolos da futura Internet dos Agentes

Uma equipe monta um agente de compras. Ele consulta o estoque, abre cotações e emite pedidos por ferramentas expostas em um servidor MCP. Logo aparece a segunda necessidade: antes de fechar contrato acima de certo valor, o agente precisa do parecer de um agente jurídico mantido por outro time. E a terceira: um fornecedor novo, de fora da empresa, publicou um agente próprio de cotação, e ninguém sabe se dá para confiar nele. Alguém pergunta na reunião: "Afinal, a gente adota MCP, A2A ou esse tal de ANP?"

A pergunta soa razoável e está mal formulada. As três necessidades são de naturezas diferentes: usar uma capacidade, delegar trabalho a um par e encontrar um desconhecido em rede aberta. Nenhum dos protocolos foi desenhado para as três. Este ensaio defende que o mapa correto não é uma corrida entre siglas, e sim uma pilha em construção, parecida com a que fez a Internet funcionar: protocolos especializados, empilhados, com fronteiras onde a segurança de cada um deixa de valer sozinha.

O texto continua a Série MCP (como um modelo escolhe uma ferramenta, o roadmap de 2026, MCP em sistemas multiagentes); aqui o foco sai do MCP e vai para o conjunto.

1. Da Web de documentos à Web de capacidades

A Internet não tem "o protocolo". DNS resolve nomes, TCP entrega bytes, TLS cifra, HTTP transporta representações, OAuth delega autorização. Cada um faz uma coisa e assume que as outras existem. Foi a composição, e não um vencedor, que fez a Web funcionar.

A Web conectou documentos; as APIs conectaram sistemas. O que está sendo conectado agora são capacidades: entidades que raciocinam, mantêm tarefas em andamento e agem no mundo. Duan e Lu (2026) argumentam que nenhum protocolo único tende a dominar a comunicação entre agentes: nenhuma tecnologia otimiza ao mesmo tempo heterogeneidade, escala, dinamicidade, eficiência e segurança, e o que é melhor para a borda, eficiência e dinamismo, costuma ser o pior para a heterogeneidade, que é o que garante interoperabilidade.

A ideia não é nova. A comunidade de sistemas multiagentes já havia proposto, em 1980, o Contract Net Protocol (Smith, 1980) para distribuir tarefas por anúncio e lance, e a FIPA padronizou, entre o fim dos anos 1990 e 2002, uma linguagem de comunicação entre agentes baseada em atos de fala (FIPA, 2002). O que mudou é que o agente agora entende linguagem natural, o transporte é a Web comum e o interesse é industrial.

2. Quatro siglas, três eixos

O erro mais comum nas comparações é desenhar MCP, A2A, ACP e ANP na mesma linha, como quatro navegadores. Uma leitura melhor os coloca em três eixos: o vertical (do agente para baixo, em direção a ferramentas e dados), o horizontal (do agente para o lado, em direção a pares) e o de rede (do agente para fora, em direção a uma população aberta de desconhecidos). Os surveys que compararam os quatro protocolos chegam a divisões parecidas: Yang et al. (2025) separam protocolos "orientados a contexto" de protocolos "entre agentes"; Ehtesham et al. (2025) os comparam por modo de interação, descoberta, comunicação e segurança.

A própria especificação do A2A adota essa leitura. No apêndice sobre a relação com o MCP, ela descreve o MCP como "o 'como fazer' para um agente usar uma capacidade específica ou acessar um recurso" e o A2A como o protocolo para agentes "se associarem ou delegarem trabalho" como pares: um agente pede uma tarefa a outro, e este usa MCP para acionar as ferramentas necessárias.

A tabela resume o que cada protocolo fixa em cada dimensão, segundo as especificações vigentes; é síntese de leitura, não classificação normativa.

Tabela 1 — O que cada protocolo fixa em cada dimensão, segundo as especificações consultadas em 18/09/2026.

Duas coisas saltam da tabela. Os três protocolos vivos reutilizam a Web como está (HTTP, JSON, OAuth, well-known URIs, TLS); nenhum inventa transporte. E a coluna do ACP é histórica, o que importa para a tese: na minha leitura, é o único caso de competição direta observado até agora, e terminou em consolidação em um ano, não em coexistência; Duan e Lu (2026) tratam a fusão ACP–A2A como uma tentativa de resolver a crise de interoperabilidade no nível do protocolo.

3. MCP em 2026: um núcleo sem estado e um sistema de extensões

Quem leu o MCP em 2025 precisa reler. A revisão 2026-07-28 mudou a forma do protocolo: acabou o aperto de mão initialize, acabaram as sessões do Streamable HTTP e o cabeçalho Mcp-Session-Id. Cada requisição carrega versão e capacidades em _meta; estado entre chamadas, quando necessário, vira um identificador emitido pelo servidor e passado como argumento comum de ferramenta.

Veio também server/discover, método obrigatório pelo qual o servidor anuncia versões, capacidades e identidade. Os pedidos que o servidor fazia ao cliente (amostragem, raízes, elicitação) deram lugar ao padrão de múltiplas idas e voltas: o servidor devolve um resultado input_required e o cliente repete a chamada com as respostas. Roots, Sampling e Logging entraram em depreciação, com janela mínima de doze meses. Tarefas assíncronas saíram do núcleo e viraram a extensão io.modelcontextprotocol/tasks, ao lado das extensões de interfaces interativas (MCP Apps), de skills servidas por MCP e de autorização suplementar. Extensões são opcionais e negociadas em capabilities.extensions.

Na autorização, o núcleo segue OAuth 2.1: o servidor MCP é um resource server que publica Protected Resource Metadata, o cliente é obrigado a enviar o parâmetro resource (RFC 8707) e o registro dinâmico de clientes foi depreciado em favor de Client ID Metadata Documents. Na governança, o MCP é hoje um projeto da Linux Foundation, irmão do A2A na Agentic AI Foundation. Nada disso muda o eixo: o protocolo continua vertical e não tem, nem ganhou em julho, uma noção de agente como par.

4. A2A 1.0: tarefas, Agent Cards e o fim do ACP

O A2A chegou à versão 1.0.0 em 12 de março de 2026, anunciado por um comitê técnico com representantes de AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP e ServiceNow. Dois princípios declarados dizem tudo sobre o eixo que ocupa: "async first", tarefas potencialmente muito longas e humano no circuito; e "opaque execution", agentes colaboram com base em capacidades declaradas sem expor pensamento, plano ou ferramentas internas.

A unidade de troca é a Task, com nove estados na spec (um deles, unspecified, é só o valor padrão de estado desconhecido): submetida, em execução, concluída, falha, cancelada, rejeitada e dois estados de interrupção, entrada necessária e autenticação necessária. A 1.0 trouxe três bindings equivalentes (JSON-RPC 2.0, gRPC e HTTP+JSON), extensões declaradas por URI e o Agent Card assinado com JWS (RFC 7515), que permite verificar criptograficamente identidade e metadados do agente. A autenticação reutiliza o Security Scheme Object da OpenAPI 3.2, declarado no próprio cartão.

E o ACP? O Agent Communication Protocol da IBM Research, nascido no ecossistema BeeAI, oferecia uma API REST para comunicação entre agentes, com multimodalidade, streaming e sessões: um concorrente direto do A2A no eixo horizontal. Em 29 de agosto de 2025, IBM e Google anunciaram (Blair e Segal, 2025) que o ACP se juntava ao A2A sob a Linux Foundation; a equipe "encerraria o desenvolvimento ativo e passaria a contribuir tecnologia e experiência diretamente ao A2A". O repositório i-am-bee/acp foi arquivado em 27 de agosto de 2025 e o BeeAI migrou para A2A com adaptadores. Em 2026, "ACP" sem expansão é ambíguo (há um Agent Connect Protocol e um Agent Client Protocol com a mesma sigla); aqui, ACP é sempre o da IBM, e ele é passado.

O episódio responde metade da pergunta do ensaio: protocolos de agentes competem quando ocupam o mesmo eixo e, quando competem, a saída observada foi consolidação em um ano. Em 27 de agosto de 2026 o A2A entrou na Agentic AI Foundation como projeto Growth Stage, ao lado de MCP, goose e AGENTS.md.

5. ANP: identidade e descoberta para uma rede aberta

O Agent Network Protocol parte de outra pergunta. A2A assume que você sabe, ou consegue descobrir no seu contexto organizacional, com quem quer falar. ANP pergunta como uma população aberta de agentes pode ter identidade verificável, publicar descrições, ser encontrada e se comunicar com segurança sem uma plataforma central. O white paper de Chang et al. (2025) chama esse alvo de Agentic Web.

A versão 1.1 organiza o protocolo em três camadas: a infraestrutura aberta da Internet (HTTP, DNS, CA, TLS); uma camada de identidade e comunicação cifrada baseada no método did:wba do padrão W3C DID (W3C, 2022) e em nomes legíveis como alice.example.com; e a camada de aplicação, com o Agent Description Protocol, o Agent Discovery Protocol, mensageria ponta a ponta e um protocolo de pagamento. A descrição de um agente é um JSON com identificador DID, dono, esquema de segurança, prova de assinatura e uma lista de interfaces, que podem ser OpenRPC, YAML em linguagem natural, MCP ou WebRTC. A descoberta ativa usa /.well-known/agent-descriptions por domínio; a passiva registra a descrição em um serviço de busca.

Dois pontos pedem cautela. A "negociação de meta-protocolo", que o white paper apresenta como central, está hoje marcada no repositório como rascunho que "não faz parte da arquitetura publicada". E a escala: o ANP é um projeto comunitário (cerca de 1,4 mil estrelas no GitHub em 18/09/2026) e, até onde vi, sem o comitê industrial nem a fundação que o A2A tem. Sua contribuição é insistir em uma pergunta que MCP e A2A não fazem: quem é este agente, e quem garante isso, quando não há empresa no meio.

6. Como os protocolos se compõem

Troque o agente de compras por uma tarefa mais cotidiana: "Organize minha ida à conferência em Berlim respeitando a política da empresa." Uma arquitetura plausível encadeia tudo o que vimos, e nenhuma camada substitui outra.

O modelo interpreta destino, datas e restrições. Um RAG traz a política de viagens e pode ficar inteiro atrás de um servidor MCP. O orquestrador divide o objetivo em voo, hotel, validação e reserva. Pelo A2A, delega a um agente de voos, um de hotéis e um de despesas, acompanhando cada Task; um deles pode voltar em input-required pedindo o cartão corporativo. Cada agente usa MCP para chamar search_flights, search_hotels ou create_booking. Se a empresa não tem agente de hotel homologado, descobrir um externo com identidade verificável é o papel que o ANP reivindica. Antes da compra, uma camada de política avalia valor, fornecedor e escopo e devolve permitido, negado ou "requer aprovação".

Repare na ordem: descoberta e identidade antes, tarefa no meio, ferramentas na ponta, política atravessando tudo. As fronteiras entre camadas são onde as duas próximas seções moram.

7. Descoberta de agentes: o problema que ninguém resolveu sozinho

Os três protocolos vivos descobrem coisas diferentes. O MCP descobre capacidades de um servidor que você já conhece (server/discover, tools/list); a descoberta de servidores fica fora do protocolo, em um registro oficial de metadados que, em setembro de 2026, ainda se declara preview. O A2A descobre agentes por endereço: um GET em /.well-known/agent-card.json, um catálogo curado ou configuração direta. O ANP descobre agentes por domínio e por busca, com a identidade embutida no documento.

A Web humana foi de website a metadados, rastreador, índice e busca. Uma Web agentiva pode repetir o caminho: hoje pesquisamos informação; amanhã sistemas vão pesquisar quem sabe fazer o quê. Liu et al. (2025) já propõem uma Internet of Agents com uma suíte de protocolos, no plural (a sigla deles, ACPs, não tem relação com o ACP da IBM).

Só que descrição não é confiança, e Duan e Lu (2026) dizem o mesmo: a descoberta não pode depender só da autodescrição do agente e precisa de reputação ou de histórico de comportamento. Um Agent Card pode declarar a skill medical_diagnosis; uma ferramenta MCP pode se chamar transfer_money. Nada disso prova competência, reputação ou autorização. O Agent Card assinado (JWS, RFC 7515) e o DID (W3C, 2022) provam quem publicou a descrição, o que já é avanço; não provam que ela é verdadeira. A camada de reputação e proveniência que a Web montou em vinte anos ainda não existe para agentes.

8. Composition safety: a segurança não é aditiva

Suponha que o MCP seja seguro isoladamente e o A2A também. Não segue que MCP mais A2A seja seguro. Uma ferramenta devolve um resultado; o resultado passa pelo modelo; o modelo decide delegar; a delegação atravessa a fronteira A2A e vira instrução para outro agente. Uma injeção de prompt escondida no primeiro resultado (o ataque indireto descrito por Greshake et al., 2023) viaja pela cadeia inteira sem que nenhum protocolo, individualmente, tenha sido violado.

Zheng e Zhang (2026), no AgentRFC, dão nome ao fenômeno: composition safety, a propriedade de que garantias válidas para protocolos isolados continuem valendo quando eles são combinados por bridges, proxies ou um orquestrador compartilhado. Eles modelam formalmente o caso acima: com MCP e A2A ligados por um bridge compartilhado, uma injeção de prompt no MCP amplia a delegação A2A além do escopo original, e nenhuma análise isolada de um dos protocolos detecta a falha. O trabalho organiza os protocolos em seis camadas de segurança, do transporte à responsabilização, e conclui que só a segurança de transporte está consistentemente completa: as camadas superiores continuam subespecificadas em todos os protocolos. Ferrag et al. (2026) mapeiam ameaças que atravessam MCP, A2A e ANP (injeção de prompt, envenenamento de cadeia de suprimentos, roubo de token, replay) e outras específicas de cada um: falsificação de descoberta (Agent Card forjado) faz sentido onde há discovery entre agentes, não em uma interface só de ferramentas, e a mitigação que eles listam, respostas de descoberta assinadas, é o que o Agent Card assinado do A2A 1.0 entrega.

As especificações sabem disso. O MCP declara que descrições do comportamento das ferramentas, como as anotações, "devem ser consideradas não confiáveis, a menos que obtidas de um servidor confiável" e proíbe o servidor de repassar tokens que não foram emitidos para ele; o A2A escolheu execução opaca para que um agente não precise confiar no interior do outro. São defesas por protocolo. A costura entre eles, o ponto em que um resultado MCP vira uma mensagem A2A, não pertence a nenhuma especificação, e é lá que a pergunta "isso é permitido?" precisa ser respondida. Cada protocolo cria as fronteiras de confiança que sua função exige; a pilha inteira cria fronteiras que nenhum protocolo vê.

9. O que muda para quem constrói

Primeiro: escolha por eixo, não por sigla. Se a capacidade necessária é uma função com entrada e saída definidas, é MCP; se é uma entidade que mantém tarefa, pede informação no meio e devolve artefatos, é A2A; se é um desconhecido em rede aberta com identidade a verificar, é território ANP, ainda pouco povoado. O agente de compras da abertura usa os três; isso não é indecisão, é arquitetura.

Segundo: projete servidores MCP sem estado. Quem dependia de Mcp-Session-Id para guardar contexto precisa migrar para identificadores explícitos, e quem usava Sampling ou Roots tem pelo menos doze meses para sair (janela mínima). Terceiro: no A2A, publique o Agent Card assinado e declare as extensões por URI; é o que permite a um cliente rejeitar um cartão adulterado antes da primeira mensagem. Quarto: coloque a política na costura, não dentro dos protocolos. Um gateway que intercepta a transição MCP → decisão → A2A é o lugar natural para aplicar "permitido, negado, requer aprovação" com registro de quem, o quê e em que contexto.

Quinto: interoperabilidade reduz lock-in, não o elimina. Protocolo aberto permite trocar o modelo sem trocar o MCP, ou o framework sem trocar o A2A; a organização continua dependente de modelos, nuvem, observabilidade e identidade. E conseguir enviar uma mensagem não significa que os dois lados compartilhem o mesmo entendimento, como já discutimos em interoperabilidade não é apenas conectar APIs: sintaxe, semântica, operação e governança são quatro perguntas, e, na minha leitura, os protocolos deste ensaio respondem bem à primeira, razoavelmente à terceira e quase nada às outras duas.

Uma posição, para fechar

"Quem será o HTTP dos agentes?" é uma pergunta atraente e errada. A Web não tem só HTTP; tem naming, transporte, identidade, descoberta e semântica de aplicação, cada um em seu protocolo. A Internet dos Agentes terá uma lista igualmente longa, de identidade a pagamento. Nenhuma especificação será ótima em tudo, e a que tentar será pesada demais para ser adotada.

Minha leitura do momento: MCP e A2A já se comportam como a dupla estável da pilha, um vertical e outro horizontal, ambos na mesma fundação, com a complementaridade escrita na especificação de um e no anúncio do outro. Onde houve competição de verdade, o caso ACP, ela durou pouco e acabou em fusão, e isso deve se repetir com quem tentar reocupar o eixo horizontal. ANP é a aposta em descentralização: sua tese sobre identidade está certa, sua adoção não foi provada, e é provável que suas ideias cheguem à pilha mais por absorção (DIDs em Agent Cards, well-known de descoberta) do que por vitória. O que falta não é protocolo. É a camada que a Web demorou duas décadas para montar: identidade que prova, reputação que acumula, política que decide e auditoria que responsabiliza, funcionando nas costuras onde a composição hoje é cega.

Foi da composição de protocolos especializados que nasceu a Internet que conhecemos. A próxima pode ser construída para conectar agentes, conhecimento e capacidade de ação; mas só valerá o nome quando descobrir um agente e confiar nele deixarem de ser a mesma operação.

Referências

1. Model Context Protocol. Specification, revision 2026-07-28; Key Changes; Authorization; Extensions Overview; Governance. Model Context Protocol a Series of LF Projects, LLC, 2026. modelcontextprotocol.io/specification/2026-07-28 · changelog · authorization · extensions · governance. Acesso em 18 set. 2026.
2. A2A Protocol Community. Agent2Agent (A2A) Protocol Specification, v1.0.0. The Linux Foundation, 2026. a2a-protocol.org/latest/specification/; A2A Protocol Ships v1.0, 12 mar. 2026, a2a-protocol.org; A New Chapter for A2A: Joining the Agentic AI Foundation, 27 ago. 2026, a2a-protocol.org. Acesso em 18 set. 2026.
3. Blair, K.; Segal, T. ACP Joins Forces with A2A Under the Linux Foundation's LF AI & Data. LF AI & Data, 29 ago. 2025. lfaidata.foundation. Repositório arquivado em 27 ago. 2025: github.com/i-am-bee/acp. Acesso em 18 set. 2026.
4. Agent Network Protocol. ANP 1.1 Specifications: did:wba Method, Agent Description Protocol, Agent Discovery Protocol. 2026. agent-network-protocol.com · repositório. Acesso em 18 set. 2026.
5. Sporny, M.; Guy, A.; Sabadello, M.; Reed, D. (eds.). Decentralized Identifiers (DIDs) v1.0: Core architecture, data model, and representations. W3C Recommendation, 19 jul. 2022. www.w3.org/TR/2022/REC-did-core-20220719/. Acesso em 18 set. 2026.
6. Jones, M.; Bradley, J.; Sakimura, N. JSON Web Signature (JWS). RFC 7515, IETF, 2015. doi.org/10.17487/RFC7515
7. FIPA — Foundation for Intelligent Physical Agents. FIPA Communicative Act Library Specification (SC00037J) e FIPA ACL Message Structure Specification (SC00061G). Standard, 3 dez. 2002. Cópias no Internet Archive: SC00037J · SC00061G. Acesso em 18 set. 2026.
8. Smith, R. G. The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver. IEEE Transactions on Computers, v. C-29, n. 12, p. 1104–1113, 1980. doi.org/10.1109/TC.1980.1675516
9. Duan, Q.; Lu, Z. AI Agent Communications in the Future Internet—Paving a Path Toward the Agentic Web. Future Internet, v. 18, n. 3, 171, 2026. doi.org/10.3390/fi18030171
10. Yang, Y.; Chai, H.; Song, Y. et al. A Survey of AI Agent Protocols. arXiv:2504.16736, 2025. arxiv.org/abs/2504.16736
11. Ehtesham, A.; Singh, A.; Gupta, G. K.; Kumar, S. A Survey of Agent Interoperability Protocols: Model Context Protocol (MCP), Agent Communication Protocol (ACP), Agent-to-Agent Protocol (A2A), and Agent Network Protocol (ANP). arXiv:2505.02279, 2025. arxiv.org/abs/2505.02279
12. Chang, G.; Lin, E.; Yuan, C. et al. Agent Network Protocol Technical White Paper. arXiv:2508.00007, 2025. arxiv.org/abs/2508.00007
13. Liu, J.; Yu, K.; Chen, K. et al. ACPs: Agent Collaboration Protocols for the Internet of Agents. arXiv:2505.13523, 2025. arxiv.org/abs/2505.13523
14. Greshake, K.; Abdelnabi, S.; Mishra, S. et al. Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (AISec '23), p. 79–90, 2023. doi.org/10.1145/3605764.3623985 (arXiv:2302.12173)
15. Zheng, S.; Zhang, Q. AgentRFC: Security Design Principles and Conformance Testing for Agent Protocols. arXiv:2603.23801, 2026. arxiv.org/abs/2603.23801
16. Ferrag, M. A.; Tihanyi, N.; Hamouda, D. et al. From prompt injections to protocol exploits: Threats in LLM-powered AI agents workflows. ICT Express, v. 12, n. 2, p. 353–383, 2026. doi.org/10.1016/j.icte.2025.12.001