Comunicação entre agentes utilizando o protocolo A2A

O que é o protocolo A2A

O A2A é um protocolo aberto de comunicação entre agentes de IA, lançado inicialmente pelo Google em abril de 2025, durante o Google Cloud Next. Ele foi projetado para sistemas multiagente e viabiliza a interoperabilidade entre agentes construídos com tecnologias distintas.

Em junho de 2025, o Google doou o projeto à Linux Foundation. Com isso, o protocolo passou a ter governança neutra e colaboração aberta com a comunidade.

O protocolo A2A conta com o apoio de mais de 150 organizações, incluindo Atlassian, Salesforce, SAP, ServiceNow, AWS, Cohere, LangChain e MongoDB. Esse apoio amplo indica que o padrão não depende de um único fornecedor.

Na prática, o problema que ele resolve é bem concreto. Sem um padrão comum, cada integração entre dois agentes exigiria um contrato próprio, com formatos e regras diferentes.

A2A e MCP: protocolos complementares

Antes de aprofundar no A2A, é importante entender sua relação com o MCP (Model Context Protocol), protocolo introduzido pela Anthropic em 2024. Os dois costumam aparecer juntos, mas resolvem problemas diferentes.

O MCP padroniza a comunicação entre agentes e ferramentas externas, como APIs, bancos de dados e fontes de dados. O A2A, por sua vez, foca na comunicação entre agentes.

A documentação oficial recomenda usar MCP para ferramentas e A2A para agentes. Assim, um agente pode usar MCP para acessar seus recursos internos e A2A para coordenar o trabalho com agentes externos.

Se você quer se aprofundar nessa comparação, leia MCP ou A2A: qual escolher. Para entender o outro lado da história, vale também o artigo o que é MCP.

Fundamentos técnicos do protocolo A2A

O protocolo A2A é construído sobre padrões amplamente adotados pela indústria, como HTTP, JSON-RPC 2.0 e SSE (Server-Sent Events). Isso reduz a barreira de adoção e facilita a integração com a infraestrutura que as empresas já têm.

Em outras palavras, qualquer equipe que já expõe APIs HTTP consegue implementar um agente A2A. Além disso, ferramentas de observabilidade, proxies e gateways existentes continuam funcionando.

A versão 0.3, lançada em julho de 2025, introduziu suporte a gRPC, assinatura de Agent Cards e ampliação do SDK Python. Desde então, a especificação continuou evoluindo, e a documentação da Microsoft já cita a versão 1.0 do protocolo como disponível de forma geral.

Papéis no protocolo

O A2A define dois papéis fundamentais na comunicação entre agentes. Cada interação sempre envolve um lado que pede e um lado que executa.

O A2A Client, ou agente cliente, formula e envia tarefas para agentes remotos. Ele pode ser uma aplicação, um serviço ou outro agente que delega trabalho.

O A2A Server, ou agente remoto, recebe as requisições, processa as tarefas e responde com atualizações de status ou resultados. Para isso, ele expõe um endpoint HTTP compatível com o protocolo.

Um mesmo agente pode assumir os dois papéis. Por exemplo, um agente orquestrador atua como servidor para o usuário e, ao mesmo tempo, como cliente de outros agentes especializados.

Agent Card: descoberta de capacidades

Cada agente A2A publica um arquivo JSON acessível em um endereço conhecido, o /.well-known/agent.json. Esse arquivo se chama Agent Card e funciona como um cartão de visita do agente.

Vale observar que versões mais recentes da especificação passaram a usar o caminho /.well-known/agent-card.json. A documentação do Microsoft Agent Framework, por exemplo, já expõe o cartão nesse endereço.

O Agent Card contém nome, descrição, versão, URL do endpoint, modalidades suportadas, habilidades disponíveis e mecanismos de autenticação. Dessa forma, agentes clientes descobrem automaticamente com quais agentes remotos podem interagir e de que forma.

{
  "name": "Burger Agent",
  "version": "1.0.0",
  "url": "https://burger-agent.example.com",
  "skills": [
    {
      "id": "place_order",
      "name": "Place Order",
      "description": "Places a burger order"
    }
  ],
  "supportedModalities": ["text"],
  "authentication": {
    "schemes": ["bearer"]
  }
}

Nesse exemplo, o agente anuncia uma única habilidade, place_order, e informa que aceita autenticação do tipo bearer. Portanto, o cliente já sabe o que pode pedir e como deve se autenticar antes da primeira chamada.

Estrutura de mensagens no protocolo A2A

A comunicação no protocolo A2A se baseia em mensagens trocadas entre o cliente e o agente remoto. Cada mensagem tem um role, que pode ser user ou agent, e uma lista de Parts.

Uma Part é a menor unidade de conteúdo dentro de uma mensagem ou de um artefato. O protocolo define três tipos de Part:

• TextPart: conteúdo textual puro.
• FilePart: referência a um arquivo, com os bytes em base64 ou com uma URI.
• DataPart: dados estruturados em JSON.

Essa estrutura permite que o protocolo suporte múltiplas modalidades, incluindo texto, imagens, áudio e vídeo.

{
  "role": "user",
  "parts": [
    {
      "kind": "text",
      "text": "I want to order a burger"
    }
  ],
  "messageId": "msg-001"
}

O campo messageId identifica a mensagem de forma única. Com isso, cliente e servidor conseguem rastrear cada troca, mesmo em conversas longas.

Gerenciamento de tarefas

O conceito central do A2A é a Task, a unidade fundamental de trabalho gerenciada pelo protocolo. Cada task tem um identificador único e avança por um ciclo de vida bem definido.

Os estados possíveis de uma task são:

• submitted: a tarefa foi enviada e aguarda processamento.
• working: o agente está processando a tarefa.
• input-required: o agente precisa de mais informações do cliente.
• auth-required: o fluxo exige autenticação adicional.
• completed: a tarefa terminou com sucesso.
• canceled: alguém cancelou a tarefa.
• failed: ocorreu uma falha no processamento.
• rejected: o agente recusou a tarefa.

Quando uma task chega a um estado terminal (completed, failed, canceled ou rejected), ela não pode mais ser reiniciada. Nesse caso, o cliente precisa criar uma nova task para continuar o trabalho.

Os estados input-required e auth-required merecem atenção especial. Eles permitem que o agente pause a execução e peça algo ao cliente, em vez de simplesmente falhar.

Contexto e sessões

O A2A usa o contextId para agrupar logicamente várias tarefas e mensagens em uma mesma sessão conversacional. Ou seja, ele funciona como o fio que liga uma interação à outra.

Quando o cliente envia a primeira mensagem, o servidor gera um contextId e o devolve na resposta. Em seguida, as mensagens seguintes podem incluir esse identificador para indicar que fazem parte da mesma conversa.

Esse mecanismo permite que o agente mantenha histórico e estado conversacional entre várias trocas de mensagens.

Artefatos

Os Artifacts são as saídas que um agente produz como resultado de uma task. Um artefato pode ser um documento, uma imagem, dados estruturados ou qualquer outro conteúdo gerado.

Assim como as mensagens, os artefatos são compostos por Parts. Isso mantém a consistência do protocolo e permite que os artefatos suportem as mesmas modalidades das mensagens.

A separação entre mensagem e artefato também é útil na prática. Enquanto as mensagens carregam a conversa, os artefatos carregam o resultado concreto que o cliente vai consumir.

Padrões de comunicação do protocolo A2A

O protocolo A2A suporta três padrões distintos de comunicação, e cada um atende a um perfil de tarefa.

Requisição e resposta síncrona é o padrão mais simples. O cliente envia uma mensagem e aguarda a resposta direta do agente.

Streaming via SSE permite que o agente envie atualizações incrementais em tempo real enquanto processa uma tarefa longa. O stream começa com o objeto Task, segue com eventos TaskStatusUpdateEvent e TaskArtifactUpdateEvent e termina quando a task chega a um estado terminal.

Push notifications via webhook atendem tarefas extremamente longas ou clientes que não conseguem manter conexões persistentes, como aplicações mobile e funções serverless. Nesse modelo, o agente envia atualizações assíncronas via HTTP POST para uma URL de webhook que o cliente forneceu.

Tipos de agentes A2A

A especificação do protocolo descreve três arquiteturas de agentes. A escolha entre elas depende da complexidade das interações.

Message-only Agents respondem sempre com objetos Message. Eles servem bem para interações simples, que não exigem gerenciamento de estado complexo.

Task-generating Agents respondem sempre com objetos Task, mesmo em interações simples. Essa abordagem elimina a ambiguidade, mas cria objetos de tarefa até para respostas triviais.

Hybrid Agents combinam os dois modelos. Eles usam mensagens para negociar o escopo do trabalho e tarefas para rastrear execuções complexas com vários estados.

Exemplo de fluxo completo com o protocolo A2A

O exemplo a seguir ilustra um fluxo típico do protocolo A2A com streaming. Primeiro, o cliente envia uma mensagem pelo método message/stream:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "message/stream",
  "params": {
    "message": {
      "role": "user",
      "parts": [
        { "kind": "text", "text": "List my open support tickets" }
      ],
      "messageId": "msg-001"
    }
  }
}

Em seguida, o servidor responde com HTTP 200 e Content-Type: text/event-stream e começa a enviar eventos SSE. O primeiro evento traz a task no estado submitted, e as atualizações seguem até o estado completed, junto com os artefatos gerados.

Repare que o envelope é um JSON-RPC 2.0 comum, com jsonrpc, id, method e params. Por isso, qualquer biblioteca HTTP consegue montar essa requisição sem dependências especiais.

Paralelismo e tarefas dependentes

O A2A suporta trabalho paralelo, porque permite que agentes criem várias tasks distintas dentro do mesmo contextId. Isso viabiliza cenários como este:

• Primeira task: reservar um voo para Helsinki.
• Segunda task: com base na primeira, reservar um hotel.
• Terceira task: também com base na primeira, reservar uma atividade.
• Quarta task: com base na segunda, adicionar serviço de spa ao hotel.

Nesse cenário, o agente infere os artefatos relevantes a partir das tasks referenciadas ou do contextId. Assim, a segunda e a terceira tasks podem rodar em paralelo, já que ambas dependem apenas da primeira.

Esse modelo lembra um grafo de dependências. Cada task conclui sua parte e libera as que dependem dela, enquanto o contextId mantém tudo dentro da mesma conversa, sem que o cliente precise reenviar o histórico a cada passo.

Segurança no protocolo A2A

A especificação do protocolo A2A contempla autenticação e segurança em todas as fases do ciclo de vida do agente. O próprio Agent Card declara os mecanismos de autenticação suportados, então o cliente sabe de antemão como se autenticar.

A versão 0.3 trouxe a assinatura de Agent Cards, o que aumenta a confiabilidade na descoberta de agentes. Com a assinatura, o cliente consegue verificar que o cartão realmente veio de quem diz tê-lo publicado.

Além disso, o protocolo permite que agentes colaborem sem expor sua lógica interna, memória proprietária ou implementações de ferramentas. Na prática, cada agente funciona como uma caixa preta com um contrato público bem definido.

SDKs e ferramentas disponíveis

O projeto A2A oferece SDKs oficiais em Python e JavaScript, além de suporte nativo no Agent Development Kit (ADK) do Google.

O repositório oficial fica em github.com/a2aproject/A2A e reúne exemplos de agentes cliente e servidor, além de integrações com frameworks como CrewAI e LangGraph. Para começar com os exemplos em Python, o fluxo é este:

git clone https://github.com/a2aproject/a2a-samples.git
cd a2a-samples
python -m venv .venv && source .venv/bin/activate
# o SDK Python é publicado no PyPI como a2a-sdk
pip install a2a-sdk

No ecossistema .NET, o Microsoft Agent Framework também suporta o protocolo. O pacote Microsoft.Agents.AI.Hosting.A2A.AspNetCore expõe um agente como servidor A2A, e a classe A2AAgent permite consumir agentes remotos como se fossem agentes locais.

Para entender o framework em detalhes, comece pelo artigo sobre o Microsoft Agent Framework. Depois, veja como publicar agents no ASP.NET.

Considerações finais sobre o protocolo A2A

O protocolo A2A representa um avanço importante na padronização da comunicação entre agentes de IA. Como ele se apoia em HTTP, JSON-RPC 2.0 e SSE, a integração com a infraestrutura existente acontece de forma natural.

A adoção crescente, com mais de 150 organizações apoiando o protocolo, e a governança aberta sob a Linux Foundation indicam que o A2A tem potencial para se consolidar como padrão da indústria em sistemas multiagente.

Para equipes que constroem arquiteturas baseadas em agentes, a combinação de MCP para ferramentas e do protocolo A2A para a comunicação entre agentes oferece uma base sólida e extensível. Portanto, vale dominar os dois desde já.

FAQ

Quem criou o protocolo A2A?

O Google lançou o protocolo em abril de 2025. Em junho do mesmo ano, o projeto foi doado à Linux Foundation, que hoje cuida da governança.

Qual a diferença entre A2A e MCP?

O MCP conecta agentes a ferramentas e fontes de dados. Já o A2A conecta agentes a outros agentes.

O que é um Agent Card?

É um arquivo JSON publicado em um endereço conhecido do agente. Ele descreve nome, habilidades, endpoint, modalidades e formas de autenticação.

Quais transportes o A2A usa?

O protocolo usa HTTP, JSON-RPC 2.0 e SSE. A versão 0.3 acrescentou suporte a gRPC.

Dá para usar A2A com .NET?

Sim. O Microsoft Agent Framework tem pacotes para expor agentes como servidores A2A e para consumir agentes remotos.