DEV Community

Cover image for O que é Agent2Agent (A2A)? O Protocolo Aberto para Comunicação de Agentes de IA
Lucas
Lucas

Posted on • Originally published at apidog.com

O que é Agent2Agent (A2A)? O Protocolo Aberto para Comunicação de Agentes de IA

A maioria dos sistemas de IA ainda funciona como um único agente: um modelo, um loop de prompt e um conjunto de ferramentas. Isso resolve tarefas simples, mas começa a falhar quando o trabalho precisa ser dividido entre agentes independentes, criados por equipes diferentes ou em frameworks diferentes. O Agent2Agent (A2A) resolve esse ponto: ele define um protocolo comum para agentes se descobrirem, trocarem tarefas e retornarem resultados.

Experimente o Apidog hoje

Este guia mostra o que é o A2A, qual problema ele resolve, como funciona na prática e quando usá-lo em vez do MCP. Se quiser testar um agente A2A depois, o guia do Apidog A2A Debugger continua a partir daqui.

O que é Agent2Agent (A2A)?

Agent2Agent, ou A2A, é um protocolo aberto para comunicação entre agentes de IA. Ele define:

  • como um agente anuncia suas capacidades;
  • como outro agente descobre e se conecta a ele;
  • como mensagens, arquivos e dados estruturados são enviados;
  • como uma tarefa é acompanhada até a conclusão;
  • como o resultado volta para o agente solicitante.

A palavra importante é entre. O A2A não serve para dar mais ferramentas a um agente. Ele serve para permitir que agentes separados trabalhem juntos sem conhecer os detalhes internos um do outro.

Pense nele como um “HTTP para agentes”. O HTTP permite que um navegador converse com qualquer servidor web sem saber se ele foi escrito em Go, Node.js, Java ou Python. O A2A permite que um agente LangGraph converse com um agente CrewAI, AutoGen ou customizado sem depender do framework interno.

O Google introduziu o A2A em 2025 e depois o transferiu para a Linux Foundation como um projeto neutro em relação a fornecedores. A especificação está disponível no repositório A2A do GitHub, e implementações de referência aparecem no site do projeto A2A.

O problema que o A2A resolve

Sem A2A, conectar dois agentes normalmente exige código “cola” específico para cada integração.

Exemplo típico:

  1. O agente A precisa chamar um agente de pesquisa mantido por outra equipe.
  2. Alguém escreve um cliente HTTP específico.
  3. A equipe define manualmente um formato de payload.
  4. A autenticação é combinada caso a caso.
  5. O status da tarefa é tratado com convenções próprias.
  6. Quando outro agente entra no fluxo, tudo recomeça.

Essa abordagem quebra rápido porque não há contrato comum.

Os principais problemas são:

  • Sem descoberta padronizada: o agente solicitante não sabe perguntar “o que você consegue fazer?”.
  • Sem modelo comum de tarefa: cada agente retorna status, erro e resultado em formatos diferentes.
  • Sem autenticação consistente: cada integração define headers e credenciais de forma própria.
  • Sem interoperabilidade: trocar um agente LangGraph por um AutoGen exige adaptação manual, mesmo que ambos façam a mesma função.

O A2A resolve isso com um contrato compartilhado. Qualquer agente compatível pode publicar suas capacidades, receber tarefas, enviar atualizações e devolver artefatos usando o mesmo modelo.

Como o A2A funciona

O A2A é baseado em quatro conceitos principais:

  1. Cartão de Agente
  2. Tarefas
  3. Mensagens e artefatos
  4. Streaming e atualizações

1. Cartão de Agente

O Cartão de Agente é um documento JSON publicado pelo agente para se descrever. Ele funciona como o ponto de descoberta.

Normalmente, ele fica em um caminho conhecido, como:

https://your-agent.example.com/.well-known/agent.json
Enter fullscreen mode Exit fullscreen mode

Esse cartão informa dados como:

  • nome do agente;
  • descrição;
  • capacidades;
  • habilidades disponíveis;
  • tipos de entrada e saída aceitos;
  • requisitos de autenticação;
  • versão do protocolo.

Um exemplo simplificado de estrutura seria:

{
  "name": "Research Agent",
  "description": "Agente especializado em pesquisa e sumarização",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true
  },
  "skills": [
    {
      "id": "web-research",
      "name": "Pesquisa web",
      "description": "Pesquisa fontes e retorna um resumo estruturado"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Na prática, o fluxo começa assim:

curl https://your-agent.example.com/.well-known/agent.json
Enter fullscreen mode Exit fullscreen mode

O agente solicitante lê esse documento antes de enviar qualquer tarefa. Assim, ele sabe quais habilidades estão disponíveis e qual formato deve usar.

2. Tarefas

Uma tarefa é a unidade de trabalho no A2A.

Quando um agente pede que outro faça algo, essa solicitação vira uma tarefa com:

  • um ID próprio;
  • um status;
  • mensagens associadas;
  • possíveis artefatos de saída.

Estados comuns incluem:

  • submitted
  • working
  • input-required
  • completed

Esse modelo é importante porque o solicitante não precisa saber como o agente executa a tarefa internamente. Ele só precisa acompanhar o ciclo de vida padronizado.

Exemplo de fluxo:

submitted -> working -> completed
Enter fullscreen mode Exit fullscreen mode

Ou, se o agente precisar de mais dados:

submitted -> working -> input-required -> working -> completed
Enter fullscreen mode Exit fullscreen mode

3. Mensagens e artefatos

Uma mensagem carrega o conteúdo enviado entre agentes.

Ela pode conter partes como:

  • texto;
  • arquivos;
  • dados estruturados;
  • combinações desses formatos.

Exemplo conceitual:

{
  "message": {
    "parts": [
      {
        "type": "text",
        "text": "Pesquise os principais riscos de segurança em APIs públicas."
      }
    ]
  }
}
Enter fullscreen mode Exit fullscreen mode

Quando o agente conclui o trabalho, ele retorna artefatos. Artefatos são as saídas estruturadas da tarefa.

Um artefato pode ser:

  • um resumo;
  • um documento gerado;
  • uma tabela;
  • uma referência a arquivo;
  • dados estruturados para outro agente consumir.

Exemplo conceitual:

{
  "artifacts": [
    {
      "parts": [
        {
          "type": "text",
          "text": "Resumo dos principais riscos encontrados..."
        }
      ]
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

O ponto principal: mensagens e artefatos usam o mesmo conceito de “partes”, mantendo consistência entre entrada e saída.

4. Streaming e atualizações

Tarefas longas não precisam bloquear o solicitante.

O A2A suporta eventos enviados pelo servidor, ou server-sent events, para transmitir:

  • mudanças de status;
  • resultados parciais;
  • progresso intermediário.

Exemplo de comportamento:

working: encontrou 3 fontes
working: analisando conteúdo
working: gerando resumo
completed: relatório final disponível
Enter fullscreen mode Exit fullscreen mode

Isso permite que a interface ou o agente orquestrador mostre progresso em vez de esperar uma resposta final silenciosa.

Fluxo típico de uma chamada A2A

Uma troca A2A comum funciona assim:

  1. O Agente A busca o Cartão de Agente do Agente B.
  2. O Agente A lê as habilidades disponíveis.
  3. O Agente A envia uma mensagem criando uma tarefa.
  4. O Agente B executa a tarefa.
  5. O Agente B envia atualizações de status, se necessário.
  6. O Agente B retorna artefatos quando a tarefa chega a completed.
  7. O Agente A consome os artefatos e continua o fluxo.

Em alto nível:

Agente A -> busca agent.json -> Agente B
Agente A -> cria tarefa -> Agente B
Agente B -> status/updates -> Agente A
Agente B -> artefatos finais -> Agente A
Enter fullscreen mode Exit fullscreen mode

Tudo acontece via JSON sobre HTTP.

A2A vs MCP

A2A e MCP são frequentemente confundidos porque ambos aparecem em arquiteturas de agentes. Mas eles resolvem problemas diferentes.

A2A MCP
Conecta Agente a agente Agente a ferramentas e dados
Pergunta que responde “Outro agente pode fazer esta etapa por mim?” “Quais ferramentas e recursos este agente pode acessar?”
Uso típico Workflows multiagente entre equipes Um agente chamando banco de dados, sistema de arquivos ou API
Unidade de troca Tarefas, mensagens, artefatos Chamadas de ferramentas, recursos, prompts

Use MCP quando um agente precisa acessar sistemas externos, como banco de dados, API, arquivos ou ferramentas.

Use A2A quando um agente precisa delegar trabalho para outro agente.

Um sistema real pode usar os dois ao mesmo tempo:

Agente principal
  ├─ usa MCP para consultar uma API interna
  └─ usa A2A para delegar análise a um agente especialista
Enter fullscreen mode Exit fullscreen mode

A comparação entre servidor MCP e A2A aprofunda essa diferença, e o debugger de cliente MCP da Apidog mostra o lado do MCP na prática.

Colaboração multiagente na prática

O A2A é uma forma de colaboração entre agentes, mas não é a única.

Alguns sistemas usam orquestração direta. Nesse modelo, um agente sabe exatamente qual outro agente deve chamar e em que etapa do fluxo.

Um exemplo open source é o Codex-Claude-Collab, uma habilidade que coordena um fluxo entre OpenAI Codex e Claude Code. O Codex planeja a tarefa, delega a implementação ao Claude Code e depois revisa o diff antes de responder ao usuário.

Esse é um modelo “hard-wired”: um lado conhece explicitamente o outro.

O A2A generaliza esse padrão. Em vez de o solicitante saber que está chamando um agente específico, ele lê um Cartão de Agente e interage com qualquer agente compatível.

Use orquestração direta quando:

  • você controla os dois lados;
  • os agentes fazem parte do mesmo produto;
  • o fluxo é fixo;
  • trocar o agente não é uma prioridade.

Use A2A quando:

  • os agentes pertencem a equipes diferentes;
  • você precisa de descoberta;
  • agentes podem ser substituídos;
  • a integração precisa sobreviver a mudanças internas de framework;
  • o workflow cruza fronteiras de produto ou organização.

Na prática, sistemas maduros tendem a usar os dois:

Orquestração direta dentro da equipe
A2A entre equipes, produtos ou agentes independentes
Enter fullscreen mode Exit fullscreen mode

Como testar um agente A2A

Depois de construir ou consumir um agente A2A, você precisa inspecionar o tráfego.

Logs de console geralmente escondem detalhes importantes:

  • headers;
  • payload completo;
  • status da tarefa;
  • mensagens intermediárias;
  • artefatos;
  • erros de autenticação;
  • resposta bruta.

Scripts de teste ajudam no início, mas ficam difíceis de manter quando o agente evolui.

O Apidog inclui um A2A Debugger no cliente padrão. O fluxo é direto:

  1. Cole a URL do Cartão de Agente.
  2. Clique em conectar.
  3. Veja nome, capacidades e habilidades do agente.
  4. Envie uma mensagem de teste.
  5. Anexe arquivos, se necessário.
  6. Adicione metadados.
  7. Inspecione a resposta em diferentes visualizações.

O objetivo é isolar o problema rapidamente.

Quando uma integração falha, você precisa responder:

O erro está no transporte ou na lógica do agente?
Enter fullscreen mode Exit fullscreen mode

Se o payload enviado está incorreto, o problema está na integração. Se o payload está correto e o agente responde errado, o problema está na lógica do agente.

O guia do Apidog A2A Debugger mostra o ciclo completo de conexão, envio e leitura. O guia sobre testar agentes de IA que chamam suas APIs aplica a mesma disciplina: confirme primeiro a comunicação, depois investigue a lógica.

Caminho rápido para começar com A2A

Se você quer construir ou consumir um agente A2A, siga este caminho:

  1. Leia a especificação A2A para entender o Cartão de Agente e o ciclo de vida da tarefa.
  2. Execute um dos agentes de exemplo de referência localmente.
  3. Acesse o Cartão de Agente com curl ou um debugger A2A.
  4. Envie uma mensagem simples, como “olá”.
  5. Confirme que a tarefa muda de status corretamente.
  6. Leia os artefatos retornados.
  7. Só depois adicione autenticação, anexos e streaming.

Um checklist mínimo:

[ ] O agente expõe um Cartão de Agente válido
[ ] O cartão informa habilidades e capacidades
[ ] O solicitante consegue buscar o cartão
[ ] Uma tarefa simples pode ser criada
[ ] O status da tarefa é atualizado
[ ] O resultado volta como artefato
[ ] Erros são visíveis no payload
[ ] Autenticação foi testada separadamente
Enter fullscreen mode Exit fullscreen mode

Para começar simples, teste primeiro apenas texto:

Entrada: "Resuma este texto em três bullets"
Saída esperada: artefato com resumo textual
Enter fullscreen mode Exit fullscreen mode

Depois avance para:

  • arquivos;
  • dados estruturados;
  • autenticação;
  • streaming;
  • tarefas de longa duração.

O A2A ainda é jovem, mas já trata o tráfego entre agentes como um protocolo de primeira classe. Isso evita a manutenção de código “cola” personalizado para cada integração.

A postagem Agentes de IA são os novos consumidores de API desenvolve esse argumento, e o artigo sobre projetar APIs para agentes de IA mostra o que muda quando o consumidor da API é um agente em vez de uma pessoa.

Perguntas frequentes

O A2A foi criado pelo Google?

Sim. O Google introduziu o A2A em 2025 e depois o doou para a Linux Foundation como um projeto aberto e neutro em relação a fornecedores. A especificação é desenvolvida abertamente, e qualquer fornecedor pode implementá-la.

Preciso do A2A se tiver apenas um agente?

Não. O A2A resolve comunicação entre agentes. Se você tem apenas um agente acessando ferramentas, APIs ou dados, o MCP tende a ser mais relevante. O A2A entra quando há outro agente no fluxo.

Quais frameworks suportam A2A?

O A2A é agnóstico em relação a frameworks. Qualquer agente que publique um Cartão de Agente válido e implemente o protocolo pode participar. Isso permite integrar agentes criados com LangGraph, CrewAI, AutoGen ou implementações customizadas.

A2A é o mesmo que MCP?

Não. MCP conecta um agente a ferramentas e fontes de dados. A2A conecta agentes entre si. Eles são complementares e podem ser usados no mesmo sistema.

Como depurar uma integração A2A?

Use um debugger visual A2A, como o Apidog A2A Debugger. Cole a URL do Cartão de Agente, envie mensagens de teste e inspecione a solicitação e a resposta brutas. Isso ajuda a separar erro de transporte de erro de lógica do agente.

O A2A suporta tarefas de longa duração?

Sim. O modelo de tarefa possui estados explícitos, e o protocolo suporta server-sent events para enviar resultados parciais e atualizações de progresso. Assim, tarefas longas não precisam bloquear o agente solicitante.

Top comments (0)