O que é o Protocolo A2A? Agentes e Tarefas Explicados

O Protocolo A2A, abreviação de Agent2Agent Protocol (Protocolo Agente-para-Agente), é um padrão aberto para comunicação entre sistemas independentes de agentes de IA.

Essa frase soa simples, mas implica algo que a maioria das demonstrações de agentes de IA ignora completamente. A maioria das demos ainda assume um único assistente, um único tempo de execução, um único loop de ferramentas e um único proprietário — o agente pode pesquisar, chamar ferramentas, escrever código, consultar APIs, talvez usar servidores MCP e retornar uma resposta.

O A2A foi projetado para um mundo diferente, um onde os agentes podem ser construídos por equipes, frameworks, fornecedores, linguagens ou organizações distintas. Ele assume que um agente pode precisar descobrir outro agente, entender o que ele pode fazer, enviar trabalho para ele, trocar mensagens, receber arquivos ou saídas estruturadas e rastrear uma tarefa até a conclusão — tornando-o não apenas mais um formato de chamada de ferramenta, mas uma tentativa genuína de tornar os agentes de IA interoperáveis como pares.

Os conceitos principais são:

• Agent Cards (Cartões de Agente)
• Agentes e clientes
• Tarefas (Tasks)
• Mensagens
• Partes (Parts)
• Artefatos
• Estados da tarefa
• Transmissão (Streaming) e atualizações assíncronas

Este artigo explica esses conceitos em termos de engenharia simples, com detalhes suficientes para entender onde o A2A se encaixa em sistemas reais de múltiplos agentes.

A Definição Curta

O A2A é um protocolo para comunicação de agente para agente.

Ele permite que um agente ou cliente se comunique com outro agente através de um modelo comum. O agente receptor pode descrever suas capacidades, aceitar trabalho, gerenciar o ciclo de vida desse trabalho, pedir mais entrada, transmitir progresso e retornar saídas concretas.

O objetivo não é padronizar como um agente pensa internamente — é padronizar como os agentes se comunicam em suas fronteiras.

Um agente A2A pode usar internamente:

• Python
• Go
• JavaScript
• LangGraph
• CrewAI
• Semantic Kernel
• código personalizado
• servidores MCP
• APIs privadas
• bancos de dados vetoriais
• motores de fluxo de trabalho

O chamador não precisa saber nada disso. O que o chamador precisa saber é:

• O que este agente pode fazer?
• Como me comunico com ele?
• Qual entrada ele aceita?
• Qual saída ele pode produzir?
• Como rastreio o trabalho?
• Como recebo o resultado?

Essas seis perguntas definem a fronteira do protocolo que o A2A está tentando estabelecer entre agentes que operam independentemente.

Por Que o A2A Existe

Os sistemas de IA estão evoluindo de assistentes únicos para redes de agentes especialistas.

Uma empresa pode ter:

• Um agente de suporte
• Um agente de faturamento
• Um agente de revisão legal
• Um agente de DevOps
• Um agente de análise de dados
• Um agente de pesquisa
• Um agente de documentação
• Um agente de revisão de código

Cada agente pode ter suas próprias ferramentas, permissões, conhecimento de domínio, prompts, memória, sistema de recuperação e regras de auditoria.

Sem um protocolo compartilhado, cada integração se torna personalizada — o agente de suporte precisa de conexões personalizadas para o agente de faturamento, o agente de faturamento precisa das suas próprias para o agente legal, e o agente de pesquisa precisa de mais uma para o agente de documentação. Esse sobrecarga combinatória não escala bem à medida que a rede de agentes cresce.

O A2A oferece a esses agentes uma maneira comum de interagir, reduzindo o problema de integração N×M a um único contrato compartilhado. A promessa não é autonomia mágica; a promessa é interoperabilidade.

O A2A Não é o MCP

O A2A é frequentemente comparado ao MCP, mas eles resolvem problemas diferentes.

O MCP, ou Model Context Protocol (Protocolo de Contexto de Modelo), trata principalmente de conectar um aplicativo ou agente de IA a ferramentas, recursos e prompts, enquanto o A2A trata principalmente de conectar agentes a outros agentes.

Um modelo mental útil é:

MCP: agente para ferramenta
A2A: agente para agente

Por exemplo, um agente pode usar o MCP para acessar:

• GitHub
• um sistema de arquivos
• um banco de dados
• Slack
• um sistema de busca de documentação
• uma API em nuvem

Guias práticos para construir esses servidores MCP estão disponíveis para Go e Python.

O mesmo agente pode usar o A2A para delegar trabalho a:

• um agente de revisão de segurança
• um agente de pesquisa
• um agente de planejamento
• um agente de conformidade
• um agente de codificação

Os dois protocolos podem e frequentemente trabalham juntos. Uma arquitetura limpa é frequentemente:

A2A fora da fronteira do agente.
MCP dentro da fronteira do agente.

Isso significa que outros agentes se comunicam com seu agente usando o A2A, enquanto seu agente usa internamente o MCP para acessar ferramentas — uma separação clara de preocupações que mantém a interface externa estável, independentemente das mudanças internas. Para uma comparação detalhada de como os dois protocolos dividem a responsabilidade arquitetural e quando você realmente precisa de ambos, veja A2A vs MCP: Do AI Agents Really Need Both Protocols?

Papéis Principais no A2A

O A2A usa um modelo de papéis simples baseado em duas partes: um agente que expõe capacidades e um cliente que deseja usá-las.

O cliente pode ser:

• outro agente
• um orquestrador
• um aplicativo assistente
• um sistema de fluxo de trabalho
• um gateway
• um dispositivo de teste
• um aplicativo voltado para humanos

O agente pode ser:

• um serviço de IA especializado
• um assistente de domínio
• um agente que possui um fluxo de trabalho
• um agente de fornecedor remoto
• um agente empresarial interno

O importante é que o agente não é apenas uma função. Ele possui alguma capacidade e a expõe através de uma interface de agente.

Agent Cards (Cartões de Agente)

O Agent Card é um dos conceitos mais importantes no A2A.

Um Agent Card descreve um agente — é o documento de descoberta que informa aos clientes o que o agente é, o que ele pode fazer, como se comunicar com ele e quais restrições se aplicam.

Pense em um Agent Card como uma mistura de:

• metadados do serviço
• declaração de capacidade
• documento de descoberta de API
• perfil do agente
• superfície do contrato

Um Agent Card típico pode descrever coisas como:

• nome do agente
• descrição
• ponto de extremidade do serviço (endpoint)
• recursos do protocolo suportados
• modos de entrada e saída suportados
• habilidades disponíveis
• requisitos de autenticação
• informações do provedor
• informações de versão
• links de documentação
• metadados opcionais

O Agent Card é importante porque os agentes não precisam ter conhecimento codificado de todos os outros agentes.

Um cliente pode inspecionar o cartão e decidir:

• Este é o agente certo para o trabalho?
• Ele suporta o tipo de conteúdo que preciso?
• Ele suporta transmissão (streaming)?
• Ele requer autenticação?
• Quais habilidades ele anuncia?
• Ele pode retornar o tipo de artefato que preciso?

Em sistemas práticos, os Agent Cards tornam-se a base para registros de agentes, portais de desenvolvedores e catálogos internos de agentes — o equivalente legível por máquina de um diretório de serviços onde os clientes podem consultar o que está disponível antes de comprometer-se com uma integração.

Agent Cards São Fronteiras de Capacidade

Um Agent Card não deve ser tratado como texto de marketing — é uma fronteira de capacidade na qual outros sistemas confiarão em tempo de execução.

Se o cartão do seu agente diz que ele pode realizar análise financeira, os clientes podem começar a delegar trabalho de análise financeira a ele. Se diz que o agente aceita arquivos, os clientes podem enviar arquivos. Se diz que o agente suporta transmissão, os clientes podem esperar eventos de progresso.

Agent Cards ruins criam sistemas ruins porque as decisões de roteamento e suposições de capacidade se propagam por toda a rede de agentes. Um Agent Card útil deve ser:

• específico
• preciso
• estável
• versionado
• ciente da segurança
• honesto sobre limitações

Uma habilidade vaga como “executa tarefas empresariais” não é útil.

Uma melhor habilidade é:

Analisar dados de faturas de SaaS e produzir um resumo de gastos mensal.

Ainda melhor, inclua modos de entrada e saída esperados.

Entrada: registros de fatura em CSV ou JSON.
Saída: resumo em Markdown e totais em JSON estruturado.

Quanto mais preciso for o Agent Card, mais fácil será para outros agentes rotear tarefas corretamente.

Descoberta de Agentes

A descoberta de agentes é o processo de encontrar um Agent Card.

Em implantações simples, a descoberta pode ser estática. Um cliente já conhece a URL de um agente específico.

Em implantações maiores, a descoberta pode envolver:

• um registro
• um portal de desenvolvedores
• um catálogo interno
• descoberta baseada em DNS
• gerenciamento de configuração
• roteamento específico de ambiente
• gateways conscientes de inquilino (tenant-aware)

A escolha de design importante é se a descoberta é pública, privada ou com permissão.

Nem todo agente deve ser descobrível por todos — um agente de folha de pagamento interno não deve expor o mesmo Agent Card para todos os chamadores, e um agente parceiro pode ver apenas habilidades seguras para parceiros. A descoberta de agentes não é apenas um recurso de conveniência; é parte do seu modelo de segurança e governança, e escopar a visibilidade é uma decisão de design de primeira classe.

Tarefas (Tasks)

Uma Tarefa representa trabalho sendo realizado por um agente.

É aqui que o A2A se torna mais interessante do que APIs simples de solicitação e resposta.

Algumas interações de agentes são rápidas. Um cliente envia uma mensagem e o agente retorna uma resposta direta.

Mas muitos fluxos de trabalho reais de agentes não são instantâneos.

Uma tarefa pode envolver:

• pesquisar múltiplas fontes
• pedir esclarecimento
• chamar ferramentas
• delegar trabalho
• esperar por aprovação
• gerar um relatório
• produzir arquivos
• transmitir progresso
• lidar com retries (novas tentativas)
• retornar múltiplos artefatos

O A2A modela esse tipo de trabalho como uma Tarefa — dando ao trabalho uma identidade e um ciclo de vida, o que importa porque o trabalho de agentes de longa duração precisa ser rastreado, inspecionado e potencialmente cancelado ou repetido.

Ciclo de Vida da Tarefa

Uma tarefa pode passar por diferentes estados.

O modelo de estado exato depende da versão do protocolo e da implementação, mas a ideia básica é direta:

• submetida (submitted)
• em andamento (working)
• entrada necessária (input required)
• concluída (completed)
• falhou (failed)
• cancelada (canceled)
• rejeitada (rejected)

O ponto importante é que uma tarefa não é apenas uma carga de resposta — é uma unidade de trabalho em curso com seu próprio estado que um cliente pode consultar a qualquer momento. Um cliente pode usar o estado da tarefa para entender o que está acontecendo:

• O agente aceitou a tarefa?
• Ele ainda está trabalhando?
• Ele precisa de mais entrada?
• Ele terminou com sucesso?
• Ele falhou?
• Foi cancelado?
• Existem artefatos disponíveis?

Isso é especialmente útil para fluxos de trabalho que levam segundos, minutos ou mais.

Por exemplo, um agente de pesquisa pode retornar uma tarefa imediatamente e continuar trabalhando em segundo plano enquanto transmite eventos de progresso ou torna o resultado disponível mais tarde.

Mensagem Sem Estado ou Tarefa Com Estado

O A2A suporta interações simples e complexas.

Para uma interação simples, um agente pode retornar uma Mensagem direta; para uma interação complexa, ele pode retornar uma Tarefa. Essa distinção importa porque nem tudo precisa de rastreamento de tarefas, e superengenharia de interações curtas em fluxos de trabalho completos de tarefas adiciona sobrecarga desnecessária.

Se um cliente pergunta:

Resuma este parágrafo.

Uma resposta direta pode ser suficiente.

Se um cliente pergunta:

Pesquise os cinco principais bancos de dados vetoriais de código aberto, compare-os e produza uma recomendação de migração.

Uma tarefa é mais apropriada.

A regra prática é direta: use uma Mensagem direta para interações simples e imediatas, e use uma Tarefa para trabalho de longa duração, com estado, auditável ou que produza artefatos.

Mensagens

Mensagens são as unidades de comunicação trocadas entre cliente e agente.

Uma mensagem pode conter uma ou mais partes.

Uma mensagem pode representar:

• uma solicitação do usuário
• uma resposta do agente
• uma pergunta de esclarecimento
• entrada adicional
• comunicação relacionada à tarefa
• contexto de progresso
• instruções estruturadas

As mensagens não são apenas strings — a comunicação de agentes frequentemente precisa carregar muito mais do que texto puro, e a estrutura da mensagem é projetada para acomodar isso.

Uma mensagem pode incluir:

• texto
• arquivos
• JSON estruturado
• imagens
• referências
• metadados

A mensagem é o envelope; as partes são o conteúdo tipado real dentro dele.

Partes (Parts)

Uma Parte é um pedaço de conteúdo dentro de uma mensagem ou artefato.

É assim que o A2A suporta comunicação multimodal e estruturada.

Uma parte pode conter diferentes tipos de conteúdo, como:

• texto
• dados de arquivo
• dados estruturados
• conteúdo binário por referência
• dados semelhantes a JSON

Uma parte também pode incluir metadados como:

• tipo de mídia (media type)
• nome do arquivo
• contexto adicional

O tipo de mídia importa porque ele informa ao agente receptor como interpretar o conteúdo.

Por exemplo:

text/plain
application/json
text/markdown
image/png
application/pdf
text/csv

Esta é uma das partes subestimadas do A2A. A comunicação de agentes não deve colapsar tudo em texto puro — se um agente downstream precisa de uma planilha, imagem, payload JSON, arquivo de log ou PDF, o protocolo deve preservar esse conteúdo como conteúdo, em vez de transformá-lo em um parágrafo. Bons sistemas de agentes evitam esses gargalos de texto desnecessários ao permitir que cada parte carregue seu tipo de mídia natural até o consumidor.

Artefatos

Artefatos são saídas concretas produzidas por um agente durante o processamento de uma tarefa.

Isso é diferente de uma mensagem geral: uma mensagem é comunicação entre agentes, enquanto um artefato é um entregável concreto que a tarefa produziu.

Exemplos de artefatos incluem:

• um relatório em Markdown
• um resultado de análise em JSON
• uma exportação CSV
• uma imagem gerada
• um documento PDF
• um patch de código
• um arquivo de resultado de teste
• um plano de implantação
• um diagrama
• um extrato de dados

Essa distinção é útil na prática. Quando um agente de pesquisa diz “Encontrei a resposta”, isso é uma mensagem. Quando ele retorna market-analysis.md, sources.json e risk-summary.csv, esses são artefatos — saídas concretas que tornam o trabalho da tarefa inspecionável, reutilizável e composável. O artefato de um agente torna-se a entrada de outro agente sem perda de estrutura.

Mensagens vs Artefatos

Uma maneira simples de pensar nisso:

Mensagens são conversa.
Artefatos são saída.

As mensagens ajudam os agentes a coordenar; os artefatos são o que a tarefa realmente produziu.

Por exemplo, em um fluxo de trabalho de desenvolvimento de software:

• O cliente envia uma mensagem pedindo uma correção de bug.
• O agente de codificação envia mensagens com perguntas de esclarecimento.
• O agente de codificação trabalha na tarefa.
• O agente retorna artefatos como um arquivo de patch, saída de teste e explicação.

Essa separação é útil porque evita misturar coordenação de tarefas com entregáveis, tornando muito mais fácil registrar, auditar e passar saídas para consumidores downstream.

Um Exemplo Prático

Imagine que um assistente primário precisa de ajuda de um agente de documentação.

O usuário pergunta:

Crie documentação de desenvolvedor para nossa nova API de webhook de faturamento.

O assistente primário verifica um registro de agentes e encontra um agente de documentação.

O agente de documentação tem um Agent Card que diz que ele pode:

• escrever documentação de API
• aceitar especificações OpenAPI
• aceitar guias de estilo Markdown
• produzir documentos Markdown
• produzir exemplos em Python e JavaScript
• suportar tarefas de longa duração
• retornar artefatos

O assistente primário envia uma mensagem com:

• uma breve instrução
• um arquivo OpenAPI
• um guia de estilo
• metadados sobre o público-alvo

O agente de documentação cria uma Tarefa.

A tarefa entra em estado de trabalho.

O agente de documentação pode enviar mensagens como:

Estou extraindo descrições de endpoints.

Depois:

Preciso de esclarecimento sobre exemplos de autenticação.

O assistente primário fornece a entrada ausente.

A tarefa continua.

Finalmente, o agente de documentação retorna artefatos:

billing-webhooks.md
billing-webhook-examples-python.md
billing-webhook-examples-javascript.md

Esse é o modelo A2A em ação: não apenas “chame esta função”, mas “delegue esta tarefa a outro agente, comunique-se conforme necessário e rastreie o resultado até a conclusão.”

Por Que as Tarefas Importam Para Sistemas Reais

As Tarefas são o que tornam o A2A adequado para fluxos de trabalho sérios.

Uma chamada de API HTTP normal é frequentemente muito limitada para trabalho de agentes. As tarefas de agentes podem envolver incerteza, múltiplos passos, resultados intermediários e perguntas de acompanhamento.

Uma Tarefa fornece um lugar para anexar:

• status
• histórico
• mensagens
• artefatos
• erros
• metadados
• progresso
• cancelamento
• informações de auditoria

Isso é útil para:

• fluxos de trabalho de pesquisa
• geração de código
• análise de dados
• revisão de conformidade
• produção de documentos
• investigação de incidentes
• planejamento em múltiplos passos
• fluxos de trabalho de aprovação humana

Sem um modelo de tarefa, os desenvolvedores geralmente reconstruem essa lógica manualmente com IDs de trabalho personalizados, filas, endpoints de status e callbacks de webhook — o A2A tenta padronizar a versão específica de agentes desse padrão para que você não precise reinventá-lo para cada nova integração de agente.

Transmissão (Streaming) e Trabalho Assíncrono

O A2A suporta a ideia de que o trabalho de agentes pode ser em tempo real (streaming) ou assíncrono.

A transmissão é útil quando o cliente deseja atualizações ao vivo.

Por exemplo:

• eventos de progresso
• resultados parciais
• status intermediário
• texto gerado
• atualizações de etapa

Os fluxos de trabalho assíncronos são úteis quando a tarefa pode levar muito tempo ou o cliente não pode manter uma conexão aberta.

Por exemplo:

• pesquisa em segundo plano
• geração de documentos grandes
• revisão por múltiplos agentes
• processamento de dados
• aprovação humana
• análise em lote

Na prática, um sistema A2A robusto deve ser projetado em torno de três modos: resposta imediata para trabalho simples, transmissão para trabalho interativo de longa duração e assíncrono para trabalho de fundo durável que pode sobreviver a qualquer conexão única.

Agent Cards e Suporte a Transmissão

Um Agent Card pode anunciar se um agente suporta transmissão.

Isso importa porque os clientes não podem assumir que todos os agentes suportam transmissão — alguns agentes podem suportar apenas solicitação e resposta simples, alguns podem suportar polling de tarefas, e outros podem suportar notificações push ou eventos enviados pelo servidor. Um bom cliente inspeciona o Agent Card antes de escolher um padrão de interação, é por isso que os Agent Cards não são apenas documentação: eles moldam diretamente o comportamento em tempo de execução.

A2A e Agentes Multimodais

O A2A é projetado para suportar mais do que texto puro.

Isso importa porque os sistemas reais de agentes processam cada vez mais entradas e saídas mistas:

• texto
• imagens
• áudio
• vídeo
• PDFs
• planilhas
• JSON estruturado
• logs
• código
• diagramas

Se cada fronteira de agente converter tudo em texto, informações importantes podem ser perdidas.

Por exemplo, um agente de solução de problemas visuais deve receber uma imagem como uma imagem, não como uma descrição de texto fraca. Um agente financeiro deve receber dados estruturados de planilha, não um parágrafo copiado. Um agente de revisão de código deve receber arquivos de fonte ou diffs, não um resumo vago.

Partes e tipos de mídia são como o A2A preserva conteúdo mais rico através das fronteiras dos agentes — e este é um dos lugares onde o protocolo é mais importante do que parece à primeira vista, porque a perda de informação na fronteira se acumula em cada salto em uma cadeia de múltiplos agentes.

O A2A Não é um Framework de Agente

O A2A não diz como construir um agente.

Ele não define:

• estratégia de raciocínio
• algoritmo de planejamento
• sistema de memória
• banco de dados vetorial
• modelo de prompt
• provedor de modelo
• framework de ferramentas
• tempo de execução de orquestração
• método de avaliação

Isso é um recurso, não um bug. O A2A é um protocolo de fronteira que permite que diferentes implementações de agente se comuniquem sem exigir que compartilhem a mesma arquitetura interna — assim como o HTTP não diz como construir um aplicativo web, ele apenas define como os sistemas se comunicam. O A2A deve ser entendido da mesma maneira.

O A2A Não é um Substituto para APIs

O A2A também não substitui todas as APIs.

Se você tem um serviço determinístico com um contrato estável de solicitação e resposta, uma API normal pode ser melhor.

Por exemplo:

• conversão de moeda
• validação de endereço
• consulta de fatura
• redimensionamento de imagem
• endpoint de busca
• consulta de bandeira de recurso (feature flag)
• serviço CRUD interno

Estes não se tornam agentes automaticamente só porque são chamados por um sistema de IA. O A2A faz sentido quando o sistema remoto se comporta genuinamente como um agente:

• ele possui uma tarefa
• ele pode pedir mais entrada
• ele pode usar ferramentas internamente
• ele pode levar tempo
• ele pode produzir artefatos
• ele tem capacidades que valem a pena descobrir
• ele pode operar como um par em um fluxo de trabalho maior

Não use o A2A apenas porque é moderno — use-o quando a abstração se encaixa genuinamente no problema.

Onde o A2A se Encaixa na Arquitetura de Sistemas de IA

O A2A se encaixa melhor na fronteira entre agentes implantados independentemente.

Uma arquitetura útil pode parecer assim:

Usuário
  |
  v
Assistente primário
  |
  |-- A2A --> Agente de pesquisa
  |-- A2A --> Agente de codificação
  |-- A2A --> Agente de conformidade
  |-- A2A --> Agente de documentação

Cada agente especializado pode usar ferramentas internamente:

Agente de pesquisa
  |
  |-- MCP --> busca na web
  |-- MCP --> armazenamento de documentos
  |-- MCP --> banco de dados vetorial

Isso fornece camadas separadas:

Camada de interface do usuário
Camada de coordenação de agentes
Camada de integração de ferramentas
Camada de dados e execução

O A2A vive na camada de coordenação de agentes, o MCP frequentemente vive na camada de integração de ferramentas, e APIs normais, filas, bancos de dados e sistemas de armazenamento vivem abaixo disso — cada camada com sua própria abstração e seus próprios modos de falha. Para um mapa transversal de como inferência de LLM, memória, roteamento, ferramentas e observabilidade se encaixam dentro de assistentes de produção, veja AI Assistant Architecture: LLM, Memory, Tools, Routing, Observability.

Padrão de Arquitetura: Orquestrador e Especialistas

O padrão A2A mais comum é provavelmente orquestrador mais especialistas.

Neste padrão, um agente primário recebe a solicitação do usuário e delega partes do trabalho a agentes especialistas.

Exemplo:

Assistente primário
  |
  |-- A2A --> Agente legal
  |-- A2A --> Agente financeiro
  |-- A2A --> Agente de pesquisa
  |-- A2A --> Agente de escrita

Este padrão é fácil de entender: o orquestrador possui o fluxo de trabalho geral, e os agentes especialistas possuem o trabalho específico do domínio. A desvantagem é que o orquestrador pode se tornar um gargalo, e ele precisa de uma estratégia de roteamento sólida para delegar eficazmente — a seleção do modelo subjacente e as compensações de orquestração são abordadas em Multi-Model System Design: When One Model Isn’t Enough. Ainda assim, para a maioria das equipes, esta é a melhor primeira arquitetura de múltiplos agentes a ser adotada antes de explorar topologias mais complexas.

Padrão de Arquitetura: Agentes Pares

Em um padrão peer-to-peer (par a par), os agentes podem se comunicar entre si mais diretamente.

Por exemplo:

Agente de pesquisa --> Agente de dados --> Agente de gráficos --> Agente de escrita

Isso pode ser poderoso, mas é mais difícil de controlar.

Você precisa de regras fortes para:

• quem pode chamar quem
• qual contexto pode ser compartilhado
• como os loops são prevenidos
• quem possui a saída final
• como o custo é controlado
• como a delegação é auditada

As redes de agentes pares soam elegantes, mas podem se tornar caóticas rapidamente — use-as apenas quando você tiver regras de governança fortes e propriedade clara sobre cada aresta no grafo.

Padrão de Arquitetura: Gateway A2A

Um padrão mais amigável para produção é um gateway A2A.

Em vez de cada agente chamar diretamente todos os outros agentes, o tráfego flui através de um gateway.

O gateway pode lidar com:

• autenticação
• autorização
• roteamento
• mapeamento de inquilino (tenant mapping)
• registro de logs
• limites de taxa (rate limits)
• verificações de política
• manipulação de versão do protocolo
• observabilidade
• trilhas de auditoria

Isso é especialmente útil em ambientes empresariais, onde o gateway torna-se o plano de controle para comunicação de agentes — aplicando política em um único lugar em vez de reimplementá-la em cada agente. Em sistemas menores, isso pode ser exagero, mas em sistemas maiores com múltiplas equipes e fornecedores, frequentemente se torna necessário mais cedo do que o esperado.

Considerações de Segurança

A segurança do A2A merece atenção séria.

A comunicação de agente para agente pode mover contexto sensível através de fronteiras. Ela também pode delegar trabalho a sistemas que podem ter suas próprias ferramentas e permissões.

As perguntas centrais de segurança são:

• Quais agentes têm permissão para descobrir este agente?
• Quais agentes têm permissão para enviar tarefas a ele?
• Que autenticação é necessária?
• Quais permissões estão anexadas ao chamador?
• Um agente pode delegar autoridade do usuário a outro?
• Quais dados podem ser incluídos em mensagens?
• Quais artefatos podem ser retornados?
• Como a tarefa é auditada?
• O agente receptor pode chamar ferramentas ou outros agentes?
• Como os segredos são protegidos?

Os Agent Cards não devem conter segredos estáticos, e Agent Cards sensíveis devem ser protegidos atrás de autenticação em vez de publicados abertamente. Diferentes clientes frequentemente precisam de diferentes visões do mesmo agente — um chamador interno pode ver mais habilidades do que um parceiro externo, enquanto um cliente público pode ver apenas um conjunto limitado de capacidades seguras.

A segurança não deve ser adicionada após a rede de agentes ser construída; ela deve moldar a rede desde o início, porque retrabalhar fronteiras de autenticação e permissão em uma topologia de agentes ao vivo é significativamente mais difícil do que projetá-las desde o início.

Considerações de Observabilidade

Os sistemas A2A precisam de forte observabilidade.

Quando uma tarefa cruza fronteiras de agentes, a depuração torna-se substancialmente mais difícil porque nenhum sistema único possui o quadro completo. Você precisa saber:

• qual agente criou a tarefa
• qual agente a aceitou
• quais mensagens foram trocadas
• quais mudanças de estado ocorreram
• quais artefatos foram produzidos
• quais erros aconteceram
• quanto tempo cada etapa levou
• quais ferramentas foram usadas internamente
• se outro agente foi chamado
• quem aprovou ações de risco

Uma trilha útil deve seguir o trabalho através da cadeia completa.

Por exemplo:

solicitação do usuário
  -> tarefa do assistente primário
  -> tarefa do agente de pesquisa
  -> chamada de ferramenta de busca de documentos
  -> artefato de sumarização
  -> resposta final

Sem essa trilha ponta a ponta, os sistemas de múltiplos agentes tornam-se muito difíceis de confiar em produção — você não pode responder com confiança por que o sistema produziu uma determinada saída, muito menos identificar onde ele falhou. Observability for LLM Systems: Metrics, Traces, Logs, and Testing in Production cobre o lado da instrumentação e ferramentas deste problema em profundidade.

Erros Comuns

Erro 1: Chamar Cada Ferramenta de Agente

Nem toda ferramenta é um agente.

Uma calculadora é uma ferramenta. Um leitor de arquivos é uma ferramenta. Um endpoint de consulta de banco de dados é uma ferramenta.

Se ela não possui uma tarefa, pedir entrada, produzir artefatos ou se comportar como um par independente, provavelmente não precisa do A2A.

Erro 2: Tornar os Agent Cards Muito Vagos

Um Agent Card não deve dizer:

Este agente ajuda com tarefas empresariais.

Isso é inútil para qualquer agente tentando rotear trabalho inteligentemente. Um bom cartão deve dizer o que o agente realmente faz, o que ele aceita, o que ele retorna e quais restrições se aplicam.

Erro 3: Ignorar o Estado da Tarefa

Se você usa o A2A mas trata cada interação como solicitação e resposta, está perdendo grande parte do valor.

O modelo de tarefa é um dos principais motivos para usar o A2A em vez de uma API simples — ignorá-lo significa reconstruir a mesma lógica de rastreamento de ciclo de vida em cada integração.

Erro 4: Retornar Tudo Como Texto

O A2A suporta conteúdo estruturado e multimodal. Use-o.

Se a saída é um relatório, retorne um artefato de relatório.

Se a saída é JSON, retorne dados estruturados.

Se a saída é um arquivo, retorne um arquivo.

Não achate tudo em texto puro a menos que o texto puro seja a saída correta.

Erro 5: Sem Modelo de Permissão

As redes de agentes sem fronteiras de permissão são arriscadas.

Nem todo agente deve ter permissão para chamar todos os outros agentes com todo tipo de dados — use autenticação, autorização e trilhas de auditoria para aplicar o princípio do privilégio mínimo através da rede de agentes.

Quando Você Deveria Usar o A2A?

Use o A2A quando você tiver fronteiras reais de agentes.

Boas razões incluem:

• agentes são possuídos por diferentes equipes
• agentes são implantados como serviços separados
• agentes são construídos com diferentes frameworks
• agentes precisam se descobrir
• agentes precisam delegar tarefas
• tarefas podem ser de longa duração
• resultados podem incluir artefatos
• clientes não devem conhecer ferramentas internas
• metadados de capacidade do agente importam

Razões fracas incluem:

• soa moderno
• você quer chamar uma única função
• você tem um aplicativo de agente único
• uma API normal funcionaria
• o MCP já resolve seu problema de integração de ferramentas

O A2A é poderoso quando o sistema é realmente multi-agente; é cerimônia desnecessária quando o sistema não é, e o custo dessa cerimônia — conceitos adicionados, infraestrutura, superfície de depuração e requisitos de segurança — é real.

Um Modelo Mental Mínimo

Se você lembrar de apenas uma coisa, lembre-se disso:

Agent Card: o que o agente pode fazer.
Message: o que os agentes dizem uns aos outros.
Part: conteúdo tipado dentro de uma mensagem ou artefato.
Task: trabalho que o agente possui.
Artifact: saída que a tarefa produziu.

Essa é a essência do A2A — o resto é principalmente sobre tornar esses cinco conceitos confiáveis, observáveis e seguros o suficiente para uso em sistemas de produção reais.

Pensamentos Finais

O A2A não é apenas mais um acrônimo de IA — é parte de uma mudança maior de assistentes isolados para sistemas de agentes interoperáveis. Essa mudança não acontecerá em todos os lugares de uma vez, e muitos aplicativos permanecerão como sistemas de agente único com bom acesso a ferramentas onde o MCP e as APIs normais são totalmente suficientes.

Mas uma vez que os agentes se tornem pares implantados separadamente, você precisa de fronteiras mais fortes: descoberta, propriedade de tarefas, mensagens que carregam mais do que texto, artefatos como saídas de primeira classe, e segurança, estado e observabilidade que atravessam as fronteiras dos agentes. Esse é o espaço que o A2A está tentando ocupar, e é um problema genuinamente diferente do problema de integração de ferramentas que o MCP resolve.

Para uma visão prática de onde o A2A realmente tem tração de produção em 2026 — incluindo tiers de adoção, preocupações de segurança, o caso de uso empresarial e um framework de decisão — veja Google A2A Protocol in 2026: Adoption, Hype, and Reality.

Minha opinião: não comece com o A2A para projetos pequenos. Comece com um agente útil, boas ferramentas e arquitetura clara — o AI Systems cluster cobre assistentes auto-hospedados, servidores MCP e memória de agentes como um conjunto conectado se você quiser o contexto mais amplo. Mas quando sua “ferramenta” começa a parecer com outro especialista autônomo com seu próprio ciclo de vida de tarefas, provavelmente não é apenas uma ferramenta mais — e é quando o A2A se torna interessante.

Fontes

• Especificação do Protocolo A2A: https://a2a-protocol.org/latest/specification/
• Conceitos-Chave do A2A: https://a2a-protocol.org/latest/topics/key-concepts/
• Vida de uma Tarefa no A2A: https://a2a-protocol.org/latest/topics/life-of-a-task/
• Descoberta de Agentes no A2A: https://a2a-protocol.org/latest/topics/agent-discovery/
• Transmissão e Operações Assíncronas no A2A: https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A e MCP: https://a2a-protocol.org/latest/topics/a2a-and-mcp/