A2A Protocol: quando usar e como combinar com MCP

Use o A2A Protocol quando seu agente precisar delegar trabalho a outro agente, operado de forma independente. Use o Model Context Protocol (MCP) quando ele precisar acessar ferramentas ou dados. O A2A v1.0 muda o contrato de integração. Por isso, a decisão depende tanto da separação entre os sistemas que você quer conectar quanto das versões aceitas pelos seus endpoints.

MCP vs A2A: ferramentas, dados e delegação de trabalho

O MCP dá ao agente acesso a recursos. O A2A permite pedir a outro agente que assuma a responsabilidade por uma parte do trabalho. Os dois podem fazer parte do mesmo sistema.

O Model Context Protocol (MCP) padroniza a conexão de uma aplicação de IA com sistemas externos, incluindo ferramentas e fontes de dados. O Agent2Agent (A2A) padroniza a comunicação entre agentes independentes. A documentação oficial apresenta os dois como complementares. Introdução ao MCP, A2A e MCP.

Exemplo com MCP: consultar um pedido

Imagine um agente de atendimento respondendo a uma dúvida sobre uma entrega. Um servidor MCP expõe uma ferramenta de consulta de pedidos. O agente informa o identificador do pedido, recebe os dados e redige a resposta ao cliente.

O ganho para o negócio é uma conexão reutilizável com o sistema de pedidos. Não é preciso introduzir outro agente só para buscar um registro. O guia de servidores MCP aborda o lado dessa decisão que envolve a conexão com ferramentas.

Exemplo com o protocolo A2A: delegar a seleção de fornecedores

Imagine um assistente de compras que precisa de uma lista de fornecedores adequados. Um agente de pesquisa de fornecedores, separado e operado por outra empresa, é responsável pelo fluxo de pesquisa. O assistente de compras envia os requisitos, esclarece uma dúvida sobre as necessidades de entrega e recebe uma lista estruturada de candidatos.

O assistente de compras não precisa saber como esse agente faz as buscas, qual modelo usa ou como organiza suas etapas internas. Precisa de uma solicitação com termos acordados e de um resultado útil. É esse tipo de interação entre sistemas que o A2A foi projetado para viabilizar.

O agente de pesquisa de fornecedores pode usar MCP internamente para consultar dados de catálogos. Nessa arquitetura, o A2A cuida da delegação; o MCP fornece o acesso aos dados.

A diferença está na interface de que você precisa. Uma ferramenta MCP pode ter uma lógica de implementação sofisticada por trás. Escolha A2A quando quiser que o outro sistema se apresente como um agente, com habilidades que possam ser descobertas e um ciclo de vida para o trabalho. O critério não deve ser o quanto o funcionamento interno parece inteligente.

O que é o A2A Protocol?

O A2A é um contrato comum de comunicação para agentes criados por fornecedores diferentes ou com frameworks diferentes. Ele permite interagir com um agente sem precisar acessar sua memória interna, suas ferramentas ou sua lógica de decisão. O site do protocolo descreve esses elementos internos como opacos. Visão geral do A2A.

Quem faz a solicitação é o cliente A2A; o sistema que a recebe é o servidor A2A, também chamado de agente remoto. Para quem está à frente de uma empresa e contrata um serviço especializado, isso permite concentrar a integração na interface do serviço, sem recriar a implementação do especialista.

Quem desenvolveu o A2A e quem governa o projeto?

O site oficial é preciso: “O A2A foi originalmente desenvolvido pelo Google e doado à Linux Foundation.” O site também informa que um comitê técnico diretor mantém o projeto. Portanto, a governança vai além de seu desenvolvedor original. Governança e código aberto.

O repositório a2aproject/A2A é a porta de entrada para a especificação, os links dos SDKs e os exemplos. O A2A em si é um protocolo; você ainda precisa escolher o software usado para criar e operar seus agentes.

Especificação do protocolo A2A: os conceitos essenciais

A distinção central é entre a conversa, o trabalho que está sendo acompanhado e o resultado entregue. Separar esses elementos facilita o projeto de sistemas com o protocolo.

Agent Card: como o cliente descobre o que um agente oferece

Um Agent Card é um documento de metadados em JSON que descreve a identidade, as habilidades, os recursos, as informações de conexão e os requisitos de autenticação de um agente. Ele ajuda o cliente a decidir se deve contatar aquele agente e como fazer isso. Conceitos fundamentais.

No exemplo de compras, o cartão pode anunciar habilidades de pesquisa de fornecedores. Ele é o ponto de partida da integração, não uma prova de que a lista entregue atenderá aos seus critérios de compra.

O caminho padronizado de descoberta documentado é /.well-known/agent-card.json. Os cartões também podem ser obtidos por configuração direta ou em um registro com curadoria. O A2A não determina uma API padrão para esses registros. Descoberta de agentes.

Tarefas, mensagens, Parts e artefatos

Uma tarefa é uma unidade de trabalho com estado, identificador e ciclo de vida. Uma mensagem é um turno de comunicação. Uma Part contém o texto propriamente dito, o conteúdo ou a referência de um arquivo, ou dados estruturados. Um artefato é um resultado concreto produzido durante uma tarefa. Conceitos fundamentais.

No exemplo dos fornecedores, “Qual é a região de entrega?” é comunicação. A pesquisa de fornecedores que está sendo acompanhada é a tarefa. A lista final de candidatos é um artefato. Seu fluxo de compras deve consumir essa lista como uma entrega, sem precisar vasculhar o histórico da conversa em busca de algo que pareça concluído.

Um agente pode devolver uma mensagem autossuficiente ou criar uma tarefa. Interações relacionadas são agrupadas por contextId. Quando uma tarefa chega a um estado terminal, um refinamento inicia uma nova tarefa, em vez de reabrir a anterior. Ciclo de vida de uma tarefa.

Essa distinção importa quando o comprador muda os requisitos depois da entrega. Mantenha a lista original identificável e trate sua revisão como um novo trabalho. Assim, quem usar o resultado nas etapas seguintes saberá qual versão aprovou.

Transportes: como o mesmo contrato circula

Um transporte ou vínculo de protocolo (binding) define como as operações trafegam pela conexão. A especificação define bindings para JSON-RPC, gRPC e HTTP+JSON/REST. As interfaces do Agent Card identificam o endpoint, o binding e a versão do protocolo. Especificação do A2A.

Polling, streaming e notificações push dizem respeito à forma como as atualizações da tarefa chegam. Essa escolha é separada da escolha do binding. Em um painel de compras, consultas periódicas podem bastar; em uma experiência interativa, atualizações incrementais podem ser importantes. Confira os recursos aceitos pelo endpoint antes de projetar a interface em torno deles.

O que mudou no A2A v1.0?

Integrações existentes precisam passar por uma revisão de compatibilidade; trocar a string de versão não basta. As mudanças abaixo são as descritas na página oficial de novidades, na comparação entre v0.3.0 e v1.0:

• Uma definição compartilhada: a2a.proto passa a ser a definição normativa do protocolo, com especificações formais para os bindings.
• Mudanças no formato de comunicação: uma Part unificada substitui tipos de conteúdo separados; nomes de membros substituem os discriminadores kind, e os valores de enumeração usam SCREAMING_SNAKE_CASE.
• Agent Cards reorganizados: supportedInterfaces agrupa os detalhes de conexão, e a versão do protocolo é declarada por interface.
• Operações atualizadas: message/send passa a ser SendMessage; ListTasks adiciona listagem com filtros e paginação por cursor.
• Mudanças para uso empresarial: campos de tenant, regras de verificação de assinatura do Agent Card e fluxos OAuth atualizados afetam o projeto da integração.

Essas mudanças foram verificadas na página de novidades da v1.0 do projeto em 12 de outubro de 2026.

Para um conector existente, revise em conjunto as solicitações serializadas, a interpretação das respostas, a descoberta de cartões e as operações utilizadas. Uma conexão que funciona, por si só, não comprova que todas as interações continuam se comportando corretamente.

Quais frameworks e plataformas oferecem suporte a A2A?

Há implementações documentadas, mas a cobertura de versões e recursos varia. Escolha com base no comportamento de que seu fluxo precisa. O suporte e as limitações abaixo foram conferidos na documentação pública de cada fornecedor em 12 de outubro de 2026; não houve teste dos produtos em uma sessão autenticada.

Google Agent Development Kit

O Google Agent Development Kit (ADK), um framework para criar agentes, documenta to_a2a para expor um agente e gerar seu Agent Card. A integração A2A em Python é classificada como experimental. A documentação informa suporte a a2a-sdk 0.3.x e 1.x.x e orienta novas integrações a usar 1.x.x. Guia do ADK para expor agentes.

O ADK também documenta RemoteA2aAgent para consumir um agente remoto. Assim, quem desenvolve com ADK encontra pontos de entrada documentados nos dois lados da delegação. Mesmo que o wrapper seja conveniente, o status experimental precisa entrar na decisão de implantação. Guia do ADK para consumir agentes.

LangGraph via LangSmith Agent Server

O LangSmith Agent Server, a camada de disponibilização documentada para implantações de LangGraph, expõe um endpoint A2A em /a2a/{assistant_id}. Sua documentação especifica o binding JSON-RPC da v1.0 e a aceitação de nomes de métodos da v0.3. O grafo precisa ter um campo messages no estado. Documentação de A2A do LangSmith.

A mesma página lista limitações: gRPC e HTTP+JSON não estão implementados, e SubscribeToTask e a configuração de notificações push ainda não têm suporte. É possível transmitir uma mensagem por streaming, mas isso não significa que todas as operações de assinatura ou notificação estejam disponíveis. Esse é um motivo concreto para conferir a cobertura de operações antes de definir como executar trabalhos em segundo plano.

CrewAI e CrewAI AMP

O CrewAI, um framework para coordenar agentes, documenta A2AClientConfig para delegação remota e A2AServerConfig para expor agentes. Um agente pode ser configurado para exercer os dois papéis. Documentação de delegação do CrewAI.

O CrewAI AMP, sua plataforma de implantação, classifica os agentes servidores A2A como lançamento inicial (early release) e lista as versões 0.2 e 0.3 do protocolo. Também descreve o uso de armazenamento distribuído persistente no lugar do estado em memória da implementação de código aberto. A existência de suporte a A2A no CrewAI não permite presumir que um endpoint do AMP aceite v1.0. A2A no AMP.

Microsoft Foundry Agent Service

O Microsoft Foundry Agent Service, uma plataforma gerenciada de agentes, documenta o tipo de ferramenta a2a, em disponibilidade geral, para a versão 1.0 do protocolo. O tipo anterior, a2a_preview, aceita 0.3 e permanece em prévia. A Microsoft recomenda o tipo em disponibilidade geral para novas integrações. Documentação de A2A do Foundry.

A página também informa que os agentes do Foundry usados como destino aceitam apenas texto e não oferecem respostas por streaming. Um fluxo que precise receber uma entrega multimídia por streaming deve levar essa limitação em conta. Os tipos de conteúdo previstos por um protocolo não são uma garantia de que toda plataforma de hospedagem os implemente.

Para a decisão mais ampla sobre frameworks, consulte o comparativo de frameworks de agentes de IA. Estas notas de integração respondem a uma pergunta mais específica: qual interface A2A o sistema que disponibiliza o agente documenta?

O que muda para quem desenvolve, opera ou contrata

O ganho é uma interface de integração mais reutilizável, desde que operar o serviço adicional compense. As implicações variam conforme quem toma a decisão.

Quem desenvolve: defina o que será delegado antes de adicionar um transporte. “Produzir uma lista de fornecedores com fontes e justificativas” delimita um serviço. “Executar esta consulta no banco de dados” delimita uma ferramenta. Preserve essa diferença mesmo que ambos acabem acionando chamadas a modelos.

Quem opera: defina quem responde pela tarefa depois da delegação. No exemplo de compras, alguém precisa decidir o que acontece se a pesquisa de fornecedores pedir mais informações, parar de responder ou devolver uma lista que não cumpra os critérios de aceitação. Um formato comum de mensagens não resolve essas responsabilidades.

Compradores e fundadores: peça informações sobre a versão do protocolo, o binding, as operações, os tipos de conteúdo e o status de implantação. Compare esses detalhes com os requisitos do seu fluxo. Uma alegação de compatibilidade sem essas informações não basta para assumir um compromisso de integração.

Como planejar o orçamento de uma implantação A2A

Não existe uma configuração única de implantação A2A a partir da qual calcular sua conta mensal. Um especialista hospedado por terceiros e um serviço operado por você têm componentes de custo diferentes. A documentação do protocolo não estabelece um preço universal de plataforma.

Use esta equação de planejamento, sempre considerando o mesmo período orçamentário:

Benefício líquido da integração = custos de conectores evitados menos custos de migração, custos adicionais de infraestrutura e custos contínuos de operação.

Inclua uso de modelos, hospedagem, armazenamento de tarefas, monitoramento e responsabilidade pela resposta a incidentes entre esses componentes operacionais. Use seus próprios custos em cada termo. O A2A se justifica quando elimina trabalho repetido de integração suficiente para compensar a nova interface de serviço que você terá de manter.

Onde há exagero nas promessas sobre A2A?

Um protocolo comum não torna agentes desconhecidos confiáveis nem garante a confiabilidade do trabalho distribuído. A padronização é útil, mas as decisões da aplicação continuam sendo suas.

Um Agent Card anuncia o que um serviço oferece. Ainda cabe a você decidir se confia no operador e se aceita o resultado. As orientações empresariais do A2A atribuem à implementação a aplicação das regras de autenticação e autorização, incluindo as permissões sobre as ações subjacentes. Orientações para implementação empresarial.

No fluxo de pesquisa de fornecedores, permita pesquisar sem conceder, de forma implícita, autoridade para comprar. Devolver uma recomendação e fazer um pedido devem exigir permissões separadas na sua aplicação.

Gerencie separadamente o artefato devolvido, o status da tarefa e o seu próprio registro de aceitação. Antes de permitir que um fluxo delegado crie uma ordem de compra, defina como a aplicação detectará ações de negócio repetidas e resolverá situações em que o resultado ficou incerto.

Outro exagero é adicionar A2A a toda chamada interna de subagente. O próprio escopo do projeto exclui explicitamente a definição de como um agente deve chamar suas ferramentas ou subagentes internos. Se os componentes seguem o mesmo contrato de aplicação, a composição nativa do seu framework pode já atender à necessidade. Escopo do A2A.

Preciso de A2A, de MCP ou dos dois?

Comece pela separação entre sistemas que já existe no seu produto.

Escolha MCP quando um agente precisar acessar sistemas de negócio, arquivos ou APIs por interfaces de ferramentas reutilizáveis. Se você precisar expor uma funcionalidade, siga o guia de servidor MCP em Python. Quando o desafio passar a ser a governança do acesso por essas conexões, o guia sobre gateway MCP aborda essa camada.

Escolha A2A quando outro agente, operado de forma independente, for responsável por um trabalho relevante e você precisar de uma forma comum de descobrir sua interface, trocar instruções e acompanhar o trabalho resultante. Avance agora se essa necessidade de integração já existir e os endpoints documentarem recursos compatíveis.

Escolha os dois quando seu agente delegar a um especialista que também precise de ferramentas e dados. O exemplo de fornecedores se encaixa aqui: A2A para a pesquisa delegada, MCP para o acesso ao catálogo dentro de um agente.

Espere para adotar A2A se o especialista externo ainda for apenas uma hipótese. A existência de um novo protocolo entre agentes não muda a situação de um agente que funciona bem com as ferramentas atuais. Também não é preciso usar nenhum dos dois padrões em toda chamada de função interna. Adote o contrato de conexão que resolva um problema real de integração.

Qual é o próximo passo na implementação?

Escreva o contrato de delegação para um resultado de negócio bem delimitado antes de migrar o restante da arquitetura. No caso de um assistente de compras, comece pela lista de fornecedores e deixe a execução da compra fora do escopo inicial.

1. 1

   Defina o que torna um artefato aceitável

   Especifique quais informações a lista de fornecedores deve conter, o que a torna inaceitável e qual aplicação registra o resultado aceito. Dê ao agente remoto uma responsabilidade delimitada.

2. 2

   Confira a compatibilidade das interfaces documentadas

   Registre as versões do protocolo no cliente e no servidor, o binding, os requisitos de autenticação e as operações necessárias. Verifique se o fluxo precisa de streaming ou entrega por push e se os dois endpoints oferecem esses recursos.

3. 3

   Planeje os casos em que o trabalho fica pendente

   Defina quem trata pedidos de esclarecimento, tempo limite excedido, rejeição e respostas incertas após uma nova tentativa. Estabeleça o que o usuário vê enquanto o trabalho está pendente e como um artefato revisado substitui o anterior.

Esse contrato dá uma base concreta para adicionar A2A. Se, ao escrevê-lo, ficar claro que o suposto especialista apenas busca um registro, implemente primeiro a conexão com a ferramenta.

Dúvidas antes de adotar A2A

Posso usar A2A sem MCP?

Sim. O A2A não determina como o agente remoto acessa suas próprias ferramentas e seus dados. O MCP é útil quando você também precisa de conexões padronizadas com ferramentas. Como os dois funcionam juntos.

Os dois agentes precisam usar o mesmo framework?

Não. A interoperabilidade entre frameworks é um dos objetivos centrais do A2A. O que precisa estar alinhado é a interface exposta e os recursos exigidos pela interação, não a implementação interna dos agentes. Visão geral do A2A.

Para receber guias práticos sobre como criar sistemas de agentes úteis, assine a newsletter.