Google A2A: o HTTP dos agentes de IA vai escalar?

Interoperabilidade de agentes travou e o Google quer resolver

Agent2Agent, ou A2A, chegou porque construir agente isolado ficou fácil demais e fazer dois agentes de empresas diferentes trabalharem juntos continua doloroso. Quem já tentou orquestrar um agente de atendimento com um agente de cobrança, um de logística e outro de análise sabe o problema. Cada um fala um dialeto próprio, espera um formato de entrada diferente e devolve saída que ninguém previu. O resultado é cola manual, webhook improvisado e prompt gigante para traduzir contexto de um lado para o outro. É custo, latência e fragilidade empilhados. A proposta do Google é criar uma camada comum para essa conversa, algo próximo do que o HTTP fez pela web, mas para agentes autônomos que precisam delegar tarefas entre si sem intervenção humana a cada passo.

O fato

O Google anunciou o Agent2Agent como protocolo aberto para comunicação entre agentes, apresentado durante o Google Cloud Next junto com o suporte total ao MCP da Anthropic. A ideia não é substituir o MCP, e sim complementar. Enquanto o MCP padroniza como um agente acessa ferramentas e dados, com contexto, funções e recursos externos, o A2A padroniza como um agente fala com outro agente. O lançamento veio com especificação em draft, site de documentação e um Agent Development Kit para acelerar adoção, além de uma lista grande de parceiros. Na prática, o Google está tentando puxar para si a definição do padrão antes que o mercado fragmente em dez protocolos incompatíveis.

O recado é direto. Agentes remotos vão precisar se descobrir, negociar capacidade, trocar mensagens, acompanhar progresso e entregar um resultado verificável. Sem isso, multiagente vira demo bonita que quebra em produção. O A2A tenta formalizar esse ciclo com peças simples e familiares para quem já opera APIs distribuídas.

Como funciona na visão de quem opera

Pense no A2A como uma combinação de descoberta, RPC assíncrono e troca de artefatos, tudo sobre HTTP com JSON, com suporte a streaming. O primeiro bloco é o Agent Card. É um arquivo JSON público onde cada agente declara quem é, o que sabe fazer, quais endpoints expõe, quais métodos de autenticação aceita e qual nível de serviço promete. É o equivalente a um README executável mais um contrato OpenAPI simplificado. Seu orquestrador não precisa de integração customizada, ele lê o card, valida capacidades e decide se aquele agente remoto serve para a tarefa.

O segundo bloco é a Task. Quando seu agente local precisa de ajuda, ele abre uma Task com um agente remoto. Dentro dessa Task trafegam Messages, que carregam contexto, instruções e dados parciais, e no final é produzido um Artifact, que é o resultado entregável. Pode ser um relatório, um conjunto de linhas processadas, uma reserva confirmada, um código gerado. Esse modelo é importante porque separa conversa de entrega. Você consegue auditar o que foi pedido, o que foi intermediado e o que foi efetivamente entregue, em vez de ficar preso a um log infinito de chat.

Auth, observabilidade e tempo real

Para ambiente enterprise, o protocolo prevê recomendações de autenticação e observabilidade. Na prática, isso significa suportar esquemas já usados em APIs, como tokens, OAuth e mTLS, além de IDs de correlação para rastrear uma Task de ponta a ponta. Quem opera sabe que sem trace ID e sem log estruturado, depurar falha em cadeia de agentes é um pesadelo. O A2A também prevê streaming via Server-Sent Events e notificações push para tarefas longas. Isso evita polling burro a cada dois segundos e ajuda a controlar latência e custo de infraestrutura, embora empurre complexidade para o lado da segurança do push, validação de callback e retry.

Em termos de arquitetura provável, você terá um agente cliente que mantém estado da Task, um ou mais agentes remotos stateless ou semi-stateful, e uma camada de transporte que precisa lidar com timeout, cancelamento e idempotência. Se um agente remoto cair no meio de uma Task de dez minutos, quem retoma, quem paga pela recomputação, como evitar duplo efeito colateral. A especificação ainda é draft, então muitos desses detalhes vão aparecer na implementação real, não no papel. O custo aqui não é só token de LLM. É manter conexões abertas, gerenciar fila, armazenar artefatos intermediários e observar tudo isso sem estourar o orçamento de plataforma.

O que isso muda na prática

Para quem constrói, a mudança imediata é menos integração sob medida. Hoje, conectar seu agente a um agente de parceiro exige ler docs proprietárias, mapear campos na mão e torcer para não quebrar na próxima atualização. Com um Agent Card padrão e um ciclo de Task uniforme, dá para imaginar um marketplace funcional de agentes, onde descoberta e teste viram rotina. Ganha quem opera plataforma e quem precisa compor capacidades rápido, como times de CX, automação financeira, backoffice e integrações B2B.

Perde quem apostou em lock-in por conector proprietário. Se comunicação vira commodity, o diferencial volta para qualidade do modelo, dados exclusivos e execução confiável, não para o formato do plugue. E tem ajuste operacional para fazer agora, mesmo sem migrar tudo.

• Padronize seus contratos internos como se fossem Agent Cards, com capacidades, entradas, saídas e limites claros.
• Separe mensagem intermediária de artefato final no seu pipeline para facilitar auditoria e replay.
• Implemente uma ação prática imediata, exponha um endpoint de descoberta legível por máquina para cada agente crítico e meça latência, taxa de falha e custo por Task antes de adotar qualquer padrão externo.

Essa disciplina simples já prepara seu stack para plugar no A2A quando ele amadurecer, sem refatoração traumática. Também ajuda a negociar SLA com fornecedores, porque você passa a falar de Task concluída e artefato válido, não de conversa que pareceu boa.

A tensão real, isso escala ou só move o gargalo

Aqui entra a dúvida de operador. Padronizar a mensagem não resolve confiança, nem alinhamento de objetivo, nem custo de coordenação. Dois agentes podem trocar JSON perfeito e ainda assim se entender errado sobre o que significa concluir uma tarefa. Quem valida o Artifact, quem se responsabiliza por alucinação propagada em cadeia, como evitar loops onde o agente A delega para B que delega de volta para A e queima orçamento em segundos. Esses são problemas de semântica e governança, não de transporte.

Tem também o custo escondido da interoperabilidade total. Quanto mais fácil chamar agentes remotos, mais chamadas você fará, com mais streaming aberto, mais contexto replicado e mais tokens gastos em negociação. A latência de uma Task multiagente pode facilmente passar de segundos para minutos se cada salto envolver retrieval, reasoning e validação. Escala tecnicamente, sim, mas escala economicamente. Essa é a pergunta que o draft não responde. E tem o risco político. Padrão aberto liderado por um hyperscaler costuma começar aberto e terminar gravitacional, puxando todo mundo para seu ecossistema de identidade, observabilidade e hospedagem.

O paralelo com MCP ajuda a entender. MCP resolveu acesso a ferramenta, A2A tenta resolver delegação entre pares. Juntos, eles cobrem um fluxo completo, mas também criam duas superfícies para manter, versionar e securing. Para time pequeno, isso pode ser peso demais. Talvez o ganho real apareça primeiro em empresas grandes, com muitos agentes internos que precisam conversar com compliance e trilha de auditoria.

Conclusão

O A2A é um passo sensato para tirar multiagente do improviso e levar para engenharia de verdade, com descoberta, Task rastreável e entrega verificável. O valor vai depender menos do protocolo e mais de como você mede custo, latência e qualidade por Task. Vale testar em um fluxo delimitado e perguntar sem vaidade, meu sistema ficou mais confiável e mais barato, ou só ficou mais distribuído.