Protocolo A2A: como agentes de IA se comunicam

O que é o protocolo A2A?

Agent2Agent é um padrão aberto para comunicação e colaboração entre aplicações baseadas em agentes.

Criado inicialmente pelo Google e hospedado pela Linux Foundation, ele permite que sistemas construídos por fornecedores e frameworks diferentes se comportem como cliente e servidor em uma interação padronizada.

O agente cliente age em nome de um usuário ou processo e solicita uma capacidade.

O agente remoto avalia a solicitação, pode responder imediatamente ou abrir uma tarefa duradoura, pedir dados adicionais, enviar progresso e entregar artefatos.

A especificação oficial do A2A define objetos, operações, estados e vínculos de protocolo.

Ela não padroniza o raciocínio interno do agente. Isso preserva autonomia e propriedade intelectual, mas exige um contrato claro nas fronteiras.

Qual problema o A2A resolve?

Sem um protocolo comum, cada integração entre agentes tende a criar seu próprio endpoint, formato de mensagem, modelo de progresso e tratamento de arquivos.

À medida que o número de agentes cresce, surgem combinações ponto a ponto difíceis de manter.

A2A padroniza perguntas essenciais: o que esse agente sabe fazer, onde atende, como autenticar, quais formatos aceita, como iniciar uma tarefa e como acompanhar seu estado.

A comunicação deixa de depender do framework usado para construir cada participante.

O protocolo é especialmente útil quando o agente remoto possui autonomia real: ele pode planejar, usar várias ferramentas e manter uma interação por mais tempo.

Para entender essa organização antes do protocolo, veja como sistemas multiagentes colaboram.

Cliente A2A e agente remoto

Há três papéis conceituais. O usuário define um objetivo. O A2A Client, que pode ser outro agente ou um serviço convencional, inicia a comunicação.

O A2A Server expõe um agente remoto por um endpoint compatível.

“Remoto” não significa necessariamente outra empresa. Os participantes podem estar em serviços separados dentro da mesma organização.

O ponto importante é a fronteira: o cliente conhece as capacidades publicadas e os resultados recebidos, mas não precisa acessar prompts internos, memória privada, cadeia de raciocínio ou ferramentas do servidor.

Essa opacidade reduz acoplamento. Uma equipe pode trocar modelo, framework ou ferramentas internas sem alterar o contrato externo, desde que mantenha o comportamento anunciado pelo agente.

A2A vs MCP: qual é a diferença?

A documentação oficial descreve A2A e MCP como protocolos complementares. A diferença está no tipo de participante com o qual o agente interage.

Critério	MCP	A2A
Relação principal	Agente com ferramenta ou fonte de dados	Agente com outro agente
Unidade típica	Chamada estruturada de uma função ou recurso	Mensagem ou tarefa com ciclo de vida
Autonomia do destino	Capacidade delimitada	Sistema capaz de planejar e usar ferramentas
Resultados	Conteúdo ou saída da ferramenta	Mensagens, estados e artefatos
Duração	Geralmente operação direta	Pode durar minutos, horas ou mais

Um agente de compras pode usar A2A para delegar uma cotação a um agente fornecedor. Esse agente remoto pode usar MCP internamente para consultar estoque e prazo em suas APIs.

O artigo O que é MCP detalha a camada de ferramentas e dados.

Como o protocolo A2A funciona

1. O cliente encontra ou recebe a Agent Card do agente remoto.
2. Ele verifica interface, versão, capacidades, formatos e requisitos de segurança.
3. As credenciais necessárias são obtidas fora da mensagem A2A.
4. O cliente envia uma mensagem com instruções e conteúdo.
5. O servidor retorna uma mensagem direta ou cria uma tarefa.
6. O cliente acompanha progresso por consulta, streaming ou notificação.
7. O agente entrega resultados como mensagens ou artefatos.

A versão 1.0 permite declarar interfaces para JSON-RPC, gRPC e HTTP com JSON. A semântica central deve permanecer equivalente entre os vínculos suportados.

Assim, escolher o transporte não deveria mudar o significado da tarefa.

Agent Card: como os agentes publicam capacidades

Agent Card é um documento JSON que apresenta identidade, descrição, interfaces, capacidades, habilidades e requisitos de segurança.

Ela funciona como um cartão de visita legível por máquinas. A descoberta pode usar um endereço público conhecido, registros controlados ou distribuição por configuração, conforme o ambiente.

Este exemplo reduzido ilustra a estrutura. Em produção, use o schema da versão adotada e as bibliotecas oficiais:

{
  "name": "Agente de logística",
  "description": "Consulta entregas e trata ocorrências",
  "supportedInterfaces": [
    {
      "url": "https://agente.exemplo.com/a2a",
      "protocolBinding": "HTTP+JSON",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": [
    {
      "id": "acompanhar-entrega",
      "name": "Acompanhar entrega",
      "description": "Localiza um pedido e informa sua situação",
      "inputModes": ["application/json"],
      "outputModes": ["application/json"]
    }
  ]
}

Uma card pública não deve revelar ferramentas internas, segredos, prompts ou habilidades restritas.

Quando configurado, um cliente autenticado pode solicitar uma card estendida com informações adicionais permitidas para sua identidade.

Messages, Parts e Artifacts

Message representa um turno de comunicação. Ela possui papel e uma ou mais Parts.

Cada parte pode transportar texto, bytes, uma URL ou dados estruturados, além do tipo de mídia e metadados.

Artifact é um resultado concreto produzido durante a tarefa: relatório, imagem, arquivo ou objeto estruturado.

Separar conversa de entrega ajuda o cliente a distinguir uma explicação intermediária do produto que deve armazenar ou processar.

O formato flexível não dispensa contrato. Se dois agentes usam JSON, ainda precisam concordar sobre campos, unidades, identificadores e versões.

Para fluxos críticos, valide schema e rejeite conteúdo inesperado.

Como funciona o ciclo de uma tarefa

Uma resposta simples pode voltar como Message. Quando o trabalho precisa de acompanhamento, o servidor retorna uma Task com identificador, contexto, estado, histórico opcional e artefatos.

• submitted: a solicitação foi aceita;
• working: o agente está processando;
• input-required: falta informação do usuário;
• auth-required: é necessária uma etapa de autenticação;
• completed: o trabalho terminou com sucesso;
• failed, canceled ou rejected: a tarefa terminou sem conclusão bem-sucedida.

Estados terminais não aceitam novas mensagens. Para continuar um objetivo relacionado, a aplicação pode iniciar outra tarefa no mesmo contexto.

Esse limite evita reabrir silenciosamente algo já concluído ou rejeitado.

Requisição, streaming e notificações

Há três padrões principais. Em requisição e consulta, o cliente envia a mensagem e recupera o estado depois.

No streaming, recebe eventos de progresso e artefatos incrementais por SSE.

Em tarefas longas, o servidor pode avisar um webhook quando ocorrer uma mudança importante.

A documentação de streaming e operações assíncronas recomenda SSE para progresso em tempo real e notificações para clientes que não podem manter conexão aberta.

O guia sobre como funcionam webhooks ajuda a entender entrega, repetição e validação do destino.

Nem todo agente precisa oferecer os três modos. O cliente deve ler as capacidades anunciadas e escolher o fluxo compatível, tratando reconexão, timeout, cancelamento e reentrega.

Exemplo prático de colaboração entre agentes

Imagine um agente de atendimento que recebe: “Meu pedido não chegou e preciso dele amanhã”. Ele identifica que precisa de informações e ações fora de seu domínio.

1. O agente de atendimento consulta a Agent Card do agente de logística.
2. Envia uma tarefa com o pedido e o objetivo, respeitando a autorização do cliente.
3. O agente de logística verifica transportadora, rota e opções usando ferramentas internas.
4. Se faltar confirmação de endereço, a tarefa entra em input-required.
5. Após a resposta humana, o agente retoma o fluxo e produz um artefato estruturado com alternativas.
6. O agente de atendimento explica as opções e pede aprovação antes de alterar a entrega.

A2A transporta a colaboração, mas a decisão de pedir aprovação é uma regra do produto.

Entender como agentes usam ferramentas, memória e contexto ajuda a separar protocolo, raciocínio e política.

O que mudou no A2A 1.0

A versão 1.0 é a primeira especificação estável. Ela formalizou vínculos para JSON-RPC, gRPC e HTTP com JSON, reorganizou a Agent Card, adicionou listagem paginada de tarefas, suporte a múltiplos tenants, negociação de versão e mecanismos mais claros para extensões.

Na segurança, a versão inclui cards assinados com JWS, declaração de mTLS, fluxos modernos de OAuth 2.0 e suporte a PKCE.

Há mudanças incompatíveis em relação às versões anteriores; implementações antigas precisam seguir o guia de migração, não apenas alterar um número.

Em abril de 2026, a Linux Foundation informou mais de 150 organizações apoiando o padrão e integrações em plataformas de nuvem. Isso mostra tração, mas não prova que A2A seja necessário para todo projeto.

Segurança no protocolo A2A

A2A aproveita mecanismos conhecidos da web. A documentação de recursos empresariais orienta declarar esquemas na Agent Card, obter credenciais fora das mensagens e enviá-las em cabeçalhos HTTP. HTTPS protege o transporte, mas a aplicação ainda precisa definir confiança e permissão.

Autenticação não substitui autorização

Saber qual cliente enviou uma solicitação não significa permitir qualquer tarefa. Restrinja habilidades por identidade, tenant, usuário representado e contexto.

Uma tarefa só pode ser consultada por quem tem autorização para aquele recurso. O artigo sobre autenticação em APIs explica essa diferença fundamental.

Conteúdo recebido continua não confiável

Mensagens e artefatos podem conter instruções maliciosas, arquivos perigosos ou dados incorretos.

Valide tipos, tamanho e schema; examine arquivos; isole processamento; e nunca transforme texto recebido em autorização.

Os guardrails em sistemas de IA devem existir antes e depois da chamada remota.

Webhooks e artefatos exigem validação

Proteja endpoints de notificação contra falsificação e repetição. Ao buscar uma URL de artefato, bloqueie redes internas e destinos não permitidos para reduzir SSRF.

Limite redirecionamentos, bytes, tipos de arquivo e tempo de download.

Observabilidade e governança

Uma tarefa pode atravessar organizações e vários agentes. Sem correlação, um erro aparece apenas como “falhou”.

Registre identificadores de requisição, tarefa e contexto; transições de estado; duração; agente chamado; versão; resultado da autorização e motivo de falha.

Não grave prompts, credenciais e artefatos sensíveis indiscriminadamente. Telemetria precisa de minimização, retenção e controle de acesso.

Avaliações também devem medir a cadeia completa, não apenas o modelo isolado.

O guia de evals para modelos e agentes apresenta critérios para qualidade, segurança e regressão.

• taxa de sucesso e rejeição por habilidade;
• tempo em cada estado e tempo total;
• quantidade de pedidos de informação adicional;
• falhas de autenticação, autorização e schema;
• volume e tamanho dos artefatos;
• custo por tarefa e intervenção humana necessária.

Quando vale a pena usar A2A

• agentes pertencem a equipes, empresas ou frameworks diferentes;
• o destino executa tarefas autônomas e não apenas uma função simples;
• o trabalho precisa de estado, acompanhamento ou várias interações;
• resultados incluem documentos, arquivos ou dados estruturados;
• existe necessidade de streaming, cancelamento ou notificação assíncrona;
• a interoperabilidade reduz integrações específicas entre fornecedores.

Comece com uma colaboração estreita e mensurável. Uma cadeia grande de agentes aumenta custo, latência e superfície de falha.

Padronizar a conexão é útil, mas não torna a decisão distribuída automaticamente melhor.

Quando o A2A é complexidade desnecessária

Uma função determinística com entrada e saída conhecidas continua adequada a uma API ou ferramenta MCP.

Dois componentes internos fortemente controlados podem usar uma fila ou chamada de serviço sem adotar todo o modelo de agentes.

Também não use A2A para esconder uma arquitetura indefinida. Se não há proprietário, contrato de dados, política de autorização ou critério de conclusão, o protocolo apenas transportará a ambiguidade.

Primeiro modele a responsabilidade e só depois escolha a interface.

Checklist de implementação

1. Escolha um caso em que o destino seja realmente um agente autônomo.
2. Defina habilidade, formatos aceitos, artefato esperado e critério de conclusão.
3. Publique uma Agent Card mínima, versionada e sem dados internos sensíveis.
4. Use um SDK compatível com a versão 1.0 e valide os schemas oficiais.
5. Implemente autenticação e autorização por identidade, tenant e tarefa.
6. Defina timeout, cancelamento, repetição, idempotência e limites de custo.
7. Valide Parts, artefatos, URLs e notificações como entradas não confiáveis.
8. Correlacione mensagens, tarefas e chamadas internas na telemetria.
9. Teste estados interrompidos, falhas, reentrega, versão incompatível e perda de conexão.
10. Mantenha revisão humana antes de ações financeiras, irreversíveis ou sensíveis.

Perguntas frequentes

A2A é uma API de inteligência artificial?

A2A é um protocolo de aplicação com operações e estruturas padronizadas.

Uma implementação oferece endpoints, mas o padrão vai além de uma API específica porque define descoberta, tarefas, mensagens, artefatos, versões e diferentes vínculos.

A2A substitui o MCP?

Não. MCP conecta agentes a ferramentas e fontes de dados. A2A conecta agentes independentes para colaboração.

Um agente remoto chamado por A2A pode usar vários servidores MCP internamente.

Os agentes precisam usar o mesmo modelo?

Não. O agente pode usar outro modelo, framework, linguagem ou arquitetura.

A interoperabilidade depende do contrato A2A exposto, não da implementação interna.

A2A garante que outro agente é confiável?

Não. Agent Cards assinadas ajudam a verificar origem e integridade, e autenticação identifica participantes.

A organização ainda deve autorizar ações, validar resultados, limitar dados e avaliar o fornecedor.

É obrigatório usar streaming?

Não. O agente declara essa capacidade. O cliente pode usar resposta direta, consultar uma tarefa, acompanhar por SSE ou receber notificações, conforme duração e infraestrutura.

A2A serve apenas para grandes empresas?

Não, mas o benefício cresce quando há fronteiras entre agentes e integrações que precisam ser reutilizadas.

Em um projeto pequeno com um único agente e poucas ferramentas, uma API simples ou MCP provavelmente é suficiente.

Conclusão

O protocolo A2A oferece uma base comum para agentes descobrirem capacidades, trocarem mensagens, acompanharem tarefas e entregarem artefatos sem compartilhar sua implementação interna.

A versão 1.0 tornou esse contrato mais estável e adequado a ambientes empresariais.

Seu valor aparece quando existem agentes realmente independentes e uma colaboração longa ou complexa.

Comece pequeno, combine A2A com MCP onde cada um faz sentido e trate segurança, governança e observabilidade como partes do produto.

O protocolo organiza a conversa; a arquitetura continua responsável pelo que os agentes podem fazer.