Google ADK e A2A Protocol: o que muda para agentes de IA conectados?

Google ADK, A2A e MCP resolvem problemas diferentes. O ADK ajuda a construir e orquestrar o agente. O A2A permite que um agente delegue trabalho a outro agente remoto. O MCP conecta o agente a ferramentas e contexto externos. Eles podem coexistir, mas nenhum entrega estado, fila, segredos, logs, testes ou aprovação humana por mágica.

Para quem desenvolve sozinho, a decisão mais segura é começar com a menor camada que resolve o fluxo. A2A entra quando existe outro agente independente, com responsabilidade e contrato claros. Antes disso, uma função, uma API ou um workflow no mesmo processo costuma ser mais barato de manter e muito mais fácil de depurar.

O que muda de verdade com ADK, A2A e MCP

O Google ADK é um framework open source e code-first para criar, avaliar e implantar agentes. O projeto é otimizado para Gemini, mas se declara independente de modelo e de ambiente de implantação. Isso abre espaço para diferentes provedores, porém não torna prompts, custos, sessões ou migração de workflows automaticamente portáveis.

O A2A foi anunciado pelo Google em 9 de abril de 2025 como um protocolo aberto para agentes de fornecedores e frameworks distintos se comunicarem e coordenarem ações. No anúncio oficial do A2A, a relação foi descrita de forma direta: A2A complementa MCP. MCP entrega ferramentas e contexto ao agente. A2A trata da colaboração entre agentes.

Essa separação evita uma confusão comum. A2A não substitui MCP. Também não substitui API REST, fila ou chamada de função. Ele cria um contrato para falar com outro agente quando esse outro agente é a unidade de trabalho.

A regra prática é simples: não escolha o protocolo pelo nome mais novo. Escolha pela fronteira real do sistema. Um agente que chama uma função sua não precisa virar um serviço A2A só porque o produto tem mais de uma etapa.

Discurso oficial versus evidência operacional

Google apresenta o ADK como uma base para criar, avaliar e implantar agentes. O A2A é apresentado como um protocolo aberto para agentes de fornecedores e frameworks distintos se comunicarem. A documentação também posiciona A2A e MCP como camadas complementares, não concorrentes.

A evidência da pesquisa impõe limites práticos a esse discurso. O protocolo padroniza comunicação, mas não elimina decisões sobre identidade, autorização, versão, estado, timeout, retry, logs ou custo de cada serviço. A2A também não migra prompts, credenciais ou contratos de erro entre frameworks por conta própria.

O problema real: demo de agente não é produção

Uma demo mostra que um modelo consegue chamar uma ferramenta. Produção precisa responder outra lista de perguntas: quem pode chamar o endpoint? O que acontece quando uma tarefa demora? Como você correlaciona uma falha? O retry duplica uma ação? Onde está o estado depois de reiniciar o container?

É aqui que aparece a Conta de Operação Multiagente. Cada agente remoto adiciona trabalho recorrente: autenticar, versionar, observar, limitar, recuperar e pagar chamadas entre serviços. Essa conta não é uma crítica ao A2A. É o custo operacional de criar uma nova fronteira de rede.

O A2A descreve comunicação por JSON-RPC 2.0 sobre HTTP(S), descoberta por Agent Cards, resposta normal, streaming por SSE e push assíncrono. O Agent Card pode informar identidade, capacidades, skills, endpoint e requisitos de autenticação. Consulte o contrato da especificação A2A antes de modelar essa integração.

Mas publicar um Agent Card não é o mesmo que abrir um catálogo público confiável. Você ainda decide identidade, autorização, limites, exposição de dados e política de erro. Um endpoint que aciona uma ação externa sem confirmação pode transformar uma boa integração em uma superfície de abuso.

O projeto A2A está sob a Linux Foundation, foi contribuído pelo Google e usa licença Apache-2.0. O repositório e SDKs A2A lista SDKs para Python, Go, JavaScript, Java, .NET e Rust. Disponibilidade de SDK, porém, não garante paridade de recursos nem maturidade idêntica entre linguagens.

O que o Google ADK resolve no código

O ADK oferece um runtime de workflow em grafo. A documentação do projeto lista routing, fan-out e fan-in, loops, retry, estado, nós dinâmicos, human-in-the-loop e workflows aninhados. É uma base útil quando seu agente já precisa de caminhos condicionais e ferramentas com controle explícito.

O framework também declara suporte a ferramentas próprias, funções, especificações OpenAPI e ferramentas MCP. Em termos de arquitetura, isso permite que o agente ADK use MCP para alcançar uma ferramenta ou contexto, enquanto A2A fica reservado para a delegação a outro agente remoto.

A camada de confirmação de ferramentas merece atenção. O ADK oferece fluxo de confirmação, mas não decide quais ações são perigosas no seu produto. Excluir registros, enviar mensagens, aprovar transações ou alterar permissões são decisões de negócio. Elas devem ter política de menor privilégio e aprovação humana quando fizer sentido.

O ADK pode ser containerizado e implantado em Cloud Run ou Vertex AI Agent Engine. Como o framework se declara deployment-agnostic, ele também pode rodar em uma VPS. Isso não autoriza recomendar uma quantidade universal de RAM, CPU ou agentes por servidor. A documentação consultada não fornece esse dimensionamento comparável.

O ADK Python exige Python 3.10 ou superior. O repositório também lista implementações em Java, Kotlin, Go e TypeScript. Trate cada uma como uma implementação própria: nomes, APIs e detalhes de integração não devem ser transferidos de uma linguagem para outra sem teste.

Onde A2A entra entre agentes independentes

A2A faz sentido quando o segundo agente é um serviço de verdade. Talvez ele pertença a outro domínio, tenha um ciclo de release separado, use outro framework ou seja mantido por outra equipe. Nesse cenário, um contrato explícito de tarefa é melhor do que acessar memória e ferramentas internas desse agente.

Essa separação preserva a implementação interna. Um agente pode colaborar sem revelar necessariamente memória, estado ou ferramentas. Em troca, quem integra precisa caprichar no contrato de entrada e saída, no tracing e nos limites de timeout. Opacidade protege, mas não ajuda a depurar uma tarefa que terminou sem o resultado esperado.

O ADK ganhou recursos A2A no release Python v2.8.0, publicado em 26 de agosto de 2026. O release do ADK com A2A documenta task mode nativo e suporte de autenticação para RemoteA2aAgent. Fixe versões, teste upgrades e mantenha um rollback possível. O próprio projeto alerta para mudanças incompatíveis na API de agentes, no modelo de eventos e no schema de sessão entre gerações do ADK.

Quando não usar A2A

Não use A2A para transformar uma sequência interna em arquitetura distribuída. Se as etapas vivem no mesmo processo, se a integração é única ou se o fluxo é linear e conhecido, uma função direta, uma API interna ou uma fila costuma resolver com menos pontos de falha.

Também é cedo para A2A quando você ainda não consegue responder cinco perguntas: qual é a responsabilidade do agente remoto? Qual input ele aceita? Qual output ele devolve? Como ele sinaliza erro? Quem aprova ações irreversíveis? Sem essas respostas, o protocolo só conecta um processo que ainda não foi definido.

Esse ponto importa porque o roadmap do A2A continua evoluindo. O repositório oficial cita trabalho futuro em esquemas de autorização no Agent Card, confiabilidade de streaming e push, além de métodos adicionais. Interoperabilidade é uma vantagem, não um atalho para pular design, testes e controles.

Se seu objetivo é uma automação visual simples, comparar n8n versus Make pode ser uma escolha mais direta. Para um agente que precisa coletar páginas, uma ferramenta como Firecrawl pode entrar como integração específica, sem exigir outro agente remoto.

Stack mínima em VPS: o que você precisa operar

Uma VPS é útil quando o agente precisa ficar disponível, executar workers persistentes, receber callbacks ou compartilhar uma rede controlada com banco, fila e serviços MCP. Ela dá controle de implantação e persistência. Não entrega observabilidade, segurança ou recuperação configuradas.

Comece com Docker e configuração versionada. Mantenha segredos fora do Git. Defina onde ficam volume e estado. Coloque HTTPS e uma camada de identidade antes de expor endpoints. Centralize logs estruturados e inclua um identificador de correlação desde a entrada até a resposta do agente remoto.

Para tarefas demoradas, configure timeout e deixe claro o que acontece após ele. Retry sem idempotência pode repetir uma ação externa. Fila não é sinônimo de A2A: ela continua sendo uma opção quando o problema é processar jobs assíncronos com controle de entrega e recuperação.

Se você precisa de infraestrutura para manter agentes, workers, logs e integrações rodando, veja a VPS para rodar automações. Avalie a configuração pelo seu tráfego, pelo modelo usado e pelas tarefas reais. Não escolha servidor com base em uma promessa genérica de capacidade por agente.

Alternativas antes de complicar

LangGraph, CrewAI e OpenAI Agents SDK são alternativas reais para estruturar agentes. Os repositórios consultados desses três projetos usam licença MIT, enquanto ADK e A2A usam Apache-2.0. Licença do framework não cobre custos de modelo, hospedagem ou dependências.

A escolha não deveria ser um ranking abstrato. Use um framework quando ele melhora o workflow que você precisa entregar. Use A2A quando um agente remoto, autônomo e com contrato próprio precisa participar. Se a outra ponta adotar o protocolo, ela pode atuar nessa fronteira mesmo que sua lógica interna use outro framework. Isso não migra prompts, estado, credenciais ou contratos de erro automaticamente.

Para acessar diferentes modelos em uma aplicação, OpenRouter é outro componente que merece análise separada. Misturar camada de modelo, framework, protocolo e hospedagem numa escolha só costuma esconder os trade-offs.

Checklist: o que validar antes de expor A2A

1. Defina a responsabilidade exclusiva do agente remoto.
2. Documente o input, o output e os erros previstos para cada tarefa.
3. Verifique quem chama o endpoint e como essa identidade é comprovada.
4. Aplique autorização de menor privilégio às ferramentas e credenciais.
5. Mantenha segredos fora do Git e revise seu acesso.
6. Configure timeout, retry e idempotência para impedir ações duplicadas.
7. Inclua IDs de correlação e mascare dados sensíveis em logs e traces.
8. Defina onde estado e volumes persistem após reinícios.
9. Teste backup, restauração e o comportamento de tarefas longas.
10. Fixe versões, teste upgrades e mantenha um rollback possível.
11. Exija aprovação humana antes de ações irreversíveis.

FAQ

Google ADK é só para Gemini?

Não. O ADK se descreve como otimizado para Gemini, mas também como model-agnostic. Isso significa que a escolha de modelo continua exigindo configuração, testes e controle de custo por provedor.

A2A substitui MCP?

Não. A2A trata da comunicação e delegação entre agentes. MCP é a camada indicada para conectar um agente a ferramentas e contexto externos. Eles podem ficar no mesmo desenho.

Preciso de A2A para criar mais de um agente?

Não necessariamente. Vários agentes ou etapas no mesmo processo podem usar um workflow local. A2A faz mais sentido quando há uma fronteira de serviço entre agentes independentes.

Preciso de VPS para usar ADK e A2A?

Não para aprender ou prototipar localmente. Uma VPS passa a ser útil quando você precisa operar serviços persistentes, workers, callbacks, logs e integrações sob seu controle. A necessidade depende do seu produto, não do nome do protocolo.

Como expor um agente A2A sem pular segurança?

Comece com HTTPS, identidade, autorização de menor privilégio, segredos fora do Git, timeout, logs, rastreamento e confirmação humana para ações sensíveis. Teste falhas, retry e rollback antes de colocar usuários reais no fluxo.

Conclusão: use protocolo depois de definir o processo

ADK, A2A e MCP não competem pela mesma função. ADK constrói e orquestra. MCP conecta ferramentas e contexto. A2A cria uma fronteira entre agentes. O melhor ponto de partida para um solo builder é o menor stack que já resolve a dor.

Adote A2A quando houver outro agente independente e uma responsabilidade clara para delegar. A partir daí, trate endpoint, identidade, logs, estado e recuperação como parte do produto. Protocolo aberto ajuda a conectar serviços. Ele não substitui o processo, nem a operação que mantém esses serviços confiáveis.