O que é o protocolo A2A (Agent2Agent)? Guia 2026

A divisão de papéis que o próprio A2A declara em relação ao MCP é: "o MCP é vertical e aprofunda um único agente; o A2A é horizontal e conecta agentes através de fronteiras." No A2A, a parte chamada é um agente "opaco": ele raciocina por conta própria e guarda o próprio estado, o chamador não vê quais modelos ou ferramentas ele usa internamente, e as duas partes interagem em várias rodadas apenas pelo ciclo de vida da tarefa (Task). Documentos oficiais de Taiwan também já tratam do A2A: o Manual de Referência de Aplicações de Inteligência Artificial no Setor Público V1.0 do Ministério de Assuntos Digitais (data de disponibilização registrada no documento: 115-01-28) tem, na página 14, a subseção "A2A: protocolo de comunicação entre agentes de IA", explicando que ele se concentra na comunicação "cliente–remoto".

A governança do A2A passou por três fases. Em 2025-06-23 a Linux Foundation anunciou que assumiria o projeto, com AWS, Cisco, Google, Microsoft, Salesforce, SAP e ServiceNow como membros fundadores; em 2025-08-29 o ACP, liderado pela IBM, foi incorporado ao A2A e teve seu desenvolvimento encerrado. O poder de decisão efetivo está em um Comitê Diretivo Técnico (TSC) de 9 assentos, um por empresa: Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP, IBM e Bloomberg. As propostas são votadas com gitvote em issues do GitHub marcadas como TSC Review; por exemplo, a #1942, que consolidou 41 issues nos oito temas da v1.1, foi aprovada em 2026-06-25 por 5 votos a favor e 0 contra (limiar de 51%).

Em agosto de 2026, o A2A entrou na Agentic AI Foundation (AAIF) como projeto em estágio Growth Stage, passando a pertencer à mesma fundação que o MCP. As fontes divergem quanto à data de adesão: o blog da AAIF e a Axios indicam 2026-08-17, o blog oficial do A2A e a página da especificação indicam 2026-08-27, e a reportagem da Forbes é de 08-19. Uma possibilidade é que 08-17 seja o anúncio público da fundação e 08-27 a publicação do próprio projeto, mas nenhuma fonte confirma essa explicação; este artigo apresenta as duas datas lado a lado, sem escolher uma pelo leitor. A Diginomica conta o A2A como o 5º projeto hospedado pela AAIF, sendo os quatro anteriores MCP, goose, AGENTS.md e agentgateway; fontes secundárias também ressaltam que se trata apenas de um ajuste organizacional e que as duas especificações não foram fundidas.

O documento de governança do A2A estabelece que a composição do período de estabilidade será definida "18 meses após a criação". Contando a partir de junho de 2025, esse prazo vence por volta de dezembro de 2026, e o anúncio da AAIF não diz se o TSC será reorganizado — isto é uma inferência, indicando que a composição do TSC pode mudar em breve e merece acompanhamento.

Todos os métodos da A2A v1.0 foram renomeados: message/send virou SendMessage, message/stream virou SendStreamingMessage, tasks/resubscribe virou SubscribeToTask, e foi adicionado o ListTasks. Os caminhos REST passaram a seguir o estilo AIP, por exemplo POST /tasks/{id}:cancel, e o prefixo /v1 foi removido. O formato de erro HTTP trocou o application/problem+json da RFC 9457 por google.rpc.Status, com reason em maiúsculas separadas por sublinhado (por exemplo, TASK_NOT_FOUND) e domain fixo em "a2a-protocol.org". As notas de pesquisa avaliam que essa revisão equivale a remodelar o A2A no estilo do guia de design de APIs do Google — isto é uma inferência.

A mudança incompatível mais importante no modelo de dados é o achatamento do Part. TextPart, FilePart, DataPart e o campo discriminador kind foram removidos; agora um mesmo Part contém apenas um entre text, raw (bytes), url e data, e o tipo é identificado pelo campo presente, e não mais pela leitura de kind; mimeType foi renomeado para mediaType, e file.fileWithUri passou a ser url. Relatos da comunidade apontam que muitos parsers ainda leem part.kind, a causa mais comum de falhas de interoperabilidade entre 0.3 e 1.0. O Agent Card passou a ter supportedInterfaces[] como núcleo: cada interface traz seus próprios url, protocolBinding, protocolVersion e um tenant opcional; o cliente escolhe pela ordem do array e SHOULD implementar fallback.

A negociação de versão tem um padrão pouco notado: se o cabeçalho A2A-Version vier vazio, ele é tratado como 0.3. O cliente envia apenas Major.Minor e, se o servidor não suportar, responde com −32009 VersionNotSupportedError; um mesmo agente pode listar em supportedInterfaces interfaces com protocolVersion diferentes, permitindo a convivência de 0.3 e 1.0. A migração oficial tem três fases: primeiro conseguir interpretar os dois formatos, depois emitir 1.0 e ler 0.3 e, por fim, manter apenas 1.0. Atlassian Forge e MuleSoft já publicaram guias de migração 0.3→1.0, o que mostra que alguém está de fato pagando o custo das mudanças incompatíveis.

A semântica das tarefas tem alguns detalhes que só aparecem lendo a especificação inteira. O taskId é sempre gerado pelo servidor; se o contextId vier do cliente, o agente só pode aceitá-lo ou rejeitá-lo, sem gerar outro; quando taskId e contextId não são consistentes, o agente MUST rejeitar. Enviar mensagens a uma tarefa em um dos quatro estados terminais — COMPLETED, FAILED, CANCELED, REJECTED — retorna UnsupportedOperationError; para dar continuidade, abre-se uma nova tarefa no mesmo context e vincula-se à original com referenceTaskIds. A máquina de estados tem dois estados de "interrupção": TASK_STATE_INPUT_REQUIRED e TASK_STATE_AUTH_REQUIRED, e um SendMessage bloqueante também retorna ao encontrar um estado de interrupção.

As garantias de streaming e notificações push são mais fracas do que a maioria imagina. A flag final do TaskStatusUpdateEvent foi removida na 1.0, e o "fechamento da conexão" passou a indicar o fim do stream; assim, para o cliente, uma queda no meio da tarefa e a conclusão da tarefa parecem iguais, e é preciso chamar GetTask ou SubscribeToTask para distinguir; a especificação também não tem mecanismo de retomada por ID de evento, o que foi listado como tema #1986 da v1.1. A notificação push envia um StreamResponse por HTTP POST ao webhook do cliente, com Content-Type application/a2a+json; a especificação exige apenas que o agente tente enviar ao menos uma vez, com timeout que SHOULD ficar em cerca de 10–30 segundos, e o receptor SHOULD processar de forma idempotente e MUST conferir o taskId. Em outras palavras, o push é "pelo menos uma vez, sem garantia de ordem e com payload sem assinatura" — conclusão inferida a partir da especificação. A idempotência também ficou pela metade: o SendMessage "pode" deduplicar por messageId, mas não é obrigatório.

Há duas contradições entre fontes sobre datas e quantidades. Data de lançamento da v1.0: o CHANGELOG indica 2026-03-12, um artigo de revisão (arXiv:2507.10644 v4) indica janeiro de 2026, e o comunicado de primeiro aniversário da Linux Foundation só diz que a v1.0 é a primeira versão estável, sem data; este artigo adota a fonte primária, o CHANGELOG. Número de SDKs: a Linux Foundation disse em 2026-04 que havia 5 linguagens "production-ready", o anúncio oficial do A2A lista 6 — Python, Go, Java, JS, .NET e Rust —, mas o SDK Rust testado em detalhe é uma versão da comunidade.

No último ano ouviu-se muito que "com Tasks no MCP, o A2A deixa de ser necessário", mas a direção real da versão 2026-07-28 do MCP foi justamente a oposta. A versão 2025-11-25 do MCP de fato adicionou as Tasks experimentais (SEP-1686), voltadas a acompanhar requisições longas, polling e obtenção adiada de resultados, com estados (working, input_required, completed, failed, cancelled) que correspondem quase um a um aos do A2A. Mas a versão 2026-07-28 removeu a session e o handshake initialize, tornando o MCP stateless (SEP-2567, SEP-2575), tirou as Tasks do núcleo e as transformou na extensão oficial io.modelcontextprotocol/tasks (SEP-2663), substituiu as requisições iniciadas pelo servidor pelo MRTR (InputRequiredResult com inputResponses anexados no reenvio) (SEP-2322) e marcou Sampling, Roots e Logging como deprecated (SEP-2577).

Essas mudanças significam que os mantenedores do MCP abandonaram deliberadamente a rota de agentização em que "o servidor pega emprestado o raciocínio do LLM do chamador" — isto é uma inferência. Se um servidor MCP quiser raciocinar por conta própria, precisa trazer seu próprio modelo, e nesse ponto ele já é, na prática, um agente opaco, apenas com aparência de ferramenta. A Task do MCP trata da "obtenção adiada de uma chamada de ferramenta longa"; a Task do A2A trata de "colaboração em várias rodadas em que ambas as partes podem fazer perguntas", além de descoberta via Agent Card, declaração de habilidades e streaming de artifacts. Também há cenários de falha no sentido inverso: forçar o ciclo de vida Task, Message, Artifact em consultas determinísticas, como cotações e alíquotas, aumenta latência e custo de implementação, e o LLM do chamador deixa de receber o schema detalhado da ferramenta — também uma inferência. As notas de pesquisa não encontraram registros reais de incidentes do tipo "falha ao usar MCP para agente-a-agente" ou "falha ao embrulhar ferramentas com A2A".

Quanto à adoção, além do número de tópicos no GitHub, uma comparação não sistemática no PyPI mostra cerca de 10,9 milhões de downloads do SDK A2A contra cerca de 257 milhões do SDK MCP. Fontes secundárias apontam que o endpoint UCP da Shopify usa o MCP como camada de transporte, ou seja, os principais agentes de comércio se conectam via MCP. Nas plataformas de nuvem: o AWS AgentCore Runtime pode implantar servidores A2A (JSON-RPC, POST /, porta 9000, OAuth 2.0 ou SigV4); o suporte a A2A no Microsoft Foundry entrou em public preview em junho de 2026; o Google Agent Registry lê cards well-known, mas a descoberta automática se limita ao mesmo projeto. Entre os principais fornecedores de modelos verificados nas notas de pesquisa, a Anthropic ainda não tem suporte nativo a A2A, e a issue #104852 relacionada ao Claude Code só foi aberta no fim de outubro de 2026.

Na prática, a escolha é simples: para que um assistente de IA chame suas funções determinísticas (cotação, consulta de alíquotas, rastreamento de envios), use MCP; o A2A só é necessário quando dois agentes, cada um com raciocínio próprio e de organizações diferentes, precisam colaborar em várias rodadas. O MCP público da HowBridge pertence ao primeiro caso; a forma de conexão está no tutorial de MCP de consolidação no site.

O Agent Card do A2A declara, em securitySchemes, um entre cinco esquemas de autenticação: API Key, HTTP Auth, OAuth2, OIDC e mTLS. A v1.0 removeu os fluxos implicit e password do OAuth, adicionou o Device Code e recomenda PKCE para todos os clientes. A especificação exige que o servidor "MUST authenticate every incoming request", mas a autorização é implementation-specific, e a obtenção de credenciais deve ocorrer por canal out-of-band; quando a tarefa entra no estado AUTH_REQUIRED, a especificação ressalta que "Agents MUST NOT treat the state transition alone as authorization". A seção 13, "Considerações de segurança", não menciona prompt injection, delegação ou token exchange, nem OpenTelemetry, e não traz requisitos específicos de isolamento entre tenants. Uma análise da Semgrep na época da v0.3 apontou que o A2A "supports but does not enforce Agent Card signing", que a duração e o scope dos tokens não são restringidos pelo protocolo e que uma mesma tarefa pode ter vários streams paralelos, de modo que um session token roubado pode escutar silenciosamente o stream da vítima.

Mesmo assinando o Agent Card, hoje não há garantia de verificação entre SDKs diferentes. A especificação manda primeiro canonicalizar o card segundo a RFC 8785 (JCS), excluindo o campo signatures, e depois aplicar JWS; o protected header MUST conter alg e kid. A issue #2122 (aberta em 2026-08-10 e ainda não encerrada até 2026-10-31) registra diferenças medidas: o a2a-python 1.1.2 e o @a2a-js/sdk 1.0.1 produzem bytes canonicalizados diferentes — o Python escapa caracteres não ASCII como \uXXXX, ordena por code point em vez de unidades UTF-16 e escreve números como 1e-06, enquanto o ECMAScript escreve 0.000001; a especificação exige que campos REQUIRED apareçam mesmo com valor padrão, mas o proto3 não tem o conceito de presence, e description: "" e skills: [] acabam descartados; o typ também é ambíguo. O PR #2319 corrigiu os exemplos da especificação, mas a saída do a2a-go continua diferente. Outra limitação: uma assinatura válida só prova que o card não foi adulterado, não prova a identidade de quem o emitiu, e a comunidade também observa que a norma não tem nenhum mecanismo para vincular o card ao ambiente de execução que efetivamente faz a chamada.

Alguns ataques funcionam mesmo em total conformidade com a especificação. O A2ABreak (arXiv:2609.10871, v3 de 2026-10-24) usou um LLM para extrair da especificação em linguagem natural 37 estados, 76 transições e 929 enunciados formalizados, encontrando 11 novas vulnerabilidades, todas "exploráveis por um adversário em conformidade com a norma, sem necessidade de qualquer defeito de implementação" — por exemplo, injeção de context entre clientes por falta de proteção do context identifier, perda de identidade após vários saltos na cadeia de delegação e agentes que alegam capacidades não comprovadas. Um estudo sobre colisão de nomes (arXiv:2609.27624) aponta que a norma define name como "human-readable metadata, not as a stable identity" e não estabelece regras de colisão; das 7 implementações de código aberto acompanhadas pelo autor, 6 integrações do tipo cliente enviariam requisições a endpoints controlados pelo atacante, e o autor caracteriza isso como uma classe recorrente de vulnerabilidade de implementação, e não como vulnerabilidade genérica do protocolo. A Unit 42, da Palo Alto Networks, fez uma prova de conceito de session smuggling com o Google ADK, mostrando um agente malicioso que usa "perguntas de esclarecimento" para extrair instruções de sistema e induz o cliente a chamar buy_stock, comprando 10 ações sem autorização; a Unit 42 deixou claro que não se trata de vulnerabilidade do protocolo, que qualquer protocolo com estado e várias rodadas pode ser afetado e que não observou exploração em ambiente real. A comunidade também relatou que um servidor malicioso pode esconder instruções nos campos description ou skills do Agent Card, que o LLM hospedeiro acaba executando como instruções.

As evidências acadêmicas sobre ataques entre agentes também sustentam que "a confiança entre agentes não pode ser presumida". Triedman et al. (COLM 2025) mostraram que conteúdo web malicioso pode sequestrar o fluxo de controle de sistemas multiagente; com o GPT-4o, a execução de código arbitrário teve sucesso em 58%–90% dos testes. A revisão revisada por pares de Ferrag et al. na ICT Express (2026) organiza as ameaças desde a prompt injection até ataques na camada de protocolo, cobrindo MCP e A2A.

Os números de CVE da tabela abaixo foram copiados exatamente das notas de pesquisa. As próprias notas registram que esses números são incomuns e que algumas entradas aparecem em uma única base de dados (por exemplo, o CVE-2026-90790 não tem GHSA correspondente no repositório a2a-python e só aparece no OpenCVE). As consultas aos repo advisories de a2a-js, a2a-go e a2a-dotnet voltaram vazias, mas isso pode ser falta de permissão e não significa necessariamente ausência de vulnerabilidades. Da tabela podem-se extrair três lições — o que segue é inferência: primeiro, o Agent Card é uma entrada controlável pelo atacante, a ponto de até o nome do header poder ser definido pela outra parte; segundo, a norma só diz "SHOULD validar a URL do webhook", e por isso SDKs de duas linguagens tiveram SSRF; terceiro, a norma diz que "a autorização é definida pela implementação", o SDK Java mais popular não aplicava autorização por padrão, e a correção ainda foi contornada por diferenças da plataforma Android.

O problema da identidade de agentes está se dividindo, fora do A2A, em três camadas. A primeira é a identidade de workload, que responde "que programa é este": os autores do draft-klrc-aiagent-auth vêm de empresas como Amazon, Zscaler, Ping Identity e OpenAI; o rascunho foi adotado pelo grupo de trabalho IETF WIMSE e substituído pelo draft-ietf-wimse-aims, seguindo a linha de reutilizar a família WIMSE e OAuth 2.0 existente, "sem inventar um novo protocolo". A segunda é autorização e delegação, que responde "em nome de quem e o que pode fazer": o exemplo da Ping Identity registra todo o caminho de delegação com a claim act do token exchange da RFC 8693 e limita o próximo salto com may_act; mas a RFC 8693 foi projetada para trocas entre servidores "depois que o consentimento já ocorreu" e não cobre nativamente o consentimento do usuário a um agente específico.

A terceira é a identidade verificável externamente, que responde "como um desconhecido pode confiar nele". O Cloudflare Web Bot Auth assina requisições HTTP com Ed25519 e RFC 9421, mas a Cloudflare hoje não verifica o nonce, e a proteção contra replay depende principalmente de uma validade curta, de cerca de 1 minuto; o rascunho ANS v2 valida domínios com ACME, em três níveis: Bronze, Silver (com DANE) e Gold (com log de transparência SCITT). O A2A só toca na assinatura do card nessa camada, e a assinatura é opcional. Produtos comerciais já chegaram antes: o Okta Agent SSO foi lançado oficialmente em 2026-08-24 e usa ID-JAG; o Microsoft Entra Agent ID não suporta ID-JAG nativamente, e as fontes divergem sobre sua data de lançamento oficial (2026-04 ou 2026-05). Por isso, em A2A entre empresas, as duas partes provavelmente terão de converter tokens em suas respectivas fronteiras — isto é uma inferência.

O nível governamental também está preenchendo essa lacuna. O CAISI do NIST, nos Estados Unidos, anunciou em 2026-02-17 a AI Agent Standards Initiative, com três pilares: padrões liderados pela indústria, protocolos abertos liderados pela comunidade e pesquisa em segurança e identidade de agentes; mas a página da iniciativa usa apenas termos genéricos como "interoperable agent protocols", sem citar A2A ou MCP. O projeto "Software and AI Agent Identity and Authorization" do NIST NCCoE publicou em 2026-09-29 um resumo dos comentários ao documento conceitual, com mais de 600 entidades ou pessoas respondendo. O post de blog do NIST de 2026-10-27, "Design Tenets for Agent Identity Management Systems", propõe 10 princípios de design, entre eles: agentes com identidade própria, vinculada a quem os iniciou e com permissões cada vez mais restritas a cada delegação; privilégio mínimo; autorizações de curta duração e revogáveis; intervenção humana acionada conforme o risco; mandates assinados para delimitar o escopo de ação; e registros imutáveis. Ele é um post de blog, não um padrão formal.

A pesquisa acadêmica segue a mesma direção. South et al. propõem estender o OAuth 2.0/OIDC com credenciais específicas para agentes e criar cadeias de delegação auditáveis; uma versão de posicionamento do mesmo estudo foi incluída no ICML 2025 Position Paper Track. Chan et al., no FAccT 2024, defendem três tipos de medidas para aumentar a visibilidade de agentes: identificadores de agente, monitoramento em tempo real e logs de atividade.

O AP2 já não é a versão que todos lembram de 2025. A v0.2.0 mudou o mecanismo para Checkout Mandate e Payment Mandate, cada um com duas fases, open e closed, implementados com SD-JWT; o open mandate guarda a chave pública do agente na claim cnf. A principal novidade é o fluxo Human-Not-Present: o usuário primeiro assina o open mandate com sua própria chave em uma interface confiável, registrando as restrições, e depois o agente assina o closed mandate com a chave do agente; as duas partes são vinculadas por sd_hash, e o comerciante ou o provedor de credenciais pode devolver unresolved_constraint, trazendo o fluxo de volta para "pessoa presente". A especificação também recomenda que o comerciante assine o Checkout JWT com assinatura não determinística (ECDSA), e não com Ed25519, para evitar ataques de rainbow table. O ponto mais crítico é que a especificação AP2 coloca tratamento, guarda e consulta de disputas como out of scope, comprometendo-se apenas a fornecer uma trilha de auditoria criptográfica irrefutável. As notas de pesquisa também observam que a forma de extensão recomendada pela especificação AP2 são os extension points do UCP, enquanto o A2A nem é discutido no corpo da especificação; o posicionamento do AP2 está migrando de "extensão do A2A" para "camada de segurança dentro de protocolos de comércio" — isto é uma inferência.

Extensões de pagamento se acoplam ao A2A pelo próprio mecanismo de extension do A2A: são declaradas em AgentCapabilities como AgentExtension (uri, description, required, params), e o cliente pede a ativação pelo cabeçalho A2A-Extensions; as extensões não podem alterar estruturas de dados centrais nem adicionar valores de enum, só podem operar via metadata, mudanças incompatíveis exigem uma nova URI e, diante de versão não suportada, "MUST NOT fall back". O a2a-x402 (spec v0.1) é uma extensão desse tipo: o comerciante envia payment-required, o cliente assina e devolve payment-submitted, e o comerciante liquida on-chain e responde payment-completed.

O número de transações x402 vem principalmente de volume artificial. A Chainalysis contabiliza mais de 100 milhões de transações x402 acumuladas na rede Base até o primeiro trimestre de 2026, mas o salto no quarto trimestre de 2025 foi "em grande parte impulsionado por meme coin farming", e a retenção semanal caiu de 87% para 5%. A Coinbase afirmou no fim de abril de 2026 cerca de 165 milhões de transações e cerca de US$ 50 milhões acumulados — alegação do fornecedor; a Artemis considera que mais de 95% são sinais de protocolo ou testes; e outro site de acompanhamento estima o volume de comércio real em cerca de US$ 28 mil por dia.

A prática real das bandeiras de cartão e das plataformas é "aceitar vários protocolos, com autenticação forte com a pessoa presente como válvula de segurança". Em março de 2026, a OpenAI recolheu o Instant Checkout dentro do ChatGPT de volta para o modelo de Apps dos comerciantes; nas palavras de um porta-voz, "Instant Checkout is moving to Apps". A Visa anunciou em 2026-07-02 que agentes já haviam concluído compras reais na Europa, com mais de 30 emissores parceiros, e todas as transações usaram Payment Passkeys para cumprir a autenticação forte do cliente (SCA). O marco de responsabilidade continua vazio: a Chargebacks911 alerta que a infraestrutura de disputas e responsabilidade está "largely unaddressed"; a análise da Taylor Wessing indica que, no marco da União Europeia, uma compra feita por agente que ultrapasse as condições definidas pelo cliente seria, em princípio, considerada transação não autorizada; Ant International, Visa e Mastercard só em 2026-09-10 começaram a explorar um marco interoperável de Know-Your-Agent. O PSD3/PSR da UE só chegou até a posição em primeira leitura aprovada pelo Conselho em 2026-10-29, ainda não publicada no Official Journal, e uma busca por palavras-chave na exposição de motivos do PSR do Conselho não encontrou dispositivos sobre IA ou agentes autônomos; o CFPB dos EUA também não tem orientação sobre pagamentos por agentes.

A pesquisa acadêmica aponta outro ponto cego. Debi et al. (IEEE IMNS 2026) fizeram testes de red team com agentes de compras AP2: prompt injection indireta e direta conseguiram manipular a ordenação de produtos e extrair dados sensíveis do usuário, mostrando que mandates assinados não protegem o raciocínio que ocorre antes da assinatura; Jiang et al. (arXiv:2609.00060) usaram o Tamarin para uma análise formal de x402, MPP, ACP e AP2, apontando as dependências de segurança criadas pela dispersão de intenção, poder de delegação e liquidação entre várias partes. A agentização no setor de logística segue hoje pelo MCP: o servidor MCP da Flexport permite que o assistente de IA do cliente reserve espaço com tarifas negociadas e obtenha um booking ID. As notas de pesquisa não encontraram nenhum caso de liquidação de frete via AP2 ou x402.

O comunicado de primeiro aniversário da Linux Foundation, de 2026-04-09, diz que o A2A tem mais de 150 organizações apoiadoras e implantações em produção em cadeia de suprimentos, finanças, seguros e operações de TI; isso é uma alegação do fornecedor: o comunicado não nomeia nenhum usuário nem apresenta processos ou indicadores de resultado. Os exemplos mais citados — o artigo sobre o Microsoft Agent Framework .NET e o codelab de purchasing concierge do Google — são exemplos de código, não relatórios de implantação. A Tyson Foods costuma ser divulgada como caso A2A de cadeia de suprimentos, mas o apis.io dá ao seu Agent Card A2A a nota 0/8, e o que ela oferece aos parceiros comerciais continua sendo EDI e API.

A contraprova mais direta são os testes reais. Em abril de 2026, um autor selecionou em registros públicos 50 agentes que diziam suportar A2A: apenas cerca de 0–2 ofereciam um card válido no caminho well-known, e 0 responderam corretamente a uma task; o mesmo autor enviou 24 requisições a 12 organizações em 2026-09-09 e 36 requisições a 18 organizações em 2026-10-27, obtendo 0 cards nas duas vezes. A amostra foi escolhida pelo autor e não é um censo, mas a direção é consistente. O que realmente está em operação é a interoperabilidade dentro de uma mesma plataforma de nuvem: AWS AgentCore, Microsoft Foundry e Google Agent Registry.

As evidências sobre arquiteturas multiagente em si também são desfavoráveis ao A2A entre organizações. O MAST (NeurIPS 2025 Datasets & Benchmarks Track) analisou 1.642 traces de execução e identificou 14 modos de falha, agrupados em três categorias: design do sistema, desalinhamento entre agentes e verificação de tarefas; as taxas de falha de 7 sistemas multiagente de código aberto de ponta ficaram entre 41% e 86,7% (os autores alertam que benchmarks diferentes não são diretamente comparáveis). "Towards a Science of Scaling Agent Systems", de autores do Google Research, do MIT e outros, testou 180 configurações na v1/v2 e na versão do blog do Google: em multiagentes independentes o erro foi amplificado 17,2 vezes, e em multiagentes com coordenação central, 4,4 vezes; em tarefas de raciocínio sequencial, todas as variantes multiagente pioraram 39%–70%; a v3, de 2026-04-08, ampliou o estudo para 260 configurações e 6 benchmarks e manteve as conclusões de 17,2 e 4,4 vezes. O blog de engenharia da Anthropic (não é artigo revisado por pares) relata que seu sistema de pesquisa multiagente supera em 90,2% o Claude Opus 4 com agente único, mas consome cerca de 15 vezes mais tokens que uma conversa comum, e aponta como inadequados os domínios "em que todos os agentes precisam compartilhar o mesmo contexto ou em que há muitas dependências entre agentes". O A2A entre organizações reúne justamente essas condições desfavoráveis: as partes não compartilham contexto, não há verificador comum e os processos comerciais (cotação → pedido → pagamento → expedição) são sequenciais — isto é uma inferência.

As lacunas de engenharia são ainda maiores que as da especificação. Quando o A2A delega a um próximo agente, o trace se quebra: o SDK Python só cria spans localmente e não há forma padrão de propagar o W3C Trace Context entre agentes (Issue #2103). O SDK Rust da comunidade relatou 7 falhas no TCK, que, após comparação, foram atribuídas a defeitos da própria suíte de testes; o mesmo relato diz que os SDKs JS, Go e Java passaram 21/21 nos dois bindings. O tráfego de agentes do lado do consumidor também ainda é pequeno: a HUMAN Security contabilizou crescimento anual de 7.851% no tráfego de agentes em 2025, mas só 2,3% ocorreu em páginas de checkout; fontes secundárias citam dados do Cloudflare Radar de agosto de 2026 segundo os quais bots de IA respondem por cerca de 7% das requisições HTML, e a "ação em tempo real em nome do usuário" representa só 5,8% disso; multiplicando os dois, chega-se a cerca de 0,4% — essa multiplicação é uma inferência ainda não confirmada com os dados originais. A Akamai alerta que sites de e-commerce apenas monitoram mais de 90% dos bots de IA, enquanto a atividade de agentes fraudulentos cresce. As notas de pesquisa não encontraram evidências de agentes pessoais como ChatGPT, Gemini ou Claude chamando agentes de empresas comuns via A2A, mas isso é apenas ausência de evidência, não confirmação oficial.

Já as entrevistas de governos e organismos internacionais mostram que a demanda é real. O OECD Artificial Intelligence Papers No. 65 registra, na página 16, que os profissionais entrevistados preferem protocolos abertos e apontam protocolos de comunicação agente a agente como o A2A como importantes impulsionadores da coordenação multiagente, ao mesmo tempo em que temem ficar presos ao ecossistema de um único fornecedor.

Taiwan: a Lei Básica de Inteligência Artificial tem 20 artigos; o artigo 3 define inteligência artificial como "sistema com capacidade de operação autônoma", o que pode abranger agentes de IA, mas a palavra "agente" não aparece no texto; o artigo 4 lista sete princípios, entre eles autonomia e supervisão humanas, transparência e explicabilidade, e responsabilização; pelo artigo 16, o Ministério de Assuntos Digitais promove um marco de classificação de riscos alinhado ao cenário internacional; o artigo 17 exige que o governo defina a atribuição de responsabilidade e as condições de imputação para IA de alto risco e crie mecanismos de reparação, compensação ou seguro; o artigo 18 exige que os órgãos concluam os ajustes normativos em até dois anos após a entrada em vigor. Com base no artigo 16, o Ministério de Assuntos Digitais publicou em 115-07-07 o Marco de Classificação de Riscos de Inteligência Artificial v1.0 (ofício de estratégia digital nº 1150015933, com vigência imediata), cujo tipo de risco B6, "comportamento fora da autorização de agentes autônomos de IA", afirma: "sistemas multiagente têm maior probabilidade de, por acionamentos mútuos entre agentes, gerar reações em cadeia não previstas nem por desenvolvedores nem por usuários, dificultando que humanos intervenham e corrijam a tempo". Já as diretrizes de IA generativa para instituições de saúde, emitidas por ofício pelo Ministério da Saúde e Bem-Estar em 115-05-29, deixam claro que sistemas de agentes de IA "ainda não estão incluídos no âmbito destas diretrizes".

As leis já existentes em Taiwan também se aplicam a cenários com agentes. O artigo 4 da Lei de Proteção de Dados Pessoais estabelece que quem coleta, trata ou usa dados pessoais por encomenda é equiparado ao órgão contratante, no âmbito desta lei; portanto, confiar dados pessoais a um agente não isenta de responsabilidade só porque "é a IA que está fazendo"; o artigo 21 regula restrições à transferência internacional. Atenção: vários dispositivos alterados em 114-11-11 (incluindo a nova redação do artigo 21 e o novo artigo 20-1) já foram promulgados, mas ainda não estão em vigor; a data de vigência será fixada pelo Yuan Executivo. A Lei de Assinaturas Eletrônicas não menciona IA nem agentes; se uma assinatura feita por um agente pode ser presumida como assinatura do próprio titular não está previsto em lei, e este artigo não pode confirmá-lo.

China: a Administração Estatal de Regulação do Mercado e a Administração de Normalização da China aprovaram e publicaram em 2026-05-22, pelo Anúncio de Normas Nacionais nº 22 de 2026, a série GB/Z 185.1–185.7-2026 "Inteligência artificial — Interconexão de agentes", com 7 documentos técnicos orientativos (arquitetura geral, código de identidade, gestão de identidade, descrição de agentes, descoberta de agentes, interação entre agentes e chamada de ferramentas por agentes); a plataforma nacional de serviços públicos de informação sobre normas indica o status "vigente", o texto integral foi publicado em 2026-06-18, e a Administração Estatal de Regulação do Mercado realizou uma coletiva de imprensa temática em 2026-06-26. O nome do protocolo usado nos documentos oficiais é AIP (protocolo de interconexão de agentes); nenhuma das páginas oficiais encontradas menciona A2A ou MCP, e a compatibilidade entre eles não foi comprovada. Os Pareceres de Implementação sobre Aplicação Normatizada e Desenvolvimento Inovador de Agentes, emitidos em conjunto em 2026-05-08 pela Administração do Ciberespaço da China, pela Comissão Nacional de Desenvolvimento e Reforma e pelo Ministério da Indústria e Tecnologia da Informação, combinam em um só pacote a promoção do AIP, uma plataforma de registro de agentes e a identidade digital de agentes, e exigem que "as operações executadas por agentes não ultrapassem o escopo autorizado pelo usuário". Essa linha difere da posição da comunidade A2A de "não oferecer registro central oficial".

União Europeia: o AI Act (Regulation (EU) 2024/1689) entrou em vigor em 2024-08-01; as obrigações de modelos de IA de uso geral aplicam-se desde 2025-08-02, e a aplicação geral e as obrigações de transparência, a partir de 2026-08-02; as obrigações de alto risco foram adiadas pelo Regulation (EU) 2026/1744 (publicado no Official Journal em 2026-07-24): o anexo III para 2027-12-02 e o anexo I para 2028-08-02. Quanto ao PSD3 e ao PSR, o Conselho aprovou a posição em primeira leitura em 2026-10-29, ainda pendente da segunda leitura no Parlamento Europeu e não publicada no Official Journal.

Estados Unidos, Singapura e Reino Unido: CISA, NSA e outras agências dos Five Eyes publicaram em 2026-04-30/05-01 o documento "Careful Adoption of Agentic AI Services", recomendando limitar permissões de acesso e começar por casos de uso de baixo risco e não sensíveis; o CFPB dos EUA não tem orientação específica sobre pagamentos por agentes, e a proposta de regra interpretativa relacionada, de 2025, foi retirada em 2025-05-15. O Model AI Governance Framework for Agentic AI v1.5 da IMDA de Singapura (publicado em 2026-05-20 e atualizado em 06-05) cita diretamente, na seção 1.1.1, o A2A para comunicação entre agentes e o MCP para comunicação entre agentes e ferramentas, e aponta a delegação recursiva e a identidade entre organizações como lacunas atuais. A orientação da CMA do Reino Unido publicada em 2026-03-09 (atualizada em 10-30) afirma que "if an AI agent you use does something illegal, you are responsible", ou seja, as empresas respondem pelos atos ilícitos dos agentes que utilizam; a consulta pública do ICO do Reino Unido sobre IA agêntica encerra-se em 2026-11-20.

A issue #1942 consolidou 41 issues nos oito temas da v1.1; a memória de agentes entre tarefas (#893) ficou fora do escopo acompanhado. Mais reveladoras da direção do que a lista de temas são as issues com mais comentários: #1672, verificação de identidade de agentes no Agent Card (cerca de 658 comentários); #1829, assinatura de mensagens com Ed25519 e RFC 9421; #2028, delegação por actor-chain; #2121, propagação de custos e orçamento; #1815, uso do HTTP 402 para indicar "pagamento necessário". Todas são questões de confiança e comércio; somando-se o novo processo de governança de extensions, as notas de pesquisa avaliam que elas tendem a surgir como extensões, e não como alterações na especificação central — isto é uma inferência.

"Como um agente pessoal encontra o agente de uma empresa" ainda não tem resposta aberta implantada. A documentação oficial do A2A diz expressamente que registros centrais com curadoria estão fora do escopo do A2A; a proposta de Agent Registry da Discussion #741 se arrastou por muito tempo, e os revisores questionaram a premissa de que "os próprios provedores gerenciem seus registros". Para descobrir agentes a partir de um domínio, há no IETF quatro rascunhos individuais concorrentes: DNS-AID (usa registros SVCB apontando para /.well-known/agent-card.json), AID (consulta registros TXT _agent), ADP e DAN, nenhum ainda adotado por um grupo de trabalho; um rascunho de landscape de julho de 2026 também aponta que o namespace precisa de coordenação. Do lado do MCP, o MCP Registry continua em preview desde setembro de 2025 até hoje.

Auditoria e responsabilidade entre organizações também não têm marco. A especificação A2A só traz requisitos de nível SHOULD para registro de falhas de autenticação e limitação de taxa, e as fontes se contradizem sobre o status de estabilidade das convenções semânticas GenAI do OpenTelemetry. Com as ferramentas atuais, a menor unidade de auditoria que se pode guardar é, provavelmente: o taskId e o contextId do próprio lado, a impressão digital da assinatura do Agent Card da outra parte e a cadeia de delegação act do token apresentado pela outra parte, cada parte guardando os seus para conciliação posterior — isto é uma inferência. As notas de pesquisa também não encontraram nenhum estudo empírico de denial-of-wallet voltado a "esgotar o orçamento de LLM da outra parte".

O estado atual do A2A lembra o HTTP dos primeiros tempos: o formato já está padronizado, e a camada de confiança cada um ainda precisa completar por conta própria; a diferença é que, desta vez, a parte chamada raciocina sozinha e ainda pode ser convencida pela outra. Por isso, o gargalo não está na engenharia, e sim em "quem responde pelo comportamento do agente" — e essa questão hoje está distribuída entre o IETF (identidade), a FIDO Alliance (intenção de pagamento), as bandeiras de cartão (disputas) e os reguladores de cada país, fora do alcance do TSC do A2A. Daí se infere que, nos próximos anos, a forma mais provável de interoperabilidade de agentes entre empresas será "uma casca A2A envolvendo chamadas de ferramentas determinísticas": a parte chamada aparenta ser um agente, mas internamente é uma API, e o raciocínio de fato só acontece dentro da própria fronteira de confiança.

As orientações governamentais seguem a mesma direção. CISA, NSA e outras agências dos Five Eyes recomendam começar por casos de uso de baixo risco e não sensíveis e limitar permissões de acesso; o marco da IMDA de Singapura coloca "fazer as pessoas assumirem responsabilidade efetiva" e os controles técnicos como dimensões centrais; o Ministério de Assuntos Digitais de Taiwan classifica as reações em cadeia por acionamentos mútuos entre agentes como risco B6; e a CMA do Reino Unido afirma claramente que as empresas respondem pelos atos ilícitos dos agentes que usam.

A tabela abaixo classifica as opções de adoção para empresas em geral conforme a força das evidências. "Fazer" significa baixo risco e retorno claro com as evidências atuais; "Pode fazer" significa baixo custo, mas sem casos medidos; "Adiar" e "Não fazer" trazem a justificativa e devem ser reavaliados quando surgirem as condições de gatilho.

As consultas centrais do e-commerce transfronteiriço e da logística — quanto custa o frete, quanto são os impostos, qual é a classificação tarifária e quais são as exigências de importação de um produto — já são cálculos determinísticos, exatamente o tipo de serviço de que agentes externos mais precisam e em que menos erram. A experiência do blog de engenharia da Anthropic é que reescrever a descrição de uma ferramenta reduziu em 40% o tempo de conclusão de tarefas dos agentes seguintes; a experiência da OpenAI ao devolver o Instant Checkout para os Apps dos comerciantes mostra que, no fim, a transação volta ao processo do próprio comerciante. Assim, a ordem de preparação deve ser: primeiro tornar as páginas e os dados estruturados legíveis, depois transformar as ferramentas determinísticas em MCP, incluir nas respostas das ferramentas uma URL de continuidade que leve a transação de volta ao próprio fluxo e, só por último, considerar um marcador A2A.

Um card marcador A2A significa publicar um card em /.well-known/agent-card.json, com skills correspondentes às ferramentas determinísticas já existentes de cotação, impostos e processos, que por trás chamam código diretamente, sem rodar LLM. A abordagem tem custo baixo e "valor de opção", mas ainda não há nenhum caso medido de pequena ou média empresa que tenha ganhado tráfego ou receita com isso — é uma inferência. Se for realmente abrir um endpoint A2A, o mínimo é: expor apenas habilidades somente leitura, não confiar em nenhum campo do card da outra parte, rejeitar IPs privados nas URLs de push e registrar taskId, contextId, identidade do chamador e traceparent.

O que a HowBridge faz hoje (tudo verificável na página de desenvolvedores da HowBridge): a HowBridge oferece um MCP público sem chave e sem OAuth (https://0523.tw/mcp/public), com 8 ferramentas somente leitura e idempotentes, cobrindo a apresentação da marca e dos serviços da HowBridge, a simulação de frete de consolidação China→Taiwan (marítimo expresso/aéreo), a simulação de impostos de importação em Taiwan, a busca de candidatos de classificação tarifária CCC pelo nome do produto, alíquotas e exigências de importação por código CCC, a taxa de excesso de dimensões na entrega dentro de Taiwan, e o fluxo de consolidação e as regras de declaração simplificada; o limite é de 120 chamadas por minuto por IP, e o servidor já está registrado no MCP Registry oficial (nome tw.0523/lucky-public); a resposta da simulação de frete inclui uma URL de continuidade (continue_url) para o usuário voltar ao site oficial e prosseguir. O MCP de membros (https://0523.tw/mcp) usa autorização OAuth 2.1 e oferece 6 ferramentas somente leitura, que só leem faturas, pacotes, pré-avisos, guias de impostos e declarações de importação do próprio membro autorizado, com limite padrão de 60 chamadas por minuto e 5.000 por dia. A página de desenvolvedores da HowBridge lista hoje como pontos de acesso a API de dados de membros, o MCP de membros e o MCP público, sem endpoint A2A; este artigo não significa que a HowBridge já suporte A2A.

Se você quer que um assistente de IA ajude a estimar o custo de enviar da China para Taiwan, pode usar diretamente a simulação de frete de consolidação, a calculadora de impostos de importação e a consulta de classificação tarifária na versão web; as ferramentas e o MCP público usam a mesma lógica de cálculo, as simulações são apenas referência, o frete vale conforme a fatura emitida após a medição na entrada no armazém, e os impostos, conforme o valor fixado pela alfândega.